- From: Thomas Broyer <t.broyer@ltgt.net>
- Date: Sat, 24 Jan 2009 02:48:57 +0100
- To: public-html <public-html@w3.org>
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