couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johs Ensby <>
Subject Re: authentication behaviour
Date Sun, 30 Oct 2011 10:43:07 GMT
Thanks for raising this question, Benoit!

Having worked with CouchDB as an all-in-one solution for deploying small web sites and couchapps,
the authentication system is the main sources of irritation. How on earth do I make this work?
An example:
- push the app to a publicly available db so you can serve an app with a login box
- then get data ajax-style from the databases that you want to protect
- oops, the timeout does not return a useful json, but redirects the user
- ok, so lets alter the timeout redirect to a login page..
- opps, what about my half-way completed form that i wanted to submit after logging in again
- ok, so make a "keep-alive" polling function to avoid timeout
.. and so on..

I am really exited about Couch for its simplicity as a backend for ajax apps, but the auth
solution is a real showstopper. My specific suggestion as of now:
- an alternative to the authentication_redirect: serve a json object as if from the _session,
e.g. {"ok":false, "timeout": true ...

Best regards,

On 30. okt. 2011, at 09:48, Benoit Chesneau wrote:

> Hi all,
> I'm starting to hate our authentication system. We have now an
> authentication system which default behaviour is to answer to browsers
> or ajax calls. Ie we redirect on fail login. Last change for example
> in cookie auth make the API raises a 401 only when fail parameter is
> given in the uri.
> While this default behaviour may be good for some couchapps, I would
> prefer that the default behaviour would be a full HTTP behaviour, so
> we can consider coudhdb as full store. Also this system doesn't work
> well in some couchapps too. So I propose to have this default HTTP
> behaviour
> - forbidden -> raise 403 and return a body
> - unauthenticated -> raise 401 and return a body
> And that's all. Redirection should be in my opinion something either
> forced in the settings or via a url params (or headers). That can be
> both. Although, I'm not sure why we have redirection here when we
> could have depending on the Accept header either a json or an html
> page. Anyway, making this redirection something that must be forced is
> something I would like to introduce for 2.0x.
> Thoughts ?
> - benoƮt

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