couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: authentication cleanup
Date Tue, 05 Jan 2010 18:38:04 GMT
FYI - I have pushed the account branch to Apache SVN.

I plan to merge it to trunk in the next couple of days. Please test,
especially if you are making heavy use of authentication / oauth /
cookie auth.

There may be some small backwards incompatibilities, hopefully these
are slight enough that we can fix them in CouchDB or your application
code. My intention is to make this patch as smooth as possible for
people to work with. If you see something that's not fun to handle on
your end, please let us know.


On Mon, Jan 4, 2010 at 5:20 PM, Adam Kocoloski <> wrote:
> On Jan 4, 2010, at 4:54 PM, Chris Anderson wrote:
>> On Mon, Jan 4, 2010 at 1:26 PM, Adam Kocoloski <> wrote:
>>> Hi, just catching up on this very nice thread.  I'm +1 on using the login for
the docid instead of triggering a view lookup, for the reasons Chris outlined.  Regarding
resistance to brute force attacks, bcrypt storage is definitely better than salted sha-anything,
and Colin Percival's scrypt[1] is definitely better than bcrypt.  I'm not aware of javascript
implementations of either of them, though.
>> The current implementation runs the crypto in the browser to create
>> the user document. This could be run in an Erlang _update function and
>> then we could use erlang's bcrypt.
> Yep, that would work.
>>> I'm curious to see where we end up on the whole 401 Unauthorized browser popup
thing.  At Cloudant we still respond with a 401 if a basic auth request failed, but we send
a 403 if a /_session request failed or a cookie expired, and for exactly this reason.
>> The solution I'm going with right now is to send a 401, but without
>> the WWW-Authenticate header. This avoids triggering the popup, without
>> breaking anything else.
> That sounds like a better approach.  Cheers, Adam

Chris Anderson

View raw message