Im still rather new to this, so i barely know where to start...
Is it possible to configure multi-tennant flows by attaching a scoped repository( a special object that has methods for interacting with data, where the data-access is coupled to a user in some way) to a context(node/flow/global) in an elegant way? im kind of lost on how to do that without it being a total pain the ass to work with.
i dont want to prepend a middleware to node red just yet, as that would prohibed any nodes that may want to use the repository from working in any environment that ist set up like mine is.
help is apprechiated, i hope im just missing something right now.
for context, i plan on just creating a node right now that initializes the repository for now.
After some testing i found out that websocket-ins and http-ins provide message-properties. Namely _session for websockets, where a session-id for the given websocket is stored as _session inside the object and req for httpins, the request object( the one that the underlying express-instance provides), which allows to to get a session via tokens. however, this adds the need for middleware, so i wont get arround using middleware in order to support multi-tennancy with regards to consumers of the webservice.
You can have the http response node send a http header ww-authenticate, this will mean the person has to log in, which you can use to identify them. I believe at that point you can set cookies etc in the response.
There is just 1 flow and it runs in the backend, which has no concept of the different users that can be defined for the editor (frontend).
If you want to run different flows for different users the only option is to run different instances of Node-RED.
Now if you are talking about multiple users interacting with a website hosted by Node-RED, either by using http-in/http-response nodes or the Node-RED Dashboard, that is a different thing.
The Node-RED Dashboard v2 supports multiple concurrent users and there are a number of plugins that support different authentication schemes, they are listed on the documentation page here:
Note that websockets does not support custom headers. Therefore it is only possible to have session headers on the initial connection, not on websocket messages. This limits the usefulness of session headers for systems that have long-running websocket comms.
As does UIBUILDER. Dashboard2 and http-in/-response are not the only options.
Dashboard2 and http-in/-response are not the only options.