On Wed, Aug 17, 2011 at 12:55 AM, Jens Alfke <j...@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’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 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. -- Iris Couch
