Created users can't read or edit their own user-Information (curl -X GET http://localhost:5984/_users/org.couchdb.user:< username >).
Couchdb always print the error:
{"error":"forbidden","reason":"You are not allowed to access this db."}
I can only print/edit the information if I use the admin Account. Btw. I can successfully create sessions with the users.
I'm using Couchdb v3.1.0 on Ubuntu
I installed couchdb (v3.1.0). Created an admin account (during the installation).
After that I created a user and tried to read its data.
Try this:
curl -X GET http://username:password\@localhost:5984/_users/org.couchdb.user:username
Kindest Regards,
Bill Stephenson
On May 11, 2020, at 3:27 PM, stkeogie notifications@github.com wrote:
Description
Created users can't read or edit their own user-Information (curl -X GET http://localhost:5984/_users/org.couchdb.user http://localhost:5984/_users/org.couchdb.user:< username >).
Couchdb always print the error:
{"error":"forbidden","reason":"You are not allowed to access this db."}
I can only print/edit the information if I use the admin Account. Btw. I can successfully create sessions with the users.Your Environment
I'm using Couchdb v3.1.0 on Ubuntu
Steps to Reproduce
I installed couchdb (v3.1.0). Created an admin account (during the installation).
After that I created a user and tried to read its data.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/apache/couchdb/issues/2881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3TDEM2ODBAZPOKNEUBV23RRBNUFANCNFSM4M6HIYDA.
Doesn't work. I get the same error message. Wether I insert the user data into the URL or send the request with the session cookie.
I tried that on both my local CouchDB (2.3.1 running on my Mac desktop pc) and on my DigitalOcean vps running CouchDB 3.1.0 on Ubuntu 16.04 and it worked on both.
What happens when you try it using your admin credentials?:
curl -X GET http://Admin-name:Admin-password\@localhost:5984/_users/org.couchdb.user:username http://Admin-name:Admin-password\@localhost:5984/_users/org.couchdb.user:username
Kindest Regards,
Bill Stephenson
Tech Support
www.ezInvoice.com http://www.ezinvoice.com/
1-417-546-8390
On May 11, 2020, at 4:04 PM, stkeogie notifications@github.com wrote:
Doesn't work. I get the same error message. No matter if I insert the user data into the URL or send the request with the session cookie.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/apache/couchdb/issues/2881#issuecomment-626962626, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3TDEKR3Q6XEPECQNIEU63RRBR4LANCNFSM4M6HIYDA.
The userinformation gets printed when i use my admin credentials. (When i use my User credentials i get the error i mentioned)
I created users like this:
curl -X PUT http://<admin>:<admin-password>@localhost:5984/_users/org.couchdb.user:jan \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -d '{"name": "jan", "password": "apple", "roles": [], "type": "user"}'
Do I need to change some settings so that normal users have access to _users (their own informatitons)?
Then it should work for a valid user in the _user db too.
I’d double check the credentials I'm using and make sure the url is formatted correctly.
You can always change the password in the _user file if you have to.
Or make a test user.
—
Kindest Regards,
Bill Stephenson
On May 11, 2020, at 4:17 PM, stkeogie notifications@github.com wrote:
The userinformatiion gets printed when i use my admin credentials.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/apache/couchdb/issues/2881#issuecomment-626969823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3TDEJBSW65SYUKKRAPYOLRRBTP5ANCNFSM4M6HIYDA.
So, I reinstalled Couchdb, created an Admin Account and created a user like this:
curl -X PUT http://<admin>:<admin-password>@localhost:5984/_users/org.couchdb.user:jan \
-d '{"name":"jan", "roles":[], "type":"user", "password":"apple"}'
> Succesfully creates user jan
Then I tried to get its userinformation with the admin Account and:
curl -X GET http://<admin>:<admin-password>@localhost:5984/_users/org.couchdb.user:jan
> Succesfully returns Userinformation of Jan
So far so good. After that I tried to get the Userinformation of my own user
curl -X GET http://jan:apple@localhost:5984/_users/org.couchdb.user:jan
> returns: "You are not allowed to access this db."
The specified username and password are correct if I intentionally type in a wrong Password i get following response:
curl -X GET http://jan:wrongPasswordTest@localhost:5984/_users/org.couchdb.user:jan
> returns: "Name or password is incorrect.
Ok After setting the users_db_security_editable flag to true.
I updated the _users security object ( Bad practice) and removed "_admin" from member.roles
now everything works fine.
default Security Object:
{
"members": {
"roles": [
"_admin"
]
},
"admins": {
"roles": [
"_admin"
]
}
}
After edit:
{
"members": {
"roles": [ ]
},
"admins": {
"roles": [
"_admin"
]
}
}
Is there another Solution to this?
I'm getting the same error {"error":"forbidden","reason":"You are not allowed to access this db."}. Also curious to see if there's another solution to this.
This is a deliberate change.
All databases are now set to admin-only by default as part of #2339. This is documented in the 3.0 release notes here: https://docs.couchdb.org/en/stable/whatsnew/3.0.html
There is an open documentation bug to update the advice on the _users security changes at apache/couchdb-documentation#513.
As pointed out above, to allow users to edit their own _users document, you must change a config setting and alter the security object of the _users database first.
Duplicate of #2730 .
To confirm, it is not a bad practice to alter the _users database security object - it is encouraged. This way you can select a subgroup of users (who have a specific role) who are allowed to edit their own document if desired.
Most helpful comment
To confirm, it is not a bad practice to alter the
_usersdatabase security object - it is encouraged. This way you can select a subgroup of users (who have a specific role) who are allowed to edit their own document if desired.