couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: to CouchApp or not to CouchApp
Date Wed, 17 Aug 2011 06:28:49 GMT
On Wednesday, August 17, 2011, Adam Kocoloski <> wrote:
> On Aug 16, 2011, at 10:47 PM, Jason Smith wrote:
>> On Wed, Aug 17, 2011 at 12:55 AM, Jens Alfke <> 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’s
backwards. I agree with prior messages in this thread that CouchApps are
nifty but limited, and we shouldn’t 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
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message