[whatwg] Session Management

[Dave Kok]

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?

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

>> [..] 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.

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

>Also an HTML renderer and JavaScript VM  may not have a communication
>channel with a HTTP UA feeding it data.

That would be unfortunate.