[whatwg] Session Management

[Dave Kok]

Hi Subscribers,

I am not sure if I am at the right mailing list for this. But I was 
wondering if it would be beneficial to have some kind of session 
control feature in the Web Applications spec.

Currently the spec defines sessionStorage which I think is a great. It 
allows me to stop using cookies and maintaining session state 
completely in the browser. However I am still faced with the fact that 
there is no way to clear the HTTP authentication credentials cache. I 
prefer to use HTTP authentication mostly as it is build-in anyways and 
has richer features then pure form-based authentication. 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.

I would be interested to know if such a feature would be worth 
considering. Looking forward to comments and possibly a discussion.

Regards,
Dave Kok