W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Session Management

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 1 Mar 2011 22:29:26 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1103012212400.26730@ps20323.dreamhostps.com>
On Thu, 25 Nov 2010, Dave Kok wrote:
> 
> I am still faced with the fact that there is no way to clear the HTTP 
> authentication credentials cache.

To some extent that's up to the browser. It logs you in, it can offer the 
ability to log you out.


> I prefer to use HTTP authentication mostly as it is build-in anyways and 
> has richer features then pure form-based authentication.

What features does it have that other mechanisms do not?


> The only problem is that you can't clear credentials when a session is 
> terminated. So I am wondering whether some kind of session control that 
> is somewhat broader then just clearing sessionStorage could be included 
> into the standard.
> 
> Personally I would imagine such a API existing out of just two 
> functions: a start and a terminate function. After an session has 
> started all credentials cached for HTTP authentication and everything 
> stored in sessionStorage and all cookies without explicit expiration 
> created, would all be destroyed when the terminate function is called or 
> when the user navigates away from the origin in the top-browser context. 
> Using such a method would give a web application developer just the 
> right amount of control and would allow the implementation of a logout 
> button that actually works. Currently it is possible the clean out 
> sessionStorage and destroy cookies but not to clear cached credentials 
> for HTTP authentication.
> 
> Possibly the start function could also accept a path argument to specify 
> just a sub area of the origin on which the session is valid. This would 
> allow more fine-grained control. Please note that the session would be 
> specific to the top-browser context. Also HTTP authentication 
> credentials belonging to the current session should not be limited to 
> just credentials cached for the top-browser context origin but all 
> credentials cached. This should also be the case for sessionStorage and 
> cookies without expiration specified.
> 
> As for backwards-compatibility since the feature requires a developer to 
> call a function to make use of it. It would not impact current web 
> applications and thus would be fully backwards-compatible. A developer 
> must already know about the feature to use it. So I would expect that 
> such a consideration would not be an obstacle.

This is an interesting idea. I recommend following the steps described 
here to see if it can get traction:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 1 March 2011 14:29:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC