Updating user password via management UI sometimes displays a "not authorized" error but the password is updated after all

[yoelgal]

Describe the bug

When you try to update your password in the rabbit mq dashboard, it will say "not authorised", and you have to refresh the page and sign back in with the new password.

It should give an appropriate confirmation, and/or instructions on what to do next (refresh the page)

Reproduction steps

1. Sign in to dashboard
2. Go to admin panel, and try to update your own password
3. See "not authorised" popup message
4. Refresh page and sign in with new password to see that it has been updated, even though this was not confirmed
   ...

Expected behavior

When the user successfully updates their password, it should give an appropriate confirmation message, and perhaps include a button that links back to the sign in page, rather than the user having to refresh the page themselves

Additional context

No response

[michaelklishin]

@yoelgal we do not guess in this community. You haven't even mentioned what version you are trying with, and what permissions, tags your user has.

I cannot reproduce with a user tagged as administrator on a 4.2. node.

It can be that the UI has updated (using the old credentials) concurrently with a password request. A request with previous credentials will fail as "not authorized" immediately after credential changes.

[JoeriGithub]

@michaelklishin I also encountered this bug on a completely new install using newest rabbitmq-server-4.2.4 windows installer.
After setting up the management plugin and going to the localhost management page the first thing I tried was changing the default password of the guest admin account, and this is when the described bug occurs.

[michaelklishin]

@JoeriGithub that's what I did several times and I cannot reproduce.

My best guess is that it is a condition where the UI runs into an exception that it considers to be an authentication failure, which wasn't actually the case.

Can you reproduce this repeatedly? Can you see if there were any exceptions in your browser's Developer Tools?

[JoeriGithub]

I am able to reproduce this bug repeatedly.

I see an 401 unauthorised response.

[michaelklishin]

@JoeriGithub thank you, I think I know what's going on right from the screenshot.

Overriding Default User Credentials and Configuration Value Encryption provide a secure workaround,
plus a definition import can be used to import N users with pre-configured credentials at node boot or on a running node.

Why is the Error Displayed?

There are two competing requests, one updates the password and the other that updates the users page (table) but happens to use the original credentials until the other request completes.

Not sure if there'd be a short term solution but by 4.4.0 the UI will be modernized and that would be a good moment to make sure such competing requests, responses do not produce the confusing message.

[michaelklishin]

@JoeriGithub sorry but so far I only see various short term solutions that are hacky or equally confusing (or both):

1. Respond with 200 OK to any authentication failure within N seconds after a password for user U was changed, given that a special header is set on the request (hacky)
2. A variation of 1 but with a whitelist of endpoints, namely GET /api/users (still hacky)
3. Sign the user out after updating credentials (equally confusing)
4. Trick the UI to disable auto-updates for N seconds specifically for one form or two (least hacky, no dubious server changes)

plus a few more variations of 1, 2 which aren't meaningfully different.

So maybe the current answer — preconfigure the default user password — is the best option for now.

[deadtrickster]

We are in control of the refresh loop/timer. Can be cancelled till reply comes.

So, to clarify - when user hits Password update, we enter special mode, when all requests stop or cancel. If cancel not possible - ignore replies. When confirmation received - unfreeze.

[michaelklishin]

I ended up with something similar #15728