- From: Dave Kok <updates@davekok.net>
- Date: Thu, 25 Nov 2010 10:05:12 +0100
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
Received on Thursday, 25 November 2010 01:05:12 UTC