[
https://issues.apache.org/jira/browse/COUCHDB-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326469#comment-15326469
]
Sebastian Rothbucher commented on COUCHDB-2991:
-----------------------------------------------
It seems like this ticket has become kind of a collection of topics. Let me
sort them out - tested based on:
git checkout master && ./configure -c --disable-fauxton --disable-docs && make
clean && make && git checkout auth-tests-wip
Topic #1: _design/auth does not get installed on custom users DB => this is
solved, design doc is created upon first auth (though the test in users_db.js
is ported to use _users - where it works anyway)
Topic #2: conflicts in user docs don't seem to bother any longer => this is
solved, can't login with conflicts (also covered in the tests in users_db.js)
To reproduce: produce a conflict in a user doc (the users_db.js test does that
also) and try to login (which works)
Topic #3: any user can call _all_docs on _users via cluster port (not backdoor)
=> this seems to be solved, a "normal" user gets a "you are not a server admin"
response (tested at the end of users_db_security.js)
Unfortunately, deleting user docs seems broken now => "Topic #4" => still
there, deletion fails with reason "missing" (covered in users_db.js - just
disabled/commented out; question is about importance / wheter this is a known
limitation)
>From Jan's Github (now line 135 afaik - writing the user doc):
71: test/javascript/tests/users_db.js # <<<<< place in users_db.js where the
error is triggered
=> "Topic #5" => this seems to be solved, writing the user doc is part of the
test in users_db.js and works
>From Jan's Github
186: test/javascript/tests/users_db_security.js # <<<<< place in
users_db_security.js where
=> "Topic #6" => stil there, upgrading the hash fails w/ "bad match" (question
is about how important that is - whether we skip this test, acknowledge a known
limitation and move on)
Setting _security to role "admin" for user "beniotc" has no effect (also
user_db_security.js)
=> "Topic #7" => not working (covered around line 270 of users_db_security.js).
To reproduce, follow the steps outlined there: create a view as admin, create a
user, update _security for this user to be admin, try to query the view. It's
more strict actually than before (question is though: is that simply a known
limitation?)
I guess we have to decide on #4, #6 and #7 - how to go about these. #4 is
ecluded now; I can submit a PR quite quickly 2 exclude #6 and #7 as well. But I
think we should take a moment to think about it…
> userdb behaves less strict on cluster
> -------------------------------------
>
> Key: COUCHDB-2991
> URL: https://issues.apache.org/jira/browse/COUCHDB-2991
> Project: CouchDB
> Issue Type: Bug
> Reporter: Sebastian Rothbucher
> Assignee: Robert Newson
> Priority: Blocker
>
> Topic #1: _design/auth does not get installed on custom users DB
> To reproduce: set both
> [{section: "couch_httpd_auth",
> key: "authentication_db", value: usersDb.name},
> {section: "chttpd_auth",
> key: "authentication_db", value: usersDb.name}]
> to a usersDB that is not _users and check if the document is there (certainly
> minor)
> Topic #2: conflicts in user docs don't seem to bother any longer
> To reproduce: produce a conflict in a user doc (the users_db.js test does
> that also) and try to login (which works)
> Topic #3: any user can call _all_docs on _users via cluster port (not
> backdoor)
> To reproduce: create a user doc and use it to get _users/_all_docs (once on
> cluster, once on backdoor), you'll see the difference: cluster allows the
> action while backdoor does not
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
