following README: initial login credentials not recognized

[srsudar]

(Originally posted on #4826)

After getting everything set up, npm start appears to succeed. No obvious errors.

I can curl couchdb with my credentials successfully:

curl -X GET "http://localhost:5984/_membership" --user admin:<password>

Navigating to http://localhost:5984/medic/login, I see the Medic login screen. However, using the same credentials that succeed on the command line (admin and <password>), I get directed to http://localhost:5988/admin/. The page says only:

{"error":"unauthorized","reason":"Authentication required."}

This really, really seems like a typo on my part, but AFAICT I'm typing the password correctly.

In my first setup I had an issue where my password included an @, which made it error when setting up configuration (it thought I was trying to access something like @foo@localhost), but I uninstalled couch and reconfigured successfully. And as I mentioned, I can query couch successfully. Is it possible I have a vestigial password hanging around somewhere? Maybe in a document in couch rather than in its own configuration? I would have thought that sudo apt-get remove couchdb && sudo apt-get purge couchdb would remove all the old state.

Is this behavior expected under any other circumstances?

Environment:

Ubuntu bionic

[srsudar]

I found a fix for this. After reinstalling couchdb, it turned out that after one successful login I was getting the same error as above. But I could log in repeatedly with an incognito window!

I tried deleting cookies via the info badge in the omnibox. That wasn't enough--I was still encountering the problem. After going to site settings and deleting all of my localhost cookies in the :598[0-9] range, and restarting the app with npm start, I now seem to have solved the problem. (It is possible that I left a tab open and thus the bad cookie wasn't really deleted in the info badge approach; I am uncertain.)

Previously, when looking at the medic UI, I was getting a regular dialog saying that a new version of the app was available. Clicking accept didn't seem to do anything (but this may have been in one of my cloud instances rather than at localhost, I do not recall).

However, I now seem to be having no problems. So I think that I had cookies or localstorage from different installs that were conflicting. I would call this issue resolved, but I'm going to let one of the maintainers close it so they can ACK it in case this rings a bell that a cookie auth assumption should be double checked.