The issue has been solved but it was a little multifaceted than initially thought. The problem is something that has been identified and posted about in the GitHub repository in the post quoted by @sanjay sir above. This is an issue that existed in CHT version 3.x and was extensively discussed in the github issue here.
To explain briefly, the problem occurs when you attempt to update the password for the user medic
. Once you press submit on the Change Password
dialog, it displays an error as shown below.
Note: The image was pulled from here, since we didn’t get a chance to snap a screenshot when we were working on it. If you keep pressing submit after this, it says error saving changes.
After this, the system stops working entirely. You cannot login regardless of which password you use, the new password or the old password. Our solution involved restoring the original password to medic to get the system working at least.
First idea was to change the password using the local.ini
file inside /opt/couchdb/etc
as stated in the community post here. But even after adding medic = OldPassword
under the [admins]
section and restarting the cht_couchdb_1
container, it was not getting hashed or updated like it was supposed to. If anyone has an idea on why this approach was not working on CHT 4, please reply to my comment on the post.
Second idea was to update the user document using the instructions on the CouchDB documentation. This approach required us to fetch the user document from medic using curl and use the rev
to update the document. The following query was used to update the document but ultimately failed.
curl -X PUT http://medic:NewPassword@localhost:5984/_users/org.couchdb.user:medic \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"name": "medic", "password": "OldPassword", "roles": ["admin"], "type": "user"}'
After running this command, it does show the expected result as shown below:
{"ok":true,"id":"org.couchdb.user:medic","rev":"x-xxxxxxxxxxxxxxxxxxxxxxxxx"}
But even with this response, the password was not updated. The same issue persisted.
Third idea and the one that really worked was to follow the suggestion mentioned by latin-panda
on issue#6986. We used the node couchdb@127.0.0.1
and the following command:
curl -s -X PUT http://medic:NewPassword@localhost:5984/_node/couchdb@127.0.0.1/_config/admins/medic -d '"OldPassword"'
This worked exactly as intended in our local test instance but failed to work on the actual server.
Note: The command above will revert the password to original, if your intention is to get your server up and running quickly, this is the best option. Remember to replace NewPassword and OldPassword with whatever you used in your case.
If the command worked correctly, it will output the hashed and salted version of the password like this:
$ curl -s -X PUT http://medic:NewPassword@localhost:5984/_node/couchdb@127.0.0.1/_config/admins/medic -d '"OldPassword"'
"-pbkdf2-2d86831c82b440b8887169bd2eebb356821d621b,5e11b9a9228414ab92541beeeacbf125,10"
In our actual instance this did not happen and the password was not changed. The reason behind it was special characters. In our new password, we had special a character, ‘@’. This caused the URL to be misinterpreted by the curl
command. To remedy this, we used URL encoded version of ‘@’ which is ‘%40’. So the command in the end for password ‘P@ssword’ would be as follows:
$ curl -s -X PUT http://medic:P%40ssword@localhost:5984/_node/couchdb@127.0.0.1/_config/admins/medic -d '"OldPassword"'
Finally this was the solution that worked and helped us get our instance up and running.
Note: For CHT 3.17.1 deployments, we have been using special characters in the password. It works in the ‘cht’ command without any problems if we simply put the password inside double quotes but that approach did not work in this case.
# Does not work
curl -s -X PUT http://medic:"P@ssword"@localhost:5984/_node/couchdb@127.0.0.1/_config/admins/medic -d '"OldPassword"'
# Works in CHT 3.17.1
cht --url=https://medic:"P@ssaword"@localhost --accept-self-signed-certs
There are still a few unanswered questions which our team will do some research on. We hope that this bug will get patched as soon as possible or at least the option to change the medic password from the Web UI will get removed.