You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Patrick Barnes <mr...@gmail.com> on 2010/02/16 07:05:10 UTC
Couchdb and futon authentication on trunk (910404)
Problem 1:
- In admin party mode, when offered authentication details couchdb and
futon will complain. (from memory, I think the error was
{"error":"unauthorized","reason":"Name or password is incorrect."})
- Web browsers remember authentication details - so if I have previously
logged into futon, then removed the users and changed to admin party
mode, I can't access the site until I restart the browser.
Problem 1a: Why doesn't the test suite run unless in admin party mode?
(And why isn't there a 'clean up the test databases' test?)
Problem 2:
Once an admin user is created, if you go and change require_valid_user
to true, everything seems to work fine until you log out or restart the
browser. Then futon will not let you in - trying to access
couchserver:5984/_utils just brings up an
{"error":"unauthorized","reason":"Authentication required."} error...
not a login screen or HTTP auth prompt or anything.
It seems there's no way to get back into futon other than switching
require_valid_user off.
This is the first trunk build I've tried (was on 0.10.0 before), so it
might just be my server, but this behaviour seems either odd or incomplete.
Thoughts?
(Also, can 'sign up' be disabled / admin users allowed to create new users?)
-Patrick Barnes
Re: Couchdb and futon authentication on trunk (910404)
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Feb 15, 2010 at 10:05 PM, Patrick Barnes <mr...@gmail.com> wrote:
> Problem 1:
> - In admin party mode, when offered authentication details couchdb and futon
> will complain. (from memory, I think the error was
> {"error":"unauthorized","reason":"Name or password is incorrect."})
> - Web browsers remember authentication details - so if I have previously
> logged into futon, then removed the users and changed to admin party mode, I
> can't access the site until I restart the browser.
>
One solution for this (maybe already mentioned on the list) is to
remove /_utils from any kind of security restrictions. I'd love to see
a patch for this. This way you could still log in, and then access
data.
> Problem 1a: Why doesn't the test suite run unless in admin party mode? (And
> why isn't there a 'clean up the test databases' test?)
The tests require admin party mode because they do things like delete
and recreate admins, change the authentication methods, etc. Never run
the tests on a production CouchDB.
>
> Problem 2:
> Once an admin user is created, if you go and change require_valid_user to
> true, everything seems to work fine until you log out or restart the
> browser. Then futon will not let you in - trying to access
> couchserver:5984/_utils just brings up an
> {"error":"unauthorized","reason":"Authentication required."} error... not a
> login screen or HTTP auth prompt or anything.
> It seems there's no way to get back into futon other than switching
> require_valid_user off.
>
>
> This is the first trunk build I've tried (was on 0.10.0 before), so it might
> just be my server, but this behaviour seems either odd or incomplete.
>
> Thoughts?
> (Also, can 'sign up' be disabled / admin users allowed to create new users?)
>
> -Patrick Barnes
>
>
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Couchdb and futon authentication on trunk (910404)
Posted by Mark Hammond <sk...@gmail.com>.
On 16/02/2010 8:35 PM, Brian Candler wrote:
> On Tue, Feb 16, 2010 at 05:05:10PM +1100, Patrick Barnes wrote:
>> - In admin party mode, when offered authentication details couchdb
>> and futon will complain. (from memory, I think the error was
>> {"error":"unauthorized","reason":"Name or password is incorrect."})
>
> Correct:
>
> $ curl -v http://admin:admin@127.0.0.1:5984/
> * About to connect() to 127.0.0.1 port 5984 (#0)
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
> * Server auth using Basic with user 'admin'
>> GET / HTTP/1.1
>> Authorization: Basic YWRtaW46YWRtaW4=
>> User-Agent: curl/7.18.0 (i486-pc-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g
> * zlib/1.2.3.3 libidn/1.1
>> Host: 127.0.0.1:5984
>> Accept: */*
>>
> < HTTP/1.1 401 Unauthorized
> < Server: CouchDB/0.11.0be18ea3db-git (Erlang OTP/R12B)
> < Date: Tue, 16 Feb 2010 09:31:57 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 67
> < Cache-Control: must-revalidate
> <
> {"error":"unauthorized","reason":"Name or password is incorrect."}
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
>
> I'd have thought that a browser would then prompt the user for new
> credentials.
IIUC, some browsers will only attempt to use the auth schemes in the
www-authenticate header. In the example above, such browsers wouldn't
consider http basic auth was acceptable, so wouldn't prompt.
Cheers,
Mark
Re: Couchdb and futon authentication on trunk (910404)
Posted by Brian Candler <B....@pobox.com>.
On Tue, Feb 16, 2010 at 05:05:10PM +1100, Patrick Barnes wrote:
> - In admin party mode, when offered authentication details couchdb
> and futon will complain. (from memory, I think the error was
> {"error":"unauthorized","reason":"Name or password is incorrect."})
Correct:
$ curl -v http://admin:admin@127.0.0.1:5984/
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
* Server auth using Basic with user 'admin'
> GET / HTTP/1.1
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.18.0 (i486-pc-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g
* zlib/1.2.3.3 libidn/1.1
> Host: 127.0.0.1:5984
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Server: CouchDB/0.11.0be18ea3db-git (Erlang OTP/R12B)
< Date: Tue, 16 Feb 2010 09:31:57 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 67
< Cache-Control: must-revalidate
<
{"error":"unauthorized","reason":"Name or password is incorrect."}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
I'd have thought that a browser would then prompt the user for new
credentials. But if they click 'cancel' I'm not sure what happens (does the
browser give up at that point, but not invalidate its cached user/pass?)
> (Also, can 'sign up' be disabled / admin users allowed to create new users?)
I think you can just set readers ACL on the _users database. But then an
admin will be required to change users' passwords too.
Regards,
Brian.