Hello,
I was wondering if there are any good ways of having multiple users acess a frontend with diffrent permissions. Like a login system into a dashboard that allows only some to control and others just to watch?
I have tried dashboard for it but I cant seem to make it work like that, and I am intimidated by uibuilder but want to be sure that it can do the trick before i try that?
is there something else I am missing?
Dashboard was originally designed as a single user service. Though there are ways to overlay permissions and there are various threads about that here on the forum.
Me too! 
But for different reasons of course.
There are a number of ways. Using an external (to Node-RED) service such as a proxy web server to handle the authentication and to add some metadata to the http headers is one way that can be robust and scalable. But perhaps not terribly "easy" to set up if you aren't familiar with the technologies.
uibuilder also provides several "middleware" points for both the Node-RED ExpressJS web server and for the Socket.IO websocket communications server. These allow you to have custom code that is automatically run when a client loads data from a web url controlled by uibuilder and when uibuilder messages are exchanged between Node-RED and clients. Again, though, you need some level of knowledge about how to use these. uibuilder aims to make the needed data and code insertion points available but it makes no assumptions about what your security needs are.
In addition, uibuilder now adds standard client data to messages and so that can be used in decisions you might want to make from within your flows. This information is the simplest way to make some basic decisions on giving/blocking access to information. But it might not be as robust for situations that call for higher levels of security.
Here is an example from a "connect" control message that uibuilder fires when a new client connects:
You can also turn on similar information for standard messages as well, that adds a msg._uib property with the information in.
The _socketId can change if the client loses connection and then reconnects or if the user reloads the page. The clientId is stable while any part of the client browser remains running. The tabId is similarly stable. The clients IP address can also be useful. Between these data points, it would be possible to fully track connected clients, redirect the client web page to a login page, link the client details to a logged-in identity and prevent data exchange with the client connection without a suitable token.
Bottom line therefore is that uibuilder provides the ability but not the actual security which must be provided either externally or via a custom flow and/or custom middleware.
I hope that helps with your decision making on usage? If not, I'm more than happy to answer further queries. Sadly security isn't especially easy, and good security is pretty hard, . But it can indeed be achieved.
And please don't be intimidated by uibuilder - it really isn't that hard to get to grips with, especially with the latest release. 
Ok, in that case starting with ui_builder is the right direction and to add the security once i know what i am doing with middleware, I might hit some snaggs with the security but luckily this is not that security critical of applications as the server is airgapped.
I am not actually that intimidaded by it as it is super well documented, just don't want to sink time into a project to realize it was built on the wrong foundations so no worries. 
Thank you so much for your response
1 Like
Cool. And I'm around to help.
Indeed, I continue to try to get better examples for security so working through with a real-world requirement would be useful.
Not a problem, always wanting to get feedback from people about how (and whether) they want to use uibuilder so that it gets guided towards an ever more useful tool.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
