Subject: Authorization with WWW-Authenticate (bis)

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Fri, 23 Oct 2009 17:57:01 +0200 (CEST)

Hi all,

Following http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78 I've
been left wondering how to convey the following semantic with HTTP:

* The request was not fulfilled due to authorization failure and the
server (does not wish to)/(cannot) specify which scheme must be used.

The context is based on HTTP requests issued from Javascript along with a
cookie based authentication system.

RFC 2616 tells me I cannot reply neither with a 401 without a scheme nor
can I use a 403 since subsequent Authorization would not help.

At first I was tempted to simply use one of the 30x code to inform the
Javascript handler that it should act accordingly but browsers don't
bubble up 30x responses to the Javascript stack which leaves me the
already burdened 400.

There seemed to be a consensus two years ago not to split the
Authorization header from its WWW-Authenticate friend but to me the
semantic of one without the other remains.

Today I'm merely seeking the group advice on what would be the best
decision to make.

Thanks,
- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 23 Oct 2009 23:46:27 +0200

> Today I'm merely seeking the group advice on what would be the best

Help me advancing and finishing "HTTP Cookie Auth" ;-)
http://tools.ietf.org/html/draft-broyer-http-cookie-auth
http://hg.ltgt.net/http-cookie-auth/

(this is only a matter of time I have available to work on it –much
less than I'd like–, do not see the absence of work as a giving up)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 24 Oct 2009 15:17:43 +0200

> less than I'd like–, do not see the absence of work as a giving up)
Hi Thomas,

This is indeed a good starting point. I went through your proposal and 
I'm a bit unclear about the actual end-to-end workflow performed by the 
UA. I'm not sure to understand how the different directives would be 
applied.

- Sylvain

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 24 Oct 2009 16:33:52 +0200

On Sat, Oct 24, 2009 at 3:17 PM, Sylvain Hellegouarch wrote:
> This is indeed a good starting point. I went through your proposal and I'm a
> bit unclear about the actual end-to-end workflow performed by the UA. I'm
> not sure to understand how the different directives would be applied.

Think of how HTML form and cookie-based auth is done today. Now:
 1. replace any "redirect to login form" with either a 3xx
"Unauthorized, See Other" (to be defined, in preparation for the -01
draft, would need a <meta>-refresh for backwards compat though) or,
better, a 401 with the HTML form (some form-based auth already use 200
with no-cache).
 2. serve the HTML login page with a 401 and a WWW-Authentication:
Cookie. The only required field is the realm (per RFC 2617), fields
about the cookie(s) are RECOMMENDED, and fields about the form (-01
will add two fields to make "machine driven" auth easier, without
having to parse the response body, which might not even be HTML with a
form) are OPTIONAL (because http-cookie-auth doesn't even require that
there is a "form" to be submitted; the cookie could be set by any
mean, including some JS or Flash or ... included in the 401 response).
 3. there's no Authorization request header entering into play, the
Cookie header is enough to convey credentials (which means
authenticated responses should be sent with the appropriate Vary:
Cookie and Cache-Control: private headers).

http-cookie-auth is totally backwards compatible (except unfortunately
with Opera pre-10.0, as Opera will then display an error page about
the auth scheme not being supported); and should require only very
minimal changes to any existing cookie-based auth (including SSOs).
I'm successfully using a similar, custom, auth scheme in an enterprise
app; which I plan to migrate to http-cookie-auth when it will be
"stable" enough.

And now let's continue this discussion in private (and in French ;-) )
or on [email-masked] ;-)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/