[whatwg] Session Management

[Bjartur Thorlacius]

On 3/2/11, Dave Kok <updates at davekok.net> wrote:
> Op 02-03-11 13:16:11 schreef Bjartur Thorlacius:
>>On 3/2/11, Dave Kok <updates at davekok.net> wrote:
>>> 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. [..]
>>Application protocols (FTP, HTTP) can trigger authentication. Users
>>can authenticate, and refuse to authenticate (e.g. by discarding
>>credentials). What additional features do you need, and to serve
>>what use cases?
>
> 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 beg to differ. When credentials have been entered, it may be feasible
to cache them as long as they're valid. In fact, writing autologin
daemons, renewing security tokens periodically, is on my to-do list.

> Simple use case description:
> - user navigates to start page of site, no authentication required,
> site knows session starts and tells UA.
> - user follows link to other page on same site, requiring
> authentication, UA associates credentials with current session (if it
> exists) somewhere hidden in the background.
> - user follows link named logout for instance. Site knows
> session ends and tells UA. UA now clears credentials cached between
You're suggesting that documents *should* duplicate UA functionality?
So I can use inconsistent UIs specific to each site, rather than
customizable UI that works with all sites?

This is not a use case that should be catered to specifically.

> session start and session end. Note UA is still managing the
> credentials not the site. Site has no knowledge of the credentials in
> any way as this is all handled within the HTTP protocol. The site
> doesn't even sees the credentials.
> - Alternative session end is when the user navigates away from origin
> (as specified in session start) or closes the browser window.
>
>>Ultimately, UAs must be able to discard all credentials (from all, or
>>a specific site) upon a single command.
>
> Yes, and this is unrelated to my feature request. I am not requested
> UA's should be disallowed to do this.
>
>>Just see what happens when users login to a site, then navigate to
>> another and authenticate to the latter, and then logout from the
>> latter. In that case, they're still authenticated to the former site.
>> In theory, this shouldn't be a problem, as users should clear all UA
>> data before granting anyone else access to the UA data store, but in
>> ill-managed public terminals, that may not be the case.
>
> Yes but do they? Theory is nice but can't a site aid a user in this?
>
If neither the sysadmin, nor the user, clear the credentials - who will?
This specifically is probably the main use case for expiring auth tokens.

>>> [..] 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?
>>It is not sufficient for a document to have one. It has to be possible
>>to discard credentials when no document is being rendered. For that to
>>happen, the UA needs to manage credentials.
>
> Yes, that is why I included a alternative session ending. In my
> original proposal. And no where that I propose UA's do not manage
> credentials.
>
Yes, but authentication forms being an UI is absolutely unacceptable.
There are things I expect my computer to do for me. APIs such as the
one you're proposing will only encourage authors to create forms that only
a human will understand. Heck, people have had trouble discarding my
Facebook credentials because my Facebook is localized in French,
whereas said people read only Icelandic, English and Danish.


>>> 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.
>>>
>>How users discard credentials is not up to the spec, neither HTML nor
>>HTTP. It shouldn't be against the spec to hard code credentials for
>>corporate sites into the UA used by the corporation.
>
> Neither am I proposing this. I am proposing that a site can tell the
> UA when a session starts and ends, because it often knows this. The UA
> has no knowledge if this. So it only clears credentials, sessionStorage
> and cookies without expiration when the user closes the window. In my
> opinion this should happen as soon as possible. I propose it is done
> when a site knows a session ends. However does not mean a UA can not
> override this.
>
I still can't imagine a case when a document knows a session has been
terminated, but neither the user nor the UA know.
Enlighten me.

>>
>>>>
>>>>
>>>>> 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.
>>>
>>tl; dr: We need to patch logout buttons into mainstream UAs.
>>
>>>>
>>>>
>>>>> 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 think users should initiate authentication and deauthentication.
>
> I think things should be as simple as possible for users.
>
I don't see the proposed interfaces as simplifying anything.
Being able to log out of all sites the same way is simplest for the
user. Anything else is unnecessarily complicated.

>>Also an HTML renderer and JavaScript VM  may not have a communication
>>channel with a HTTP UA feeding it data.
As in a pipe from htmlfmt to http.

>
> That would be unfortunate.
>
But simpler.
My ideal browser would be compromised of combination of a stateful
credential store (e.g. Factotum), UAs keeping various amounts of
state, depending on protocol requirements, and contemporary PDF, HTML,
JPEG, SVG, tab/csv, flv and Ogg rendering utilities spawned as needed
(with markdown easy to add).

Mainstream browsers don't seem well suited for rendering email messages. Yes,
know about, and like/tolerate Thunderbird.