IP-based Multi-Tenancy

Dashboard
1

Hi All.

For multi-tenancy purpose, I'm exploring the use of '_client.socketIp' instead of '_client.socketId' for maintaining UI state across tab changes in a multi-tenant environment.

Currently, all my UI-template nodes are being cleared when switching tabs frequently. Would an IP-based approach provide better persistence, triggering multi-tenancy only for new IPs regardless of socket changes?

Has anyone implemented this or can share insights on potential drawbacks?

I'm specifically looking at the "ui-template" node under Client Data.
Attached is what I'm trying to do - the "ui-template" is checked, under Client Data.

image
image1034Ă—1200 103 KB

Any experiences or advice would be greatly appreciated! Thanks

2

What are you building with the ui-template?

What data do you want loaded into the templates when they load?

Relying on socket would be fine for constraining to provide some level of consistency, but on refresh, the socketId does get reset.

3

It gets reset on reload AND on any loss of connection - e.g. if the tab or computer enters a sleep mode.

4

Thanks Guys;)

I'm building a multi-page dashboard starting with a login page, using ui-template nodes with Client Data enabled to toggle between pages. I'm tracking SocketID changes and how it's clearing UI data accordingly.

From the flow below, my steps are:

  1. Enter Email/Password → 2. Populate → 3. Refresh → 4. Previous → 5. Next Page (manually).

The goal is to maintain UI state across tab changes in a multi-tenant setup. I'm concerned about frequent SocketID resets clearing data unexpectedly. I've attached an example flow below for reference. Any suggestions on improving persistence would be appreciated.
Thanks again!

My Flow (too big to paste):

My_Flow.json (38.5 KB)

image
image1814Ă—1038 158 KB

5

You should also note that IP addresses can change unexpectedly depending on the environment.

For example, in an enterprise or even a home setup, a laptop might go from a wired to a wireless connection or visa versa and in doing so, the IP address may change.

So really, neither Socket ID nor IP address are really reliable sources of client information.

It is for this reason that UIBUILDER adds both a clientID and a tabID. The clientID is created as a UUID and retained for as long as the browser stays alive (so survives devices being put into sleep or hibernation) and is unique across all tabs in a single browser instance (which includes multiple windows of course). The tabID is created by the browser itself. These are made available to Node-RED and the client for maximum versatility. Neither of these id's are impacted by network changes or devices/tabs going to sleep.

3 Likes
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.