403 accessing _users

[hawkrdg]

just installed v3.0 and can't get a logged in user to access their doc

test:

C:\Users\cliff>curl -X POST http://192.168.1.25:5984/_session -d "name=sally.user&password=pw"
returns
{"ok":true,"name":"sally.user","roles":["user","supervisor"]}

C:\Users\cliff>curl -X GET http://192.168.1.25:5984/_users/org.couchdb.user:sally.user
returns
{"error":"unauthorized","reason":"You are not authorized to access this db."}

this is a basic install of v3.0. I created server admins, then created _users table in fauxton. Added users in the usual fashion and the docs seem fine. I ran into this building a login component in angular. I get the same result using angular's HttpClient - login works fine, GET after logging in returns 403. Angular's HttpClient has withCredentials = true as an option, and this has been working fine in couch v2.3

I have tested this against require_valid_user both true and false - same result.

any help would be appreciated here: am I doing something lame...? Do I need some configuration set...? Or is this a bug...?

[natcohen]

You can't get the user if you re not logged in...otherwise anyone could get your users!

Try this: curl -X GET http://admin:password@192.168.1.25:5984/_users/org.couchdb.user:sally.user

(if I m not mistaken, you can also use the username and password of the requested user)

[dholth]

I am having the same problem in CouchDB 3 but it works in CouchDB 2, but I am setting the username using proxy authentication. #2734

[hawkrdg]

I should note that I am running https on the server but this should not matter one way or the other.

the simplest test - fauxton - login as server admin, open a new browser tab and try https://couchurl:6984/_users/org.couchdb.user:someusername - this works 200 in devtools
logout of fauxton and log back in as someusername, go back to the other tab and refresh
http://couchurl:6984/_users/org.couchdb.user:someusername - this doesn't work - 403 in devtools
logout of fauxton and log back in as a server admin, go back to the other tab and refresh
http://couchurl:6984/_users/org.couchdb.user:someusername - this works 200 in devtools

I can't resolve this and don't understand closing it. I am SUPPOSED to be able to get my own user record, just like in v2.x where it worked just fine. I have tested this using curl and using my angular http couch wrapper. Still fails and the new docs don't cover this. Is this a design change that only server admins can access any part of _users - sure makes it hard for a user to change their password.

[dholth]

Pretty clear that it's a bug IMO

…

On Mon, Mar 30, 2020, at 6:46 PM, cliff wrote: I should note that I am running https on the server but this should not matter one way or the other. the simplest test - fauxton - login as server admin, open a new browser tab and try https://couchurl:6984/_users/org.couchdb.user:someusername - this works 200 in devtools logout of fauxton and log back in as someusername, go back to the other tab and refresh http://couchurl:6984/_users/org.couchdb.user:someusername - this doesn't work - 403 in devtools logout of fauxton and log back in as a server admin, go back to the other tab and refresh http://couchurl:6984/_users/org.couchdb.user:someusername - this works 200 in devtools I can't resolve this and don't understand closing it. I am SUPPOSED to be able to get my own user record, just like in v2.x where it worked just fine. I have tested this using curl and using my angular http couch wrapper. Still fails and the new docs don't cover this. Is this a design change that only server admins can access any part of _users - sure makes it hard for a user to change their password. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2730 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABSZEURKBCJAAVHUMSGB5DRKEOODANCNFSM4LV3MZUA>.

[hawkrdg]

I agree with dholth - I just finished up a nice angular login drop-in component that works with material theming. I have commented out the 'change password' part and guess that's where it will stay until this is fixed. Natcohen's comment is not where I would go: posting to _session logs you in and you stay logged in until you either timeout or send a delete to _session.

[rnewson]

will check this over in the morning

[rnewson]

noting that the original comment is mistaken. the first POST has no bearing on the subsequent GET unless you omitted the curl params to save and load cookies (-c and -b). more in the am.

[rnewson]

Hi,

After double checking the release notes, this is a deliberate change.

All databases are now set to admin-only by default as part of #2339.

You can change this back on a per database basis if you wish.

[rnewson]

(release notes here: https://docs.couchdb.org/en/stable/whatsnew/3.0.html)

[hawkrdg]

Yeah, I get the change for other DB's, no problem - we just edit security and add some roles BUT we aren't allowed to edit security on _users and opening it up would be a bad idea.
SO how is a user supposed to change their own password...?
IMO this is a lame change and will certainly break any existing app that allows a user to change their own password.

[hawkrdg]

Adding to this:

_users had always been a rather special DB. Letting users have access to only their own record allowed app designers to keep extra info there like a profile which could be mined for say marketing or company policy.

I would hope that the couch designers will reconsider what IMO is a draconian change to behavior we have been using for years