Deal with users #538
Replies: 1 comment 1 reply
-
Hi Tobias, thanks for reaching out. I've always been clear with Node-RED users in general, let alone UIBUILDER users, authentication is best done outside of Node-RED completely. This is especially relevant for your use-case. Some background. UIBUILDER is fundamentally different to either of the 2 "Dashboards" built for Node-RED. They are both single-page apps that use complex frameworks. This means that all of the apparent "pages" are simply showing different content within a single page. Because of that, trying to have different "pages" with different users becomes complex and hard to deal with. UIBUILDER does not need that restriction. You can build a single-page app, a multi-page app, or multiple single-page/multi-page apps or any mix. In your case, simply create the form as a separate page (you can have multiple pages even with a single uibuilder node or you can even use multiple nodes if you prefer). Now, each page requiring separate authorisation is already a separate web "endpoint". So if you use an external tool to manage security, each page can be secured differently. And you can maintain a single user db for all pages. There are lots of tools you can use for external security. Most revolve around the use of a reverse proxy along with an integrated security tool. For example using NGINX as a reverse proxy integrated with Keycloak. Alternatively, a cloud version of Node-RED such as the one from FlowFuse may take care of security for you. Also, Cloudflare Zero Trust which effectively provides a cloud-based proxy with integrated security. Recent versions of UIBUILDER have integrated recognition of common proxy and security headers to make it easier to build authorisation flows in Node-RED. With UIBUILDER, you can even change its settings to use a separate instance of the ExpressJS web server to the normal Node-RED instance. This would use a separate port (which might make proxying a bit simpler) and could be then secured separately to the rest of Node-RED. Now, I recognise that this takes Node-RED from a "simple", quick solution to something more complex but once set up, the solution is reusable, scalable and far more likely to be secure than any other approach you might try with Node-RED. To be completely fair, I should say that there is, as is often the case with Node-RED, another alternative. And that is to build a separate instance of Node-RED for each separate security case. That would allow you to have multiple instances of D1 or D2 as well (each instance of Node-RED can only contain a single instance of each Dashboard, there is no such limitation with UIBUILDER). Each Node-RED instance could have its own security. You could then create API style interfaces between the instances. The biggest downside of this approach is the amount of resource required to run everything. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This tool looks great, but I can't find how to avoid this dealbreaker: I'd like to create a form that will be filled, say, by some students. Of course, I don't want to give my password to the students… and so this is where I'm stuck: how can I let regular users fill my form without letting them interact with other UI I made, or give them opportunity to modify the code? (ideally, I'd like 4 levels: admin, teachers, students, generic non-authorized public)
Beta Was this translation helpful? Give feedback.
All reactions