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 johs@b2w.com designates
 209.85.214.52 as permitted sender)
From: Johs Ensby <johs@b2w.com>
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_AB7D161E-EAC7-4A3B-82BC-40F9FF48C8ED"
Subject: Re: authentication behaviour
Date: Sun, 30 Oct 2011 11:43:07 +0100
In-Reply-To: 
 <CAJNb-9qAa6+sNsSkeqczbW92PHTbHY60A+Q5ST+-4UjzuLgtLw@mail.gmail.com>
To: dev@couchdb.apache.org
References: 
 <CAJNb-9qAa6+sNsSkeqczbW92PHTbHY60A+Q5ST+-4UjzuLgtLw@mail.gmail.com>
Message-Id: <19E5DF5D-D1E7-4C12-AF6C-1C4FC5B08738@b2w.com>

--Apple-Mail=_AB7D161E-EAC7-4A3B-82BC-40F9FF48C8ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

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,
Johs

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

> Hi all,
>=20
> 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.
>=20
> 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
>=20
> - forbidden -> raise 403 and return a body
> - unauthenticated -> raise 401 and return a body
>=20
> 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.
>=20
> Thoughts ?
>=20
> - beno=EEt


--Apple-Mail=_AB7D161E-EAC7-4A3B-82BC-40F9FF48C8ED--