Changing password for a user with non-standard password hashing function fails

[michaelklishin]

See this thread and this report by @carlhoerberg. So the issue is not rabbitmqadmin or definitions import-specific => moving here.

[michaelklishin]

@carlhoerberg with the tip of stable at least, I can't reproduce with the following steps:

• Start a 3.5.7 node, add a user server-623 with password "server-623"
• Tag the user as administrator
• Stop the node, copy its database directory to /tmp/3.5.7
• Start a 3.6.x node with RABBITMQ_MNESIA_DIR=/tmp/3.5.7
• List users with ets:tab2list(rabbit_user).
• Change password with rabbitmqctl change_password server-623 server-623-new
• Try authenticating with rabbitmqctl authenticate_user server-623 server-623-new (it succeeds)
• Try authenticating with rabbitmqctl authenticate_user server-623 server-623 (it fails)

Are the steps I take different from yours?

[michaelklishin]

Some digging with

git diff rabbitmq_v3_6_0..stable -- src/rabbit_auth_backend_internal.erl
git blame -- src/rabbit_auth_backend_internal.erl

suggests it was fixed in f1f28ea by @hairyhum.

[michaelklishin]

Assigning to @hairyhum because he fixed the issue as part of rabbitmq/rabbitmq-management#117.

[edmorley]

I think it would be good to add a test for this, since this caused breakage for our Heroku app, after updating to 3.6.0 and using our managed rabbitmq instance's "rotate password" feature.

Shall I file a new issue for adding the test?

Many thanks :-)

[michaelklishin]

@edmorley I'm afraid adding a test that uses two different database schemas (from 3.5.x and 3.6.0) is going to be quite hard.

The best I can think of is manually injecting a user with a non-standard password hashing function. I have no objections to having an issue for that.