couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: authentication cleanup
Date Thu, 24 Dec 2009 18:16:26 GMT
On Thu, Dec 24, 2009 at 5:27 PM, Chris Anderson <> wrote:
> Devs,
> I'm attempting to make more sense of CouchDB's authentication system.
> The current system is a proverbial ball of spaghetti. I'm still in the
> investigation stage of my work, and I'm writing this to clarify my
> thoughts and solicit feedback.
> To start with, the current default_authentication_handler is unaware
> of the users db. I plan to fix that, and to change default.ini so that
> cookie_auth is enabled for all Couches. I also plan to make it so that
> CouchDB never triggers the basic-auth popup box, because we all know
> that that's a UI dealbreaker. (We'll still accept basic auth, we just
> won't prompt for it.)

Auth popup is created by the browser. Does it imply an ui would be
needed to connect to CouchDB via the browser ? Also how can we detect
the basic auth if you don't send the 401 status with WWW-Authenticate
? I think we should keep the default behaviour (popup) but on the
other hand reusing the system used with cookie aut allowing us to not
popup by just providing another header.

> One question is how to manage system roles such as _admin. My thinking
> is that the users db validation function will forbid roles starting
> with underscore from being stored on user's documents. Instead, when
> Couch loads a user from the db, it will cross-reference the user with
> the list of node and db admins, and apply the _admin role when
> appropriate. This way we can avoid having more than one distinct type
> of user in the system. This should also allow us to have more system
> roles (prefixed with underscore) in the future.

Not sure to follow here.Do you plan to remove admins from ini ? I
would be to keep them. They are like super users. We could create
another class of users for that. Maybe _staff  to follow unix

> Another question is bootstrapping the cookie auth system. Currently a
> node secret needs to be configured before cookie_auth is enabled. I
> don't plan to change that, but I do plan to add a UI workflow to Futon
> which encourages you to setup an initial admin user and configure the
> secret. Once that is done, cookie auth will be enabled.


> At the level of code, I plan to move some things around so most of the
> auth stuff is together in the codebase. I'll also be removing the
> /_user handler in favor of CouchDB's standard database API + a
> validation function. If the /_user handler is widely used, I can
> replace it with an _update function which will handle setting up the
> hashed password and salt, as well as accepting
> application/x-www-form-urlencoded POSTs. If there is concern about
> backwards compatibility with existing software, I can also setup an
> internal rewrite so that the /_user URL continues to function as it
> does now.

I guess the _user rewrite could go with the rewriter i will show this
we. (pure erlang)

> I'm also thinking that the /_session handler should speak JSON
> primarily (but I'll probably leave in the ability to handle
> form-encoded request bodies as well).
We could just detect http headers and provide the needed response for
that.  Keeping the form encoded would be good. It's already used in
some applications.

> As far as security on the users DB, I don't plan to change anything
> from how it is now. The basic idea is that anyone can create a new
> user document (eg anyone can signup), but only _admins can set roles
> on user documents. Additionally, only _admins or the user whos
> document it is can update a user document.
> In the future, when we implement reader access-control-lists for
> databases, they will be useful to further secure the users DB. For
> now, the users db will be world-readable, which is fine as long as
> no-one breaks the crypto. We're already using strong hashes and long
> salts, so I think we're already relatively secure.
Not really since salt is available and hash is only sha1. I think we
could make it harder but I agree with a strong encryption we don't
need to hide them.

> None of what I'm doing should change the oauth handlers.

oauth is a problem here if it's in a public db.

> Thanks for your attention. Please fire aware with questions and comments.
> Happy holidays,
> Chris
Thanks you too. I would be happy to help on this part I have a project
that just wait for a some auth. So tell me if I can help.

- benoƮt

View raw message