Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.216.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=X2/kS1O2Ds+dRTq2D+5vgg0N9SU+g0HBvF2DcNtuNz2WfyroIiLU+8QgV1+DIYDLwd
         Mo7mIw0+9YjDrBcghd454GdBhqEjB/XYtjAshkyibq6wEDzKIyyfHNfOVAIN3XP6GceW
         tbjYuSq0MUndlAESicRouxdkK/uG/OUk7ikdU=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <8D6E5FA3-9215-49D0-8DD7-172FBE9D6ECF@apache.org>
References: <e282921e0912240827t64e37b24l777d6c8f640e972c@mail.gmail.com>
	 <hha5eb$6nv$1@ger.gmane.org>
	 <e282921e1001010821p54a602adv6618287f499a1fe2@mail.gmail.com>
	 <hhtfn8$u2f$1@ger.gmane.org>
	 <e282921e1001041142g3809f5eel59cc2070cb33037b@mail.gmail.com>
	 <41A81121-F352-4EF7-A840-1A5175FF0559@apache.org>
	 <e282921e1001041354k1d6c307djb14d44161768d109@mail.gmail.com>
	 <8D6E5FA3-9215-49D0-8DD7-172FBE9D6ECF@apache.org>
Date: Tue, 5 Jan 2010 10:38:04 -0800
Message-ID: <e282921e1001051038l17b35ed7xdfbba2eeb66e56e3@mail.gmail.com>
Subject: Re: authentication cleanup
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.

Chris

On Mon, Jan 4, 2010 at 5:20 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> On Jan 4, 2010, at 4:54 PM, Chris Anderson wrote:
>
>> On Mon, Jan 4, 2010 at 1:26 PM, Adam Kocoloski <kocolosk@apache.org> wro=
te:
>>> Hi, just catching up on this very nice thread. =A0I'm +1 on using the l=
ogin for the docid instead of triggering a view lookup, for the reasons Chr=
is outlined. =A0Regarding 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. =A0I'm not aware of javascript implem=
entations 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 browse=
r popup thing. =A0At Cloudant we still respond with a 401 if a basic auth r=
equest 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. =A0Cheers, Adam
>
>


--=20
Chris Anderson
http://jchrisa.net
http://couch.io