Couchdb: 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:[email protected]: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 https://github.com/apache/couchdb/issues/2730#issuecomment-606291265, 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 https://github.com/apache/couchdb/pull/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

[rnewson]

You say you want the 2.0 behaviour in the same comment as saying "opening it up would be a bad idea". We agree, that's why the default in 3.0 is secure (admin only).

This decision was taken consciously by the CouchDB project, you are invited to post your thoughts to the couchdb user or dev mailing list to reach the full team about this.

And a reminder to stay polite, we don't need pejoratives like "lame" and "draconian", especially when we're only discussing a new default for something you, as a couchdb administrator, are in full control of and can return to the 2.0 setting in a single request.

[rnewson]

https://github.com/apache/couchdb/blob/master/rel/overlay/etc/default.ini#L76-L77

[dholth]

@rnewson in that case the question is what is the correct _security object for the _users database to get the 2.0 behavior, since it also has "special" users-can-read-their-own-documents-only permissions? The documentation, still assuming the 2.0 _security, should be updated.

[dholth]

Documentation for the 2.0 behavior. Technically not wrong given the totality of the docs, although it should be updated to say "by default _security means users may not access documents they own"

https://docs.couchdb.org/en/stable/intro/security.html?highlight=org%20couchdb%20users#authentication-database

• Only administrators may browse list of all documents (GET /_users/_all_docs)
• Only administrators may listen to changes feed (GET /_users/_changes)
• Only administrators may execute design functions like views.
• There is a special design document _auth that cannot be modified
• Every document except the design documents represent registered CouchDB users and belong to them
• Users may only access (GET /_users/org.couchdb.user:Jan) or modify (PUT /_users/org.couchdb.user:Jan) documents that they own

[rnewson]

1. set [couchdb] users_db_security_editable = true in local.ini
2. change security object of _users db to an empty object (the 2.0 default)

curl foo:bar@localhost:15984/_users/_security -XPUT -d '{}'

to restore the default behaviour;

➜  ~curl localhost:15984/_users/org.couchdb.user:rnewson -XPUT -d '{"type":"user","name":"rnewson", "password":"wibble", "roles":[]}'
{"ok":true,"id":"org.couchdb.user:rnewson","rev":"1-be4d8b78890e9a4dc7fdb6daf712ea67"}

➜  ~ curl localhost:15984/_users/org.couchdb.user:rnewson
{"error":"not_found","reason":"missing"}

➜  ~ curl localhost:15984/_users/org.couchdb.user:rnewson -u rnewson:wibble
{"_id":"org.couchdb.user:rnewson","_rev":"1-be4d8b78890e9a4dc7fdb6daf712ea67","type":"user","name":"rnewson","roles":[],"password_scheme":"pbkdf2","iterations":10,"derived_key":"e654649d2d3aa9b0dea54d89a942a42c2f7ccb37","salt":"53a8ad5802e6c1d0a59090b6d52d7aa1"}

[hawkrdg]

I mean no offense to any on this thread. The manual (1.5.2. Authentication Database) says a user should be able to retrieve their own record - doesn't happen out of the box. Having the correct info in the manual would have saved me and others hours as well as a bunch of open issues. It isn't simple as the default install will not let an admin modify _users security. I had to dig through default.ini to fine the correct setting.

[wohali]

@hawkrdg We're a volunteer-run project with limited time. We got the update into the release notes, but obviously there are other places that need documentation updates.

Please help by opening a pull request against our documentation repository and pay it forward? Thanks.