[whatwg] Session Management
updates at davekok.net
Fri Mar 11 03:15:34 PST 2011
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
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
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
>> The proposal is restricted solely the HTML5 spec. Though in the
>> rational HTTP and authentication are mentioned as by example.
>> 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
>> 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
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
>Documents shouldn't have to concern themselves with session
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
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.
More information about the whatwg