Architecture Proposal for User Session Data

[joepavitt]

Description

1. Addition to Dashboard code onAction and onChange to include msg.socketid on all transmitted messages
2. Dashboard does HTTP call on load to Node-RED as per https://flowfuse.com/blog/2023/11/dashboard-2.0-user-tracking/
   • This can include <object :data="'/tracker?id=' + $socket.id" height="1" width="1"></object> which would include the relevant SocketID and the session data for that user, provided by Node-RED Auth Middleware
3. Back in ui-base, we watch for the relevant /tracker (or eqv.) HTTP call, and then map socketid to req.session.user
4. All onAction, onChange, etc. events can then recall from this map, and attach the user object
5. On Socket Disconnect, remove the relevant entry from the map

Epic/Story

No response

[joepavitt]

@MarianRaphael FYI - @hardillb and I have received emails from Maastricht Uni complaining about a lack of functionality that they assumed they were getting when paying us. Miscommunication in e-mails, Ben and I are aligned in what they were requesting (which they received via https://flowfuse.com/blog/2023/11/dashboard-2.0-user-tracking/).

However, in a quick brainstorm to unlock them, Ben and I came up with a very quick win, small to implement solution, that would provide user data to all Dashboard-triggered events, subject to Node-RED having suitable Auth Middleware in place.

The complexity, and the reason I haven't just shipped this already, is how we package this, given that you want this constrained to FF EE only.

@hardillb says that within the context of FlowFuse, this would be EE only due to restrictions in place on FF Auth. However, this would not be possible to restrict to all instances of Node-RED running Dashboard 2.0, outside of the constraints on FF, i.e. someone can implement their own Node-RED Auth Middleware

[joepavitt]

Some complexities still exist around the immediate events sent/loaded when a new client connects, i.e. any events sent before the initial socket connection is established, and before the initial HTTP handshake may miss that data.

[hardillb]

@MarianRaphael feel free to ping me when free to discuss this

[MarianRaphael]

Discussed the solution with Ben. Given that the socketID is part of the output in Dashboard 1, I see no reason not to include it also in Dashboard 2 (CE). See the screenshot:

A dedicated 'ui-user' node or any other dedicated information that provides you with the username or allows multi-user usage, should be separated into a different npm package as a FlowFuse EE module.

[joepavitt]

A dedicated 'ui-user' node or any other dedicated information that provides you with the username or allows multi-user usage, should be separated into a different npm package as a FlowFuse EE module.

So, with Ben's blog post, that is possible using just the socketid. I will try and work out how to package into a ui-user, as it's not possible to extend existing functionality of a Node-RED node via a new node being imported, e.g. I need to modify code in ui-base, I can only do that in ui-base.

I will have more of a think and loop back. I'm also not keen on the idea of needing a floating node in Node-RED, it's very anti best practice/pattern.