Use editor path in generating localStorage keys

[mw75]

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Proposed changes

The approach reads the path from window.location in RED.settings.init(), removes the last character, replaces "/" with "-" and stores it a authTokensSuffix property. Whenever the key auth-tokens is read, set or removed this suffix is added to the localStorage key. This results i no api-changes and no changes when the editor runs in the root path and you may run as much instances as you like on a single host name.

The only, from my perspective minor, point of discussion is the the behavior, that the hole auth-tokens* "Namespace" for setting-keys gets "magic" while currently only the key auth-tokens itself has special meaning. I don't see a security issue because the sessions are initiated from the same operating system user, on the same browser, on the same computer. And as logout is still working as expected, it truly has to be the same person - so nothing is leaked when reviewing the localStorage.

Checklist

• I have read the contribution guidelines
• For non-bugfix PRs, I have discussed this change on the forum/slack team.
• I have run grunt to verify the unit tests pass
• I have added suitable unit tests to cover the new/changed functionality

[coveralls]

Coverage: 68.556%. Remained the same when pulling ed2c9d2 on mw75:master into e5d579c on node-red:master.

[knolleary]

Hi @mw75,

thanks for this. A couple notes on process, I've updated the title to describe the change (as this is what will show up in the changelogs), and I've retargetted it to the dev branch - as this is where 3.1 lives at the moment.

As I mentioned in the original issue, the proper fix here will be to move to cookie based sessions as that will be far more secure. But I can see this is a pragmatic fix, albeit within the same limits of the existing approach around the use of localStorage.

[mw75]

Hi @knolleary,
thanks for merging! Do you already know the release date for 3.1? According to https://nodered.org/about/releases/ it should already be released. I have to decide, to include that patch in our build or not. That's the reason my PR was against main.

I like the current approach because it is controlled by the implementation and not tied to browser behavior like cookies. Cookies will cross the wire also for static assets and the authentication-header is explicit meant for that use case.

Regards,
Mario

[knolleary]

I am very aware we have fallen behind the planned schedule of releases. I'm currently trying to figure out our plan moving forward - as node.js 14 reaches end-of-life this weekend, which is our usual trigger for doing the next major version bump of Node-RED.

I am wondering if we should just release what was proposed to be 3.1 as 4.0 with the only breaking change being dropping node 14 support. We can then try to get back to the planned schedule of releases moving forward.

I targeted this to dev as I feel it is more a change in behaviour rather than a simple maintenance/bug fix.