Re: about draft-broyer-http-cookie-auth (the Cookie Authentication Scheme) and ISSUE-13

On Fri, Jan 23, 2009 at 3:30 PM, Dan Connolly wrote:
>
>   Julian: I've been following Thomas Broyer's IETF ID; I gather a new
>   draft is in progress

Work is underway at
http://hg.ltgt.net/http-cookie-auth/raw-file/tip/spec/draft-broyer-http-cookie-auth.xml
(note for instance the new Abstract, totally rewritten since the -00 draft)

>   DanC: how does Thomas Broyer's proposal work? browser builder
>   interest?
>
>   Julian: aside from a bug in opera, it doesn't require any browser
>   builder changes

One of the goals is backwards compat' with UAs (aka graceful
degradation), so it doesn't *require* any change in browsers:
http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html
Browsers might however take advantage of the Cookie auth scheme
(identify which cookies are used for authentication and store them in
a different, more secure, storage than other cookies).

The required change in Opera is related to:
  "HTTP 401 responses that do not include a challenge recognised by
the user agent must be processed as if they had no challenge, e.g.
rendering the entity body as if the response had been 200 OK."
   — HTML5, 13th step in § 5.9.1 (Navigating across documents)

>   (I can't seem to get Julain to tell me who is in the critical path
>   for deployment. who changes from 200 to 4xx? webmasters? any big
>   webmasters lined up to do this?)

Another main goal is that it's a 1-line or 2-line change in most
cases, so I'd like to then send patches to frameworks (Ruby on Rails,
Django, Zend, etc.) and applications (JA-SIG CAS, dotProject, Typo3,
Drupal, Alfresco, Liferay, etc.); or workarounds when patches are not
possible (ASP.NET for instance).
In most cases, it would then just be a matter of upgrading the
framework or application.

There's one use-case where authors/developers will particularly enjoy
the Cookie auth scheme: when using AJAX and "cookie-based
authentication", current practice of sending the login page within a
200 (OK) response (with an eventual redirect in between) makes it
impossible to detect unauthorized access (session expired, or you
logged out in another window or cleaned your cookies, etc.). The
Cookie auth scheme makes it possible to return the login form in a 401
(without violating HTTP I mean: you can still send a 401 without
WWW-Authenticate header, you won't even hit the issue with Opera) and
therefore detect such cases with code as simple as the following,
without the need to change how your resources are protected (I suspect
some current frameworks to send back some JSON object with an "error"
key, within a 200 (OK) response).

  function onReadyStateChange() {
     if (this.readyState == 4 && this.status == 401) {
        // Handle unauthorized request; for example:
        alert("You've been logged out!");
        location.reload();
        return;
     }
     // ...process response...
  }

(FWIW, that's already more or less what Alfresco SURF / Alfresco Share
does, except that it sends a 401 without WWW-Authenticate, which
violates RFC 2616)


Demos and tests: http://www.ltgt.net/tests/http-cookie-auth/
Code available in http://hg.ltgt.net/http-cookie-auth/

--
Thomas Broyer

Received on Saturday, 24 January 2009 01:49:35 UTC