You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2021/01/29 16:09:24 UTC
[GitHub] [couchdb] adrienverge opened a new issue #3356: Editing user roles is not instantaneous and produces HTTP 403
adrienverge opened a new issue #3356:
URL: https://github.com/apache/couchdb/issues/3356
Hello, I think this is a bug, although I'm not 100% sure. I haven't found any similar issues.
Problem: changes to user roles (to allow her to access a database) are not taken into account immediately, so this user gets a `HTTP 403 Forbidden` error when accessing the database. Waiting a few seconds solves the problem.
To reproduce (on the latest version, CouchDB 3.1.1):
1. As admin, create a user without roles:
```
(admin) PUT /_users/org.couchdb.user:user
```
2. Perform any request as this user (this is important):
```
(user) GET /
```
3. As admin, create a database and protect it with a role:
```
(admin) PUT /base
(admin) PUT /base/_security
{"members": {"roles": ["allowed_to_access_base"]}}
```
4. As admin, update user to give the `allowed_to_access_base` role:
```
(admin) GET /_users/org.couchdb.user:user
(admin) PUT /_users/org.couchdb.user:user
{…, "roles": ["allowed_to_access_base"], …}
```
5. As user, request the base (`HEAD`, `GET`...):
```
(user) GET /base
```
Result: sometimes response is a `HTTP 200`, sometimes it's a `HTTP 403`.
Expected behavior: always get a `HTTP 200`.
I've [attached a Python script](https://github.com/apache/couchdb/files/5894838/bug_reproduction.py.txt) to reproduce automatically. On my computer, the bug happens:
- ~ 70 times out of 100 attempts, on a 1-node cluster
- ~ 30 times out of 100 attempts, on a 3-node cluster
The bug disappears:
- If we wait for a little while between steps 4 and 5.
- If step 2 is skipped.
- If the user is created (step 1) with `allowed_to_access_base` role already.
At first, I thought it was an inconstistency problem between nodes in a cluster. But the bug happens even when doing all HTTP calls on the same node, and also on a single-node cluster.
Do you know where it could come from?
I'd be happy to dig further if you have an idea.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [couchdb] adrienverge commented on issue #3356: Editing user roles is not instantaneous and produces HTTP 403
Posted by GitBox <gi...@apache.org>.
adrienverge commented on issue #3356:
URL: https://github.com/apache/couchdb/issues/3356#issuecomment-775005078
Hello @rnewson, thanks for your answer.
> It also largely not relevant that the requests were initiated by the same coordinator node.
Interesting and good to know! That's not an intuitive result. But that's indeed what I measured when testing reproduction scenarii.
> One thing to note is that the change to the security object will enter the same queue as reads and writes to the relevant files, and those are processed in order of receipt.
Interesting too! Is there a way to use this fact in order to garantee that a future call to `GET /base` (as user) will succeed (no random HTTP 403)? Without making the code "sleep" for an arbitrary amount of time?
Also, is it a *bug* to get inconsistent results just after changing a base `_security` object?
- If yes, is there something I can do? I could open a pull request to update the docs about this limitation?
- If no, is there a "correct" way to get consistent results when querying a base after changing its `_security`? Because "waiting 1 second" doesn't sound satisfafying (performance loss after each database creation, in our case) nor reliable (in case of server load, delays are increased).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [couchdb] adrienverge commented on issue #3356: Editing user roles is not instantaneous and produces HTTP 403
Posted by GitBox <gi...@apache.org>.
adrienverge commented on issue #3356:
URL: https://github.com/apache/couchdb/issues/3356#issuecomment-799201260
@janl this message is a bit obscure, could you please enlighten us with more details than "this is not a bug"?
- If you're talking about consistency/availability (which I'm not sure of, given your very short message), these terms usually relate to multi-node clusters. Here we're talking about inconsistent results in a **one-node** CouchDB, is that right?
- "the only option until 4.x comes out": what do you mean? Will this bug be solved in the 4.x release? Is there some code/pointer that relates to this?
The reason I opened this issue is because this behavior (inconsistent reads/writes on 1 node) wasn't described anywhere.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [couchdb] rnewson commented on issue #3356: Editing user roles is not instantaneous and produces HTTP 403
Posted by GitBox <gi...@apache.org>.
rnewson commented on issue #3356:
URL: https://github.com/apache/couchdb/issues/3356#issuecomment-774658236
The _security object is stored on each copy of each shard range so there is some potential for inconsistency and delay even on a single node server. It also largely not relevant that the requests were initiated by the same coordinator node.
multiple seconds is a little odd though. One thing to note is that the change to the security object will enter the same queue as reads and writes to the relevant files, and those are processed in order of receipt.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [couchdb] janl closed issue #3356: Editing user roles is not instantaneous and produces HTTP 403
Posted by GitBox <gi...@apache.org>.
janl closed issue #3356:
URL: https://github.com/apache/couchdb/issues/3356
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [couchdb] janl commented on issue #3356: Editing user roles is not instantaneous and produces HTTP 403
Posted by GitBox <gi...@apache.org>.
janl commented on issue #3356:
URL: https://github.com/apache/couchdb/issues/3356#issuecomment-798932797
for a AP vs CP system, this is not a bug.
You could wait with shorter timeouts until you get a non-403 response. It’s not pretty, but the only option until 4.x comes out.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org