[whatwg] Session Management

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'