@TotallyInformation,
Your insight is, as always, beneficial. To clarify, I cannot tell if this feature is difficult or not. I have the utmost respect the development team and their time. I am simply a "user" and my needs are unapologetically selfish. I will take your advice in the meantime and discover how to install at least 2 instances of Node-RED in order to try this approach. Thank you for your kind advice and time to help me find a solution and explore Node-RED.
While I'm at it. We are probably going to use VUE and the uibuilder contribution. There is a need for a fixed size on the UI screen. As far as I can tell, Node-RED Dashboard does not offer an easy way to put all items on a page in a fixed size frame that does not change the page items when someone may re-size the page. I need to have it fixed. I would like to stop Items moving on the page on re-size. Or is my best option to use uibuilder? Or am I again, in a box?
Dashboard, of course, fills a much needed position in Node-RED of being accessible with minimal to no web building experience. But like many complex frameworks, you get to a point where you "fall off a cliff" and the complexity of fighting with the framework outweighs the benefits. That is why I wrote uibuilder in the first place.
I'm no expert in Dashboard as I no longer use it for anything other than a quick output or quick prototype. However, as I understand it, the Dashboard framework is built around a "card" style interface that adjusts itself to the screen size. So I don't think you can particularly fix it in place without moving to a purely Dashboard Template based output - and that might then be easier anyway using uibuilder. I expect that Dave will chip in if I've got that wrong.
What I typically find is that, even with only basic knowledge of HTML, CSS and JavaScript, a simpler and cleaner framework with uibuilder is very easy to work with.
uibuilder comes with VueJS and bootstrap-vue (and hence bootstrap) by default - though you can, of course, replace that with anything you like. Bootstrap has a fairly opinionated way of visualising things but it generally produces pleasant looking UI's with no adjustment on a variety of devices. You can chose between fixed and adaptive widths and heights with very simple selection of CSS Classes. Reasonably well documented on the bootstrap-vue and bootstrap web sites.
I would like to contribute here on the design concept, ultimately it would be beneficial to have the permissions to be able to control the access down to the node level as well as flow level (tab), so that each individual node could be configured for read or write or no view access (to secure the function code). To the point where, if I wanted the user to only see one node in the editor to be able to change the configuration they could, all other nodes would be hidden.
It would be sort of what I would like to control as per this request, to allow the end user to edit the configuration node only, i.e. FTP server user/password when the password of a FTP server changes for periodically for best practice cyber-security.
I'm not really in a position to comment on your proposal but I can comment on this.
Best practice for identity authentication and authorisation management is to have it completely independent of your business logic. And really best practice is not to be using passwords. It is certainly not to be having passwords embedded in your business logic.
Yes that's all very well, however the ftp node has the server configuration node in it, and to use that node the configuration node needs to be configured with the server credentials?
As I indicated, I wasn't commenting on whether a change to the node might be helpful but rather commenting on best practice in regards to security for FTP (and other) servers.
There are nearly always other solutions to problems and in this case there may well be ways to transfer that data that doesn't rely on the specific node.
@knolleary, I'm curious if this feature has any traction at all? Our current plan is to have multiple instances of Node-RED running and communicating with MQTT data shared from one security level to another. This means is by your definition, the only way to have levels of security to block certain flows from being able to be seen and edited. Separating out parts of the main functionality and the core dashboard would then allow technicians whom have permission to address input/output devices and change things like IP Addresses and configuration settings common to the devices and not allow them access to core development areas. For security and simplicity. This would help uncomplicate the Node-RED editor and streamline the areas they only need to see.
If we can have Flow security, then this would allow the system to be more manageable to areas without having to share data to and from the devices via MQTT at all.
I'm just looking to get some feedback on your opinion of this request and if it is within scope of any current development.
This is very often mentioned. But you really have to dig deep into the requirement here.
â-
âI want 3 people to work on a node red instance and make sure they can by no circumstance break each others working flowsâ
You can not achieve this by authorization. You can only achieve this by version control, automated testing and ci/cd
â
âMy developers know all flows and their bits and pieces. I still just want to give them visual clues of where they should be workingâ
This can be achieved by simply naming your flows accordingly
â
âI want to hide some flows from some developersâ
You shouldnt so this, people can implement things that break each other without knowing what others created
â-
Finally i suggest you to look at software development teams. 10 devs work on the same application thats gonna run on the same server. They are usually not limited from editing parts of the code. Other measures are taken mentioned on the first example
I've lost track of how many times this type of feature has been discussed. I've said a number of times in those discussions that I can see there being place to have finer grained permissions that work at the flow level.
What I don't have is a design, specific set of requirements or anyone showing interest in helping move the feature forward.
I can certainly see the value it would bring. But I also see the value of all the other items in our roadmap.
So I don't know what else I can say at this point. It is a pretty major piece of work - not a minor feature that can be slipped in between everything else.
If someone did want to discuss specific details of how this could work, I'm happy to have that conversation. For example, how would it be configured? What does the adminAuth model look like when you have to deal with access control to individual flow resources? What's the user experience in the editor to setup the permissions? How are the permissions stored? What new runtime APIs are needed? What features of the editor need changing to support this sort of locking - for example, does this prevent a user from viewing the tab entirely? Or does it just stop them from modifying it? If its the latter - can they export and reimport a copy?
There is a huge number of questions that need answering, and the best way forward is for someone to start to put together a proposal that considers them.
@aderici,
Thank you for your input. Our requirement would be to isolate flows such they cannot be edited on Technical support level. Administrator level would have access to all flows for debug and revision control. This is not a multi-developer problem. It is a Technical support vs. development problem. In the world of manufacturing, There are necessary device configuration to the outside world which needs only technical support. This is NOT strictly development, so your model for analysis may not apply completely. We would not want to expose the whole program to Technical support for reasons not only because it is out of context, but to keep it safe and the areas of real concern obvious.
@knolleary,
Thank you for your response and consideration.
I would love the opportunity to be part of this discussion. I am going to answer these questions you pose and see if I can qualify for your time on this topic. I will also try to solicit others who can help to define criteria. If the concept is attractive to others, then it should also fit their purpose.
For now, we certainly can use the system as it is with multiple instances and separate security. I am also looking forward to the offline installer which you described in new features to come. Our production systems are air-gapped from internet access. Keeping the nodes up to date is a concern which has yet to be addressed.
I think the idea has merit.
I work with a bunch of app services that have different ways of solving the fine grained security issue.
Challenges are to make something usable 'out of the box' but configurable enough if necessary.
@knolleary, what can a nodenoob like me do to help?
Is there a specific format for a requirements / design doc? Some sample code to demonstrate POC?
@RobC ,
I'm very glad you are in this conversation. I would very much like to hear what your needs are with "flow security" to better define what would be a benefit to the community and garner support for inclusion in Node-RED.
My needs are to define by tab/flow access to the tabs. For instance these tabs are greyed out if they are disabled. I would very much like to have the tab not displayed at all if the user did not have the credentials to display it. If you cannot see it, tab to it, you cannot change it.
Security levels:
Admin - global
Access - Limits tabs exposed to changes. Deploy on these tabs only.
Read-only - Look at everything, no changes
Read-access - Look at just what is available, no changes
Then its a matter of a checkbox in the flow menu to what you as an administrator will allow for the users.
"Access Limited"
To restrict "Access Limited" users so they cannot get to this tab even to look at it, much less modify it in any way. If you are "Read-only", it will have no effect, If you are "Read-Access", you cannot see it at all but can only look at the non-limited tab/flows.
This purpose is to keep those out of areas where they are changing programming and access allows tinkering. The thought is that avoid showing these things in the first place. Then you should not get tinkering.
We should consider hacking issues. I would think for sure that administrator privileges should only allow exporting of any programs. User accounts should not have any way to download or copy JSON data from a flow period!
The purpose of read only is to read and EXPORT? then how does this prevent copying your program even if you are read-only?
Isnât the purpose âpreventing users from breaking what others have doneâ?
Since all flows will be runing in the same node.js instance, all developers should see the all flows. This is necessary to understand what global context others are defining, what libraries others are using, what http in endpoints they have defined etc.
... If you are a developer, then you'd have access to the flows anyway... The purpose is to keep certain people out of the program who could do harm ... defined by access type and a password. These folks do not document what they modify. and that's the point. Developers are not technical users, those replacing devices etc. This purpose is to simplify to the areas where technical modifications are necessary and provide this without the confusion of flows unrelated which they need to browse to find where to do changes.
Is there no room for more levels of security besides admin and read-only? If you do not need security, then do not apply it.
