Multi-user suggestions/thoughts

Ok, I know SFA about a lot of it, but as an external perspective.

Could there be something like a global.context which is set to different levels of access to the nodes.

Then, as users log in that global.context is set.
Therefore the nodes which use this context would then either be disabled or stop allowing input/interaction from the user.

So charts would not show any data. Text nodes would not show any text.
Buttons would not accept input.

Does that make sense?

I get what you are trying to say and I see your line of thought. However, the issue is that this is only 1, limited mode of operation of multi-user flows. There are many other modes depending on requirements, user numbers, data sensitivity, flow complexity, ...

So there is an inherent question here - should Node-RED be made to operate in one mode? What about the others? Is the additional complexity worth the effort for a single mode of operation?

And the final question might be - are there other ways of achieving the same affect without having to tie Node-RED to a single mode of operation?

For that last question, I believe there are other ways to achieve this. I've not thought it all the way through so do take this with a bit of a pinch of salt.

For simple requirements such as the one you outline, it probably isn't that hard to craft a flow that does what you've described without any special help from Node-RED.

For more complex requirements, you might make use of external tooling to provide the authentication and the authorisation workflows, with those tools adding suitable tags to user requests that you could then pick up in your flows.

I think another possible answer might lie in thinking about the nature of Node-RED as a Node.js app. Such apps generally fall into the "microservices" category. When you think of Node-RED in that way, you will quickly realise that maybe a single instance of Node-RED isn't necessarily the best approach.

In that case, you might have a core instance that does the more sensitive processing and a couple of instances that handle Dashboards - maybe one for people who are allowed access to everything and another for people who have limited visibility of the data. Of course, you could even go as far as having individual instances of Node-RED as I've seen someone else doing recently. With a master instance doing common processing and presenting effectively as an API server.

By also using a reverse proxy, and the previously mentioned external authentication and authorisation, you could get the proxy to direct people to the correct instance based on both user id and their group or authorisation tags.

I'm sure there are other approaches as well, but the point being that Node-RED is incredibly flexible which is exactly what is needed in this kind of tool. But that doesn't mean it has to do everything itself or everything in a single instance. As soon as you move towards multi-user and multi-authorisation workflows, you are moving into much more complex scenarios that deserve some decent thought before jumping in.

1 Like

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