When we introduced Persistent Context in 0.19 we also added the new Context sidebar that lets you see the contents of context.
A concern has been raised that, in some circumstances, it is not desirable to expose the values of context to the editor. For example, where
functionGlobalContext is used to provide API tokens to a flow.
This is probably of less interest to individual users of Node-RED who have full access to the system. But for those running hosted instances of Node-RED, where the user creating flows in the editor may not be the person who setup the instance and its environment, this could be an important issue to consider.
I'm looking at what options we can introduce to reduce the potential problem this brings and would like some feedback, as the approach would potential have consequences for all users.
Before describing the approach, some background to how some of this works.
functionGlobalContextis used to seed the
globalcontext object in the runtime
globalcontext object provides the
setfunctions as well as a
keysfunction returns the names of all variables held in that context object as a list. There is no indication if the value came from
functionGlobalContextor was a value set at runtime by the flow.
- the context sidebar calls an admin HTTP api to get the values. That api uses the
keysfunction to get a list of what it needs to return - it doesn't have access to any more information than that.
A propsoal for feedback
Here is what we're proposing to change:
- by default,
global.keys()will no longer return the names of properties set in
- they can still be retrieved by
- with no further changes, that will hide the
functionGlobalContextvalues from the context admin http api and therefore from the context sidebar in the editor
- a new setting will be introduced alongside
functionGlobalContextthat restores the behaviour of
fGC's key names
- the name of this setting is to be decided...
The reason I would like some feedback on this approach is because it will change the behaviour of
global.keys for everyone. That is potentially disruptive if you have a flow that relies on global.keys returning everything.
We could have taken the approach that the new setting would be used to turn off the values appearing in global.keys. That would have less potential for disruption, but we'd rather be secure-by-default and for users to knowingly opt in to their functionGlobalContext values being visible in the editor.
There is a longer term approach around the finer-grained permissions model we have in the editor - where a user could be given flow edit permission, but not permission to read context. That would help address the more general problem of context beyond just that in
functionGlobalContext - but isn't a quick change.
Please share your thoughts. As I said at the start, the issue this is trying to address is unlikely to be one many of you need to worry about. However the proposed way to solve it might have an impact.