Node-RED Development Team:
Within Node-RED, I would like to create a base system with a few flows that are not accessible for Technicians, but available for Engineering. These flows logic are to host the UI and functions, configuration flows, and those that otherwise should not be changed. Can it be possible to assign flow tabs a password or otherwise login level permission? Or do I just give the whole environment the same level of access?
Thank you
Currently, it is really pretty much all or nothing.
You might want to look at running multiple instances of Node-RED, each with its own security then link them together via MQTT, TCP, HTTP, etc.
Login level permission can be configured as explained in the docs. You can configure different users in AdminAuth in the settings file and assign them different permissions (read-only or all). However is like Julian said, this is not configurable per TAB. It is all or nothing.
I would like to submit this as a FEATURE REQUEST.
Tab Permissions to tighten security on the Flow Tab level.
SHOW/HIDE or FILTER FLow Display ... with Permissions, or some means.
@TotallyInformation and @Andrei, Thank you both for your comments.
@TotallyInformation, The main display and configuration system pages (system 1) with the flows should comprise the base system. The configuration can be conveyed via an xml file to host configuration changes made by system 1 to the channel system (system 2). There are channels which connect to devices which could be on the lower security level. Each channel data should be conveyed to the main display instance and update the page via MQTT. This is certainly something to think about. Thank you for your advice.
If I had a means to filter flows by a default setting, name, function, or other, this would be helpful and allow for organization of flows. This may be something worth the development team to look at for a new and useful feature. Maybe by "permission" is not necessary.
You can filter and organize nodes, why not your flows?
Kind Regards
Hi, did anything come of this?
As I become responsible for more (node-red) integration I find scenarios where I would like to lock down a TAB but permit another user (e.g. 1st line 24/7 support operator) to log in & view/debug the flows and perhaps even allow modification of permitted tab(s).
Mock scenario - support member could view and operate debug/injects on TAB1 but not TAB2 however via permissions, he can look at and inspect TAB2. If so permitted, could be permitted to modify TAB1...
Another scenario I face - I write the complex logic and processing on 1 TAB (this must be locked down to protect the process) but there is no reason a support member cannot be permitted to add items to a setup (change node) e.g. fill in a list IP addresses to poll on separate TAB. Yes this could be completed on a separate instance and transmitted via HTTP/MQTT etc however the added complexity and components somewhat muddy the waters.
Is there anything in the works or under consideration?
I do realise this will be quite involved and require much more thought, discussion and consideration than my 20 minutes preparing this response this but I am interested to know if this is something under consideration or currently in development?
Cheers, Steve.
inner voice / thoughts...
I realise much of this could be achieved by a dashboard or MQTT/HTTP to external application however, node-red itself is a very good tool in terms of visual comprehension and being able to see where a problem stems from (chasing the debug messages) can give a greater insight to the issue at hand
It is not something in active development, but the general requirement (having finer grained permissions in the editor) is something on the backlog.
I have written a side-panel (tab) that lists all the flows. In regard of each flow's name are one button to lock the flow and another to hide the flow's tab ... clicking on a flow's name would display it (even if its tab is hidden) ... the flow tabs are hidden using CSS ... the locking feature is also using CSS preventing any edit ... this plugin was never released because I didn't find the time to remove all the (small) bugs but despite it does not have associated user rights (if a flow is locked, it is locked for all users -- and any user can unlock it) it kind-of worked though ... also it has the advantage of presenting the flows in a vertical list which is much easier for navigation ...
At one time I wanted to include a tree structure as well (any flow's name having a "/" in it would create a branch) but didn't find the time ...
anyway, maybe this can give some ideas ? (I believe there's a screenshot of my plugin somewhere in this forum ... )
We would be very interested in an approximate date that your team could apply the permissions in the editor. Kind Regards,
As Nick said above it is a known item on the very long backlog and is not under active development at the present time. Without any design consideration it would be foolish to even guess at an approximate date at the present time.
Hi @tree-frog,
To add to what Dave replied, you ask when 'your team' can deliver it. Please understand there is not some huge team developing Node-RED. There are maybe one or two people working on Node-RED at the level of detail that this feature needs. Given the size of the backlog and the items we are currently thinking about being priorities, it would be the towards the end of the year at least.
If this is a feature you have a particular interest in - and it sounds like you have more than a casual interest here - the best thing you could do is consider whether you are able to help make it happen in some form.
That could be by providing more details as to what your requirements are. It could be by helping write up a design document for it with us. It could be by deciding its important enough to whatever you are doing that you can make some code contributions.
Otherwise, it will happen as and when we get to it.
Nick,
I'm very glad that you are at least considering it. Nobody here demands anything from you. I don't believe that anything I suggest was in the least bit demanding or unsympathetic to your workload. It was simply a question.... If it did seem that way, I urge you to reconsider. "the end of the year at least." is as good as any answer. I am very happy with it and look forward to the next version with whatever is available. That being said, I don't believe any suggestion is worth making you or anyone defensive. Please accept my deepest sincere apology.
I would like to help with this feature, since I'm also interested on it. Please let me know how can I help designing the document for the feature, and then I can also help with the coding.
Welcome to the forum. Just to let you know that is the UK school 1/2 term holidays over the next week or so. It is possible that people might not be around to respond. Please don't be put off, if nothing happens, try posting again in a week or so - maybe with a new post suggesting what you might want to do to help.
@gmerciel as Julian says, I'm going to be on holiday for the next week. I'll still be around now and then, but not really in a position to get into deep design conversations.
This this particular feature, we're more at the requirements gathering stage. This is why I was hoping @tree-frog could provide some more insight in their requirements for this.
There are lots of potential uses for it, so we need to make sure we've captured a good set of use cases that we can validate any design against.
At this point, I don't have a good sense of how this would work - how the permissions would be set and managed, whether they become a property of the flow itself or not, how fine grained the permissions need to be and lots of other questions.
Once I'm back from holiday, we can certainly start to kick around some ideas - just be aware this feature isn't a high priority one and there's plenty of other things that are more important to us right now that need my time/attention.
Great! Just let me know what I can do to help. I'm a big fan of Node-RED and I would love to contribute!
@knolleary,
Our current need is an industrial iot application. The system needs to talk to PLC's, and SQL databases, output files, pretty much the gambit of an industrial monitor and data collection application. The app is currently in a C++ environment and it has a scripting language that is custom. Modifications are typical and I was searching for an alternative which the "scripting" could be simplified and replaced by some sort of graphical programming. With Node-RED, it seems to offer almost a perfect fit and enhance it with multi-station user interface and remote debugging and programming. The interest in the tab level security is that the base of the program needs to have a CORE administrator level, which defines the app and user interface. The second layer needs to have "Engineering" level access and then possibly a layer for "Technicians", then Operator is the default open level. If at all this kind of layers specific to tabs, for instance would allow us to deploy this in plants which do not have or need direct CORE level or "Engineering" support, but do allow the 3rd and 4th layers to access and configure all of the channels to support adding barcode readers/printers/weigh cells... and the logic for each. I have designed a beta using Node-RED for proof of concept so far. We are in load testing device connections and reliability now. Our next hurdle would be the security requirements. There may be options which would include a base program written in some other language and utilize Node-Red API for the device connection and logic layer. However, using a completely Node-RED environment is attractive.
I expect you've thought about this but what about having more than 1 instance of Node-RED? Perhaps one for each level?
Then you can easily enforce separation between the layers - even at a networking level if required. You would of course need to think about communications between them but that is rarely a problem for Node-RED given its ability to talk over many different protocols.
Yes, Multiple Node-RED instances. Thank you for that suggestion. We are now in the process of using the current C++ environment which can be installed on Windows 10 and integrating it with Node-RED in the background and using TCP/IP to update the user interface. This perhaps is a variant where you can have a user interface and base level app then connect to it's pre-configured interface much like our paradigm has been defined.
Thank you for your insight and suggestion. However, I do believe that the system would benefit from having layered security if you could user define the tabs to be hidden and accessed with a hashed user access defined in the system configuration.
My simple question would be how to separate independent instances of Node-RED. Can this be done without using Docker or another VM. Can you run independent instances of Node-RED on a single computer?
I'm certainly not disagreeing with your desire or that perhaps NR might benefit from that enhancement. Only suggesting a possible alternative. Indeed, I would - with my IT Security hat on - say that separated instances are very likely to be significantly more secure. However, that has to be balanced by resource use and maintenance/administration complexity. As so often with IT, there is no single "Right" answer only ones that fit best with your resources, knowledge and needs.
Most certainly you can run many instances of Node-RED on a single device. You could spread them over multiple devices as well of course.
You can even run multiple instances on different version levels if you needed/wanted to.
If you are happy to always use a single version, you can continue with a single, global install of Node-RED itself and set up multiple services that call Node-RED passing in different --userDir parameters. This is actually somewhat easier to do on Linux but certainly possible on Windows as well.
If you want to have the option of different versions of Node-RED, check out my alternate installer repo on GitHub. You don't have to use that but it certainly shows you how to have local installs of Node-RED. On my Windows 10 dev machine for example, I often keep multiple instances including one that is completely "clean". This enables me to run different tests on different setups and even different versions of Node-RED.
Docker, of course, is another way to achieve the same thing but rather more complex. You get better local separation with Docker but at the cost of higher resource usage and more complex administration.
One last thought. The main thing against running multiple instances is resource utilisation. You will need to check how much spare resource a machine has in order to ensure that you don't get slow-downs or even crashes.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
