authentication behaviour

[Benoit Chesneau <bc...@gmail.com>]

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

Re: authentication behaviour

[Noah Slater <ns...@tumbolia.org>]

On Fri, Nov 11, 2011 at 9:24 AM, Jan Lehnardt <ja...@apache.org> wrote:

> It'd break CouchApps that expect the redirect by default.
>
> For the sake of not breaking API's I'd suggest a config setting that
> enables Benoit's proposed behaviour that we can make the default for
> 2.0.

+1

Re: authentication behaviour

[Jan Lehnardt <ja...@apache.org>]

On Nov 11, 2011, at 08:22 , Dave Cottlehuber wrote:

> On 30 October 2011 09:48, Benoit Chesneau <bc...@gmail.com> 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
>> 
> 
> +1 in principle. What might this break?

It'd break CouchApps that expect the redirect by default.

For the sake of not breaking API's I'd suggest a config setting that
enables Benoit's proposed behaviour that we can make the default for
2.0.

Cheers
Jan
-- 

Re: authentication behaviour

[Dave Cottlehuber <da...@muse.net.nz>]

On 30 October 2011 09:48, Benoit Chesneau <bc...@gmail.com> 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
>

+1 in principle. What might this break?

A+
Dave

Re: authentication behaviour

[Randall Leeds <ra...@gmail.com>]

On Sun, Oct 30, 2011 at 17:26, Jason Smith <jh...@iriscouch.com> wrote:
> On Sun, Oct 30, 2011 at 5:43 PM, Johs Ensby <jo...@b2w.com> wrote:
>> 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..
>
> And you're just getting started!
>
> I am not confident that CouchDB can satisfy everybody's needs
> correctly. Consider the "Accept" header. Just that one little feature
> has produced a huge discussion, with no clear correct solution, and
> not all users satisfied. And that is but a tiny component of a
> well-made Couch app.
>
> Therefore, I 100% agree with Benoit's reaction. Make couch simple.
> Make couch predictable. Next, the community can build tooling for more
> complex tasks.
>
> --
> Iris Couch
>

Sounds good to me.

Re: authentication behaviour

[Jason Smith <jh...@iriscouch.com>]

On Sun, Oct 30, 2011 at 5:43 PM, Johs Ensby <jo...@b2w.com> wrote:
> 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..

And you're just getting started!

I am not confident that CouchDB can satisfy everybody's needs
correctly. Consider the "Accept" header. Just that one little feature
has produced a huge discussion, with no clear correct solution, and
not all users satisfied. And that is but a tiny component of a
well-made Couch app.

Therefore, I 100% agree with Benoit's reaction. Make couch simple.
Make couch predictable. Next, the community can build tooling for more
complex tasks.

-- 
Iris Couch

Re: authentication behaviour

[Johs Ensby <jo...@b2w.com>]

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