From Node-RED 0.14 the permissions can be much finer grained and to support that, the property can either be a single string as before, or an array containing multiple permissions.
So I think that last one should have worked?
The following does however work which again illustrates (I think) inconsistent behaviour:
default: {
permissions: ['*'],
},
This also works:
default: {
permissions: ['uibuilder.read'],
},
So for now, the workaround is to include a default that incorporates either *, read or uibuilder.read depending on your security needs for the Editor interface.
Both should work. I didn't have time to test that last one yesterday. But then read also works as default but not for a specific user so who knows what is actually happening.
If you read the docs, it says that both a string and an array of strings are both allowed.
That is critical for fine-grained control since you are likely to want to pass several authorisation strings. If you couldn't do that, there would be no point at all in allowing things like uibuilder.read since only 1 node would ever be able to be authorised.
Just FYI:
There is also a quite serious side effect by setting the permissions on default . Credentials/login are bypassed completely i.e. one does not need to pass any credential to get the default permission.
So you are saying that you have 2 otherwise identical instances of Node-RED with the only difference being the port used and one instance uses the workaround authorisation settings correctly and the other does not?
That would surely be a bug in Node-RED that needs reporting?
Yes Peter, that is certainly true. None of this is ideal I'm afraid.
As things stand and with what we know so far, I think that there is an inconsistency with the way that Node-RED treats user-specific and default authorisation settings. Such that the assumptions about how to secure additional API's attached to the Editor's instance of the ExpressJS app server do not appear to be correct.
But I am reluctant to start raising issues against Node-RED without supporting evidence (e.g. I want to make sure it isn't just me doing or thinking something daft).
I think that we need some input from @knolleary or @dceejay at this point before I start considering other changes to uibuilder.
As things stand, I suspect that I need to change the uibindex authorisation from uibuilder.read to read. Though obviously, that gives less fine-grained control. But I would like additional input before making that change since it reduces the level of control you get over who can see the uibindex page.
Well, there is a middleware function available so it is theoretically possible to abuse that in order to extract the same data that uibindex shows you.
Truthfully though, it would probably be easier to temporarily hack the source code. The simplest thing to do would be to copy the RED.httpAdmin.get('/uibindex' function (in ~/.node-red/node_modules/node-red-contrib-uibuilder/nodes/uibuilder.js, give the URL a slightly different name, remove the RED.auth.needsPermission('uibuilder.read') (or replace it with something that works for your adminAuth configuration and then add a simple test at the top of your copied function that checks for a source IP address or possibly a URL parameter that only you know.
That wouldn't be massively secure but it would be enough to keep your users out and should be fine as long as you don't leave it in place too long.
Definitely the easiest way since it means you don't have to learn what the various variables do and why. Though if you really do want to learn that, you will find partial information on the internals in the docs folder - I recommend looking at the security branch if you want to do that since the docs are significantly improved (though still not complete by any means).
