[whatwg] Session Management

Op 01-03-11 23:29:26 schreef Ian Hickson:
>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.

You can also login using AJAX requests. This breaks the idea of it 
being purely a UI matter. Also browsers don't all do this. In my 
opinion it is not sufficient to have solely the browser UI cover this 
particular feature. Also looking forward to a feature like app mode 
shipping in Google chrome, I remember Firefox having something similar, 
it would be really useful if it could be controlled from within a web 
page. Also as web developers are requesting this over and over again 
there seems to be a real need. Just saying that the web browser UI 
should do it is not getting the job done. Most prominently however how 
is a web browser suppose to know which credentials to dump when the 
user hits a logout button in the web browser UI. During a page load 
multiple origins can be accessed and all may require credentials. But 
it seems mostly natural in a web application to include a logout 
button. I don't know of any web applications not having one. So why is 
it suddenly sufficient that the browser UI could have a logout button? 
And if it should why is it not being required in any spec? The whole 
purpose of these specs is to have some common denominator so building 
web sites/applications does not require having to know everything about 
every possible browser in use. It's about making life easy not hard. I 
really think some influential spec should say something about this.

>
>
>> 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?

HTTP authentication like HTTP itself is stateless. Form-based 
authentication isn't and requires the extra hurdle of having to persist 
a session key. As far as I can judge, form-based authentication has no 
pros over HTTP authentication. Other then the web developer being able 
to create a working logout procedure. Please note that one can also use 
a form to gather the credentials and login in through AJAX. But mostly 
I like the idea of it being in the HTTP protocol itself. Rather then 
implemented on top of it. It allows for futures expansions like 
upgrading to more secure authentication methods like Kerberos (I 
believe Microsoft is already doing this) or using client certificates 
(already possible). I don't see this happening with form-based 
authentication. When logging out is possible and well supported I 
actually see these more secure authentication methods becoming 
mainstream.

>
>
>> 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

Looking into it. Thanks for pointing that out.

>
>-- 
>Ian Hickson               U+1047E                )\._.,--....,'``.   
>fL
>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>,.
>Things that are impossible just take longer.  
>`._.-(,_..'--(,_..'`-.;.'
>

Received on Wednesday, 2 March 2011 01:20:54 UTC