Misleading error message after restart?

General
1

image
image373Ă—117 7.1 KB

The above is after several restarts and even Editor page reloads - the display shows that the user called "read" is logged in but not only should they not be but it appears that they actually are not.

image

2

Aren't the tokens signed and timed - I'm not sure of the mechanics it uses?

3

Well, I'm realising I knew even less than I thought. But I can say for sure that Node-RED logins do not behave how I would expect them to work.

4

I think the large webscoket interaction may have a role to play here.

  • sometimes. - I get a login window appear over the top of my rendered flow canvas, when visiting the workspace
5

I normally ignore Node-RED's login but I've had a request to make some improvements to UIBUILDER. As you know, my usual advice is to use an external IdM tool.

6

On marcus' question: the editor tokens aren't signed or timed in the JWT sense. Going by the editor-api code in 5.0.x:

  • On login Node-RED creates a random token (crypto.randomBytes(128)) and keeps the session on the server. The browser keeps the token in localStorage under auth-tokens.
  • The sessions are written to .sessions.json in the userDir and loaded again at startup, so a restart doesn't log anyone out. That's by design. A session only goes away when it expires (adminAuth.sessionExpiryTime, default 604800 seconds = 7 days) or when the user picks Logout, which posts to auth/revoke.
  • On each request the token is looked up and the user is then found by name in the current adminAuth.users. If that user no longer exists, the token is rejected. But the scope comes from the stored session (done(null, user, {scope: token.scope}) in strategies.js), not from the user's current permissions. So if you change the read user's permissions in settings.js and restart, an existing session keeps the scope it had at login until it expires or is revoked.

If you want a restart to log everyone out, stop Node-RED, delete .sessions.json and start it again. A shorter sessionExpiryTime limits how long an old session can live.

(Disclosure: I'm connected to thirds.ai.)

7

Many thanks for that detail, very helpful. It make sense and reinforces what I've always said - use a proper external IdM tool to correctly enforce authentication and authorisation.

I that case though, I think there may be a bug?

Because while the Editor shows that the user is still logged in - I'm not sure they are?

Or, at least, the error message may be misleading. It is possible that the user is logged in but not permitted to access the settings since they only have "read" access? If that is the case, the message needs updating to say something like:

You must be logged in with appropriate access to access settings
8

Renamed this thread for clarity.