Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8B1CA083-183A-4252-B898-8F09BAD37F18@apache.org>
References: 
 <CA+5KyPSE3BULUc7KONgx8ZqfNKW++_r8vgdhh7HLxLr0JgfM0A@mail.gmail.com>
	<CAONf+LQKjE6NVCsLKWb3wzmWOwrS2ej+_PCJS4Z=uV3hj0OtOg@mail.gmail.com>
	<CAOHkvcP0XMAFvvFhaw3azEyqBxPMhNxFwkYX+5_x52ScSaxEbg@mail.gmail.com>
	<CAMkGvyNO4GC8e+PWu8u7BpV6b4OUvXZ3v37y5kpnXdrYgn_nBA@mail.gmail.com>
	<4E371B93.8060303@kearns.net.au>
	<CAAL6JQj_u0RgDhQG95oFrQfJ3MUeRXHb+Q6d1Cc6DEBUwaE_vA@mail.gmail.com>
	<CAONf+LTt0Hmuhx8PTs_LdzzX-fHQDAhQg_kJabTQAnfnBdxZqQ@mail.gmail.com>
	<CAOHkvcNutCimOggckR3ivc2=DCAP1ZhPTC2XpnP1o_E82_Pvaw@mail.gmail.com>
	<CA+5KyPR56FpKXiQ6Zyxu0V2jwaKbOghbTZyJ10Ou=YXyyk6zhA@mail.gmail.com>
	<CAONf+LTd+qQtLBb7iXb-H_HJs4Xm+t+Bw0G4CMLCC8X=bYwdFQ@mail.gmail.com>
	<CAAL6JQhytD90Jn3f7LT-HUMVH=T5GgTEMXWzaR6kQ5BgqZGRSw@mail.gmail.com>
	<CAAL6JQjbpOD9GOu-dDDf7-1-44pANT3U=ZKaNYEBXPcX11C8pA@mail.gmail.com>
	<CAN-3CBLheiAds-L5Vps-amEHN-F-17yRqHzbzNzAq-Ev9BKa5g@mail.gmail.com>
	<CAMWZAjnE9p2QB7zujjGqL-JiLMnbbimmuz3V-f+pW_bNeL4hng@mail.gmail.com>
	<CABvT1DHODFHdq3Uu6AcKGuk+Vmf+EJvV0Lyj=Q7A_iAehst+iw@mail.gmail.com>
	<CAJNb-9p--g2d_UMWAtSjbyTLRYdt_h0T0sLckX5k=+HJ2kyUHg@mail.gmail.com>
	<CAMWZAj=8GRLuvF2GDr=bi=g05j9_w+JBt76ohmscNX2Pvz4Eqw@mail.gmail.com>
	<CAJNb-9pQGzvZ8pmqSxoY0Jyk+8Z+sXYzYgTgOmqiVr3Ww+hDaw@mail.gmail.com>
	<CAMWZAjmSY_jdvyZ4+tjbO6TdbRAUb+gd4UhVrbSKTgvNmrgRJQ@mail.gmail.com>
	<CAN-3CB+LwerwsdcxLfRW70NwWvHDiTg7spRKJ0tBAZQzsuX8QA@mail.gmail.com>
	<CAMWZAjms30L_TosKNt54Bqn9fHteJOuuanYKqnA-UrAa6+Bkcw@mail.gmail.com>
	<CABvT1DEZYDTe5YLX=LOA1raLPtUq_MgPNFQKbf5z2Ff6PWqS3g@mail.gmail.com>
	<CAMWZAj=SP+9V5J+gigHpH8TAGfDBOdz0815P0=zwtyFA+ZhjAw@mail.gmail.com>
	<EB6A293C-E6D6-4BE7-8D70-23587A84D5DA@couchbase.com>
	<CAMWZAjmNCxesgOWu8iZePuigyjEz9w0iWWEBA5BoPfPkh4HXCw@mail.gmail.com>
	<CABvT1DGbE5mR9ncPnZkeeX7DWMu3_QqwBafV6y6Oh5_KtRAGXw@mail.gmail.com>
	<CAMWZAjk4z_51=it71oh--cXU+h_kxfz4FmNH7M8-Pbxy6T1m9g@mail.gmail.com>
	<CABvT1DFi=zRUmgvZfZMxU=JE2TNDp_VWFhwJ1Ygo98ZWzBw69g@mail.gmail.com>
	<CAN-3CBJzhQrY9qmhdgRQGYijWiNgaKeMAFJBOE2FZPctdf5b-w@mail.gmail.com>
	<8B1CA083-183A-4252-B898-8F09BAD37F18@apache.org>
Date: Wed, 17 Aug 2011 08:28:49 +0200
Message-ID: 
 <CAJNb-9pRYkg6wu_BRU1Or2G_zUDnwA-2oNr=mPCV+EXtFzPBpw@mail.gmail.com>
Subject: Re: to CouchApp or not to CouchApp
From: Benoit Chesneau <bchesneau@gmail.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=0015174beacafc58e904aaad9b74

--0015174beacafc58e904aaad9b74
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wednesday, August 17, 2011, Adam Kocoloski <kocolosk@apache.org> wrote:
> On Aug 16, 2011, at 10:47 PM, Jason Smith wrote:
>
>> On Wed, Aug 17, 2011 at 12:55 AM, Jens Alfke <jens@couchbase.com> wrote:
>>> IMHO the best behavior is:
>>>
>>> - CouchDB intrinsically returns a 401, with the required
WWW-Authenticate header. That is the correct HTTP behavior when the client
is trying to access a read-protected resource without being authenticated.
>>>
>>> - There would be some way for a CouchApp to intercept and override this
response, so that it can instead return a custom response such as a 302
redirect to its own login page.
>>>
>>> Returning a 302 rather than a 401 is prioritizing the app-server usage
of CouchDB over the REST/database server usage, and I think that=92s
backwards. I agree with prior messages in this thread that CouchApps are
nifty but limited, and we shouldn=92t be breaking regular HTTP behavior in =
the
server just so that CouchApps can show fancy login pages.
>>
>> Totally agree.
>>
>> However, once again, the word "CouchApp" confuses the discussion and
>> muddies the waters.
>>
>> Forget about "CouchApp."
>>
>> You click a link or bookmark and your browser (ultimately) goes to
>> couch.com:5984/db/some_doc/some_attachment.html. But you aren't
>> authorized.
>>
>> The *standard* response and also the Couchy response is 401.
>>
>> The *typical* response that all web apps actually do (because they are
>> not simultaneously REST databases) is 302 bounce to a login page.
>>
>> I am really loving this discussion. It is a tough problem. Thanks very
>> much to Marcello for keeping it going. Today I will investigate what
>> happens if you return 401 with WWW-Authenticate and also a Location
>> header. Is that allowed? Maybe we will get lucky and browsers will
>> bounce. Crossing fingers.
>

it won't change anything.


> Yeah, that'd be nice.  Not holding out hope though.
>
> Adam
>
>

--0015174beacafc58e904aaad9b74--