The easiest method still remains splitting into multiple Node-RED instances. Then you can put secured flows onto their own instance and you can easily restrict access to them.
If the flows are critical, you might also consider reworking them into dedicate Node.js apps and taking Node-RED out of the equation.
@krysatpat,
Thank you for your input on this item. Since I've posted on it, it seems that most of the comments are coming from an arena where they may not consider manufacturing environments where there is an Engineer/Maintenance/User environment. I get comments that are confusing the keeping of areas off-limits as an insult. So, we are doing this by having to maintain at least 2 instances of Node-RED per machine. This is also very good, but it is dependent on an internal conversation between the instances and the use of a MQTT broker. This adds a bit of complexity to the program, but it does exactly what I need. Once that hurdle of getting things working and having a script to deploy the process it is actually very simple to maintain.
Since the security measure I proposed brings with it some complex issues which make that discussion a much higher one, I would like to keep alive the topic of Flow Tab Filtering. If we can do this, it may be an easier means to keep people focused on the tabs they are needing to get to without having them flip through areas where they may mistake or make changes in areas they should not by improper troubleshooting techniques.
Concept: Opening up YOUR target flows or your Defalut Filter option by configuration would essentially do this. You can by your login name, use YOUR default filter to get where you need to go. Then as you are "administrator" vs. "Technician", also elevated privilege, define what series of tabs you need. You can always override the default simply by voiding the filter field.
I have very involved programs using tabs to organize programming and message values. It makes GOOD SENSE to be able to further organize your programming experience by filtering out your FLOWS. You have the option to filter out the node palette.... You can also filter out your debug messages.. Why not the flows on the top of the page? If I want to target flows for UI, screens, Input Sectional logic, Functional sectional Logic, Output Logic, Output Screen logic, I/O, Devices, it makes sense to use your naming conventions to allow you to target your program so it's easy to limit tabs you see.
While this sounds like a simple concept, in terms of Node-RED (or indeed similar systems), it really isn't.
You must think well beyond tabs if you want any meaningful security here. Partly this is because the back-end of Node-RED is written in Node.js, JavaScript, and that is pretty open by design. Partly because Node-RED is currently set up with a single folder structure and this would certainly not be secure. And partly because Node-RED is an open development platform with potentially several different routes for users to access the underlying OS and file structure.
I don't believe that anyone doesn't want Node-RED to be secure enough for the type of use you mention. However, with limited development resources, decisions have to be made about priorities. Hitachi made that call and put people onto helping with development. Other organisations not so much.
@TotallyInformation,
Great to hear from you again. I am considerate of what it would take to do the security. I have run up against different angles of attack. With further consideration, I'm not convinced that the initial concept of security levels would be the best answer. It leaves more issues to consider than I believed at first, and is too specific to be widely accepted.
And so Security is one way to view this. However, maybe the security approach will be too complex for the overall end result. I had hoped that it would be better received. It's not.
Maybe Flow Filtering is what would be useful for many, and especially if there are those who find themselves hunting around for the flow in debugging or flow program forming. The side view does help to skip to your programming area. Could that be filtered/greyed out or displayed differently to do the same purpose? Maybe this discussion can help better define what is a help for the editor.
@TotallyInformation,
More on the security option. I must agree. The levels of "Security" in this case are really not that secure because of what you are indeed saying about the file structure of the system. For this reason, I have never considered keeping people out if they really wanted to break in. You would have little trouble doing so. Normally, we are looking at what is available in front of us. Of course, you can go into the folder to muck around.... I'm really assuming most if not all of the people on our staff just won't go that far. And they don't. They do not have the time and do not want to really be responsible for messing it up. That's been 100% the case for a very similar system that uses scripts for it's system programming. The folder is right there and you can go into it and modify the code. Nobody has done this at our site in the last 10 years for us to have to worry about security. We can lock down the folder, but it's a pain to edit files when we need to. Typically, for good or bad they are left available to do text editing. The files are not defaulted to open with notepad.exe or any editor. So you cannot just open the file unless you are aware that you can.
That being said, this is a similar approach to the "security" element which is really not "Secure" at all. I was thinking of it as a means to steer folks by the level of the access. Definitely not "keeping" them out.
With our multi-instance approach, I have a key folder on the C:\NR... . I have just that folder hidden and then the install folder, "Main", the operative instances "Core" and "Tech" folders for each instance defined. This way you cannot browse to find it in Windows. (That is if you have not modified File Explorer to do so...) and that is the security model which we'll probably keep.
Well I am certainly not the expert on the Editor but it seems pretty flexible to me. So I expect something could be done in that area if someone were to find the time to do it. As long as people recognised that it was more a convenience thing than actual security. Anyone with enough knowledge could, I suspect, pick apart the Editor and do whatever they wanted. Only through separation of concerns can you really add solid security to something like this.
Then I think you need to change the name of the discussion 
If you are talking about simplifying areas of the Editor in order to make life easier for end-users, that's a bit of a different conversation all together. Unfortunately for you, the nature of my professional work means that I will tend to be quite direct when it comes to security.
But as a way to help users and to keep them directed and focused on their own flows, the ability to hide tabs would certainly be a good way and probably fairly easy to achieve given that the Editor is "just" a web app. Indeed, I bet you could do it manually yourself just using the browser's dev tools. Slightly more complex I would think to filter out in the information sidebar.
Editing the editor, Now that is interesting... Perhaps more on this topic later in another thread as you implied.
Here we go:
There seems to be enough uniqueness there to hang some code off.
This is the sidebar entry, definitely more challenging but possible I think:
"All" you need to do is to work out:
@TotallyInformation ,
I would be happy with just the top tabs filtering. The side tabs I'm sure will not be a problem because we are after "Steering" vs. "Security" in this topic. We (us here) could certainly get that later if it became necessary.
I look forward to seeing your code submission 
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
