[whatwg] Session Management

Op 10-03-11 20:02:26 schreef Bjartur Thorlacius:
>On 3/3/11, Dave Kok <updates at davekok.net> wrote:
>> Here is a more formal proposal for Session Management. Hoping to get
>> more traction.
>>
>Your former proposal was very well formed. The only thing I don't see
>is a good use case making this proposal worthy of endorsement and
>implementation.

The use case, as I imagine it, is mostly for web applications. I 
noticed that WHATWG also maintains a web application spec containing 
HTML5. I wasn't aware of it, I thought it was the same spec. This 
feature may better fit within that spec then HTML5. But I'll leave that 
to the spec writers.

For web sites that have no defined workflow and thus every document has 
it's own merit for existing there may not be a use case. However 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.

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. This proposal simply provides for a fine-grained method 
of clean up after the web site/application much like an OS does for 
a desktop applications. Having such a method also paves the way better
resource management by UA and perhaps better separation between web 
sites/applications. For instance one can imagine a UA imposing more 
security by not allowing documents from a different origin (and 
optionally path) access to any session data including reusing 
cached credentials. In the case of off line applications (using the 
CACHE MANIFEST) it may even be of interest to have a session survive 
even beyond the UA itself terminating and only have it end when 
sessionEnd is called. (Just wild thoughts outside the scope of this 
proposal.)

>>
>> SCOPE
>>
>> The proposal is restricted solely the HTML5 spec. Though in the
>> rational HTTP and authentication are mentioned as by example.
>>
>Fair enough.
>
>>

>> RATIONAL
>>
>> The rational of this feature is to provide an easy method to clean
>> session data/state after it is no longer required. How and when
>> session data is cleaned when sessionStart is never called is not 
>> specified by this proposal. Implementers are encouraged to ignore 
>> any calls to sessionEnd if sessionStart has never been called. They 
>> may off course emit a warning/notice to aid an author in debugging.
>>
>Blame my ignorance, but I haven't got this straight yet:
>When is sessionEnd supposed to be called? Is it for garbage 
>collection? Is it to be called before a user hands a public UA 
>(public terminal) over to another user?

Think of sessionEnd as terminating a regular desktop application. Like 
the user clicking on the close button in the upper right corner. 
However the user doesn't use it directly but an author can use it at an 
appropriate place within a web site/application. Please note that 
sessionEnd is not meant to be a security feature. UA's can not rely on
this to provide better security. Thus in the case of a public terminal 
some other method must be used to ensure session data has been cleared 
before switching users (if this is at all possible). But it may help a 
UA to determine what needs to be cleaned.

Also as the proposal is currently formulated an author may request 
a session to automatically end when the user navigates away from the 
origin (and optional path) of the web site/application. In this case 
the UA triggers the sessionEnd on it own. Alternatively if a UA 
provides a logout button this may too trigger sessionEnd.

In the case of public terminals it may be interesting to force the 
auto_end feature.

>> 3. The user follows a link on which to author registered a onclick
>> event handler. The event handler calls sessionEnd. The UA now
>> unreferences any session data associated with the session, event
>> handler ends and the UA loads the document indicated by the link. On
>> a side note this may very well be superior to a UA UI logout 
>> button. As the author can also specify a URL to go to after the 
>> session has ended. A UA UI logout button may not be able to do this 
>> in a meaningful way.
>>
>This is were we disagree.
>I find it annoying to be directed to some endorsed resource, after
>being logged out.

I can understand this sentiment. But don't see in the scope of this 
proposal how to prevent this.

>It's suboptimal to have both a logout button embedded into documents,
>and one provided by the UA. If all documents include a logout button, 
>UAs will remove or hide logout buttons to a greater extent.

This may very well be a natural consequence of having a proposal like 
this implemented. But this would assume that implementers feel that 
having a logout button embedded into documents is considered superior 
then having a UA provided logout button. Otherwise such a thing would 
never happen. Also authors have the freedom to use either a custom 
authentication method or a UA provided authentication method. Though I 
too prefer the UA provided authentication method we can't force authors 
to do so. A UA provided logout button alone thus not cover custom 
authentication methods like form-based authentication. Since these web 
sites/applications won't just suddenly die out, would it not be more 
consistent for the user-experience to have an embedded logout button? 
Also this proposal can work for both methods. As custom authentication 
methods often use session cookies for which I did recommend them being 
session data and be deleted at sessionEnd.

Just out of curiosity have you proposed something concrete on this 
topic in the past (being more precise then just saying you want a 
logout button). Also to my knowledge there is no spec covering a UA's 
interface. Where would you spec such a logout button?

>UAs would also have to notify users explicitly about logouts triggered
>by scripts.

Really, why? Does an OS notify you when you logged out of your e-mail 
client? If web site/application caused you to login in the first place 
why should a UA notify you when the same web site/application causes 
you to log out? Please note the sessionStart must be called 
before the log in takes place to work effectively. Thus a user must 
follow a workflow. This feature can't be used to clear credentials from 
cache when a user decided to just visit a document requiring 
authentication. In such a case the web site/application would have no 
opportunity to call sessionStart before authentication happens. Aren't 
you thinking too much on a page by page level? Sessions don't exist at 
that level.

>Documents shouldn't have to concern themselves with session 
>management.

Web site/applications have no choice but to concern them self with 
session management. The whole purpose of this proposal is to be as 
little concerned as possible about session management and have the UA 
do most of the work. Please note that right now a web site/application 
must do cleanup of session data that should no longer be used. Because 
a user may very well decide to reuse the current browsing context to 
revisit the web site/application. For instance a user may have entered 
a workflow decided to "logout" so to speak. Then login again and get an 
unclean session that may hamper the user experience. That is clearly 
unacceptable, so at logout or login an author must unsure the user can 
begin again in a known state. This proposal for session management only 
lessens the burden. It doesn't increase it (and is very much optional).

>It's very unclear how this will interact with authentication agents.

There is no uncertainty about how it well interact with authentication 
agents. Right now a UA has a choice to either consult a authentication 
agent to check for existing credentials, consult it's own store of 
credentials or ask the user. This proposal in no way effects this. To 
my knowledge no authentication agent or authentication framework 
prohibits a UA to cache those credentials for reuse until session end 
or at some defined expiration time. And with or without this proposal a 
session will end and the credentials will be removed from cache. If not 
it would be a considerable security breach. Authentication agents rely 
on this otherwise they have no control if a UA can just mine 
credentials to use forever. If we look at Kerberos for instance it 
allows a client (UA) to get a ticket and use this ticket until it 
expires. While the ticket is valid it doesn't have to check with the 
key server if it is still valid. It may just use it. When the client 
terminates (the ultimate session end) the cached ticket is disposed of 
whether or not it is still valid. Thus the cached ticket is so to speak 
session data. What this proposal effectively does is simulate a program 
startup and shutdown for a web site/application. There is a clear mark 
when a session starts and thus all session data after the session start 
is marked as belonging to this session. At session end it is deleted. 
Pretty much the same way it works in a desktop application.

Truly I can understand you wish to have a UA provided logout button but 
just wanting one is not enough. You have to specify what exactly is 
deleted at logout and why, and what not and why not. Otherwise we will 
have inconsistent implementations.

>In fact, it may be simpler for this to clear only sessionStorage (and 
>maybe select other datastores in a JavaScript VM's care).

If we are going to have a method for tracking session data, I would 
prefer it is all session data is included.

>
>Bjartur, yet another end-user.
>

Received on Friday, 11 March 2011 03:15:34 UTC