D2 Notes from standard client data conversation between Joe and Julian

[TotallyInformation]

Description

Recommendations

1) On the client-side: 1) Add clientId, tabId , and possibly pageName (though that could be derived on the server if preferred) to the socket.io client options auth property via a callback function (so that it automatically gets the latest data on every (re)connection). [Ref](node-red-contrib-uibuilder/src/front-end-module/uibuilder.module.js at v6.8 · TotallyInformation/node-red-contrib-uibuilder (github.com)). Optionally send a browser timestamp to allow server/browser time offsets to be shared. 2) Add a feature to send a control message to the server whenever the URL Hash changes (to allow for front-end routing) 3) Add incoming message filters on: clientId, tabId and pageName.

2) On the server-side: 1) Add metadata into a msg._client property where it makes sense to expose it (connections, messages from the client, etc). Using the same property names as above for consistency. socketId can go in there as well or stay on msg._socketId (or both?) 2) Add outgoing message filters on: socket id, possibly by page name.

Socket.IO socket ID: msg._client.socketId

Usage: Automatically restrict message sending - at the server - to a specific connection. Usually only reliable for a fairly immediate response to something sent from the client.

Set by: SIO library. Stability: Only stable across a specific SIO connection. Restet: If the connection restarts.

Client ID (UUID): msg._client.clientId

Usage: Restrict message receipt - at the client. More stable than the socket id but still does not require any server session management since the id is randomly generated.

Set by: Node-RED server, Stored in: browser session cookie. Stability: Stable across a browser/server connection. Reset: If either the browser or the server is restarted.

Browser tab ID: msg._client.tabId

Usage: Restrict message receipt - at the client. More fine grained than client id allowing messaging to a specific browser tab even if client has multiple connections.

Set by: Browser. Stability: Stable across a browser connection. Reset: If the browser is restarted.

Page Name: msg._client.pageName

Usage: Restrict message receipt - at the client. But might also allow send restrictions for something like D2. Send messages to ALL connections to that page.

Assumes that separate UI instances have separate URL's so only needs to include the local path, otherwise will need the full URL (minus hash and query parameters).

Page URL Hash

NOTE: This needs to be dynamic and so cannot be put into the auth property.

Usage: Restrict message receipt - at the client. Send messages to ANY connections to a specific local route (any client showing that route).

Assumes that the Page Name restriction also used? If not, will need to include more of the URL.

Set by: Browser/page. Stability: Until user or automation changes the route. Reset: If the page is reloaded - IF a default route exists.

User ID

Usage: Necessary for Internet connected UI's and anywhere that needs to identify users and potentially control access.

Assumes that the app is worth setting up and maintaining an Identity & Access Management (IDAM) capability.

Set by: Server IDAM. Stability: Until user logs out or session expires. Reset: If the session expires or the user logs out or some other criteria set by IDAM process (e.g. IP Address change).

Have you provided an initial effort estimate for this issue?

I am no FlowFuse team member

[TotallyInformation]

If we can standardise at least some of this, I will also update UIBUILDER to use these over the uib-specific properties so that flows can work with both D2 and UIBUILDER.

[joepavitt]

In favour of this, main concern is Dashboard 1.0 backward compatibility in that it used msg.socketid, rather than a nested ._client object

[joepavitt]

FYI - as part of https://github.com/FlowFuse/node-red-dashboard/pull/438 I have started to move this content into the msg._client object. It will start with msg._client.socketId