[whatwg] Session Management

[Cameron Heavon-Jones]

i'd like to reference a proposal i put forward in relation to expanding the functionality of forms which displays how http authentication could be implemented declaratively by html authors:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html

thanks,
cameron jones


On 10/06/2011, at 1:00 AM, Ian Hickson wrote:

> On Tue, 1 Mar 2011, Boris Zbarsky wrote:
>> On 3/1/11 5:29 PM, Ian Hickson 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.
>> 
>> For what it's worth, Firefox even has UI for this....
> 
> Indeed.
> 
> 
> On Wed, 2 Mar 2011, Dave Kok wrote:
>> 
>> You can also login using AJAX requests. This breaks the idea of it being 
>> purely a UI matter.
> 
> How so?
> 
> 
>> Also browsers don't all do this.
> 
> They all don't do whatever else we come up with to solve this, too.
> 
> 
>> 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.
> 
> If you really want to control it from within the page, just use another 
> credential mechanism, like form-submitted login and cookies.
> 
> 
>> Also as web developers are requesting this over and over again there 
>> seems to be a real need.
> 
> Compared to other features, this is not requested that often.
> 
> 
>> Just saying that the web browser UI should do it is not getting the job 
>> done.
> 
> Why would it be any more effective to do anything else?
> 
> 
>> 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.
> 
> That's also a UI issue. For example, the browser could just dump all the 
> credentials for the sessions started in the current tab, or it could show 
> the user a list of credentials that the user can pick to drop.
> 
> 
>> 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.
> 
> If they all have it, then there's no problem. :-)
> 
> 
>> So why is it suddenly sufficient that the browser UI could have a logout 
>> button?
> 
> For HTTP auth, the login is also done by the browser's UI. So it makes 
> sense that the logout should be done by the browser also.
> 
> 
>> And if it should why is it not being required in any spec?
> 
> We don't require UI of any kind.
> 
> 
>> 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.
> 
> There aren't really any influential specs when it comes to UI (or much of 
> anything else -- specs only appear influential if they happen to spec what 
> implementors want to do anyway).
> 
> 
>>>> 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.
> 
> Ironically, it's the fact that HTTP authentication is state_ful_ that is 
> causing you trouble here.
> 
> 
>> 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.
> 
> That seems very arbitrary.
> 
> 
>> 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.
> 
> I'm rather skeptical, personally. Client certificates are an 
> authentication mechanism that baffles regular users.
> 
> 
> On Wed, 2 Mar 2011, Dave Kok wrote:
>> 
>> Unrelated, how authentication is triggered has nothing to do with when 
>> it is cleared. But after authentication has been triggered and the user 
>> has entered it credentials (or used credentials that are pre- filled by 
>> the UA) those credentials are cached for automatic reuse, so the user 
>> does not have to log in and log in over and over again. Very useful, we 
>> all love it. But at some point those cached credentials must be cleared 
>> so the UA triggers again a dialog to require the user to log in again 
>> (possible again pre-filling credentials from some store). It is the 
>> clearing I propose a site should be able to aid the UA in. This is not a 
>> simple thing as the site does not know the credentials, as it should. 
>> But it often does now when a session starts and ends. So when it can 
>> communicate this to the UA, the UA can use this info to clear 
>> credentials at the appropriate time. Rather then waiting when the user 
>> closes the window or manually clears credentials using a browser UI 
>> feature. Should a user be expected to do this?
> 
> I recommend bringing these questions up with browser vendors and seeing if 
> they are interested in implementing some experimental features for it, as 
> per this question in the FAQ:
> 
>   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
> 
> One question that I think is relevant for such a proposal is: how can a 
> Web page know when a session has ended? Users don't typically hit the 
> logout button, do they?
> 
> Then again, personally I never consider my sessions over. Once I've logged 
> in, I want to remain logged in until the machine dies a final death. It 
> drives me crazy that I keep having to log in to my bank's Web app.
> 
> 
> On Thu, 3 Mar 2011, Dave Kok wrote:
>> 
>> Please appreciate the notion that HTML5 is broader then just browsing 
>> the internet.
> 
> At least for the purposes of the WHATWG, this is not the case. We are only 
> focusing on making the Web better. Other applications may benefit as a 
> side-effect, but they are not a consideration. We have enough difficulty 
> making a language for the Web without trying to make it fit other worlds 
> as well!
> 
> 
> On Thu, 3 Mar 2011, Dave Kok wrote:
>> 
>> Here is a more formal proposal for Session Management. Hoping to get 
>> more traction.
>> 
>> SCOPE
>> 
>> The proposal is restricted solely the HTML5 spec. Though in the rational 
>> HTTP and authentication are mentioned as by example.
>> 
>> INTERFACE
>> 
>> This proposal requests for an new interface to be added to HTML5 usable 
>> from script. The interface is currently defined on the window global 
>> object. The naming is chosen so it seems natural to co-exist with 
>> sessionStorage.
> 
> The first step here is describing the problem, not the solution.
> 
> We can't evaluate solutions without knowing what problems they solve.
> 
> 
> On Fri, 11 Mar 2011, Dave Kok wrote:
>> 
>> [In] the case of a web application in which a lot of documents are 
>> interdependent the use case becomes self-evidence, at least to me. Often 
>> these sites have a particular workflow. You start here then go there and 
>> so on. Often there is a single starting point. Like a page on which you 
>> get the option to login or register. Once logged in you are rerouted to 
>> a page for instance that contains messages of things that have changed 
>> since you last logged in. This off course all very much depends on the 
>> type of web site/application. However I don't think anyone is going to 
>> think that a web-based email client exists of independent pages that you 
>> can just bookmark and revisit later. These pages often have additional 
>> state that is build up in the course of using the web site/application. 
>> This state (session data) can't be bookmarked.
> 
> You can bookmark GMail pages just fine as far as I can tell.
> 
> 
>> In these instances having a defined method of telling the UA where a 
>> session begins and ends is useful to the point that it allows a UA to 
>> track what session data belongs to the session and clean it when no 
>> longer useful.
> 
> That doesn't really seem compatible with how the Web works. In the Web you 
> can go to a page, then open links from that page in many tabs, then close 
> some, open more, then close all of them, then unclose a tab, then bookmark 
> it, then reboot, then reopen the bookmark...
> 
> I don't really understand what problem a "session" concept solves. The 
> problems with authentication on the Web today aren't about session ends, 
> they're about identity, lack of multi-factor login, weak passwords, weak 
> account recovery features, etc. If anything is wrong with "logout" on the 
> Web, it's that sites are too _eager_ to log me out, IMHO!
> 
> 
>> Think of sessionEnd as terminating a regular desktop application.
> 
> Regular desktop applications are specifically moving _away_ from this 
> model. See OS X Lion's session resume features, session restore in 
> Firefox, Opera, Safari, or Chrome... heck, even software in the 90s (e.g. 
> Turbo Pascal) used to resume sessions automatically. OSes themselves have 
> long had suspend/hibernation features to resume state.
> 
> Terminating sessions seems to be largely considered a bug, not a feature.
> 
> 
>> Does an OS notify you when you logged out of your e-mail client?
> 
> You can log out of desktop e-mail clients?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'