[whatwg] Session Management

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

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

>
> 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.
>
>
> Prototype:
> window.sessionStart([string path = "/", [boolean auto_end = false]]);
>
> The session start function should indicate to the UA that a new session
> is requested by the author for the current browsing context. From this
> point forward any session data should be associated with this session.
> However this is only done for documents loaded from the same origin or
> if a path is supplied for that path and sub paths of that path within
> the current origin. The auto_end argument may be supplied if a session
> should automatically end when the user navigates away from documents
> within the origin[/path].
>
Are authentication mechanisms guaranteed to use origins as defined by
HTML? Or are UAs to apply unobvious criteria to credential discarding?

>
> Prototype:
> window.sessionEnd([boolean clearHistory = false]);
>
> The session end function should indicate to the UA that the current
> session is no longer valid. The UA can now stop associating session
> data with this session and unreference any session data associated with
> this session. The clearHistory parameter requests the UA, if true, to
> clear any documents within the back/forward history that have been
> loaded between session start and session end. UA's are only encouraged
> to do this for documents that required authentication and for which re-
> authentication is required after sessionEnd. This to prevent
> unauthorized access to cached documents by using the back/forward
> functionality to access information that would otherwise require
> authentication.
>
>
> Session data:
>
> What a UA considers session data in the context of this proposal is
> for a UA to decide but at minimal it is required to include data stored
> in the sessionStorage and cookies created through the document.cookie
> interface without expiration and any credentials supplied through the
> XMLHttpRequest.open function if the UA manages these. Additionally
> a UA is encouraged to include any cookies received without expiration
> from any source especially when made available through the
> document.cookie interface pertaining to the current origin[/path]. Any
> credentials that are cached for documents within origin[/path] and
> additional resources referenced by these documents whether or not
> within the origin[/path]. But only if the UA marks these for auto
> cleaning when the UA itself terminates.
>
>
> Ending sessions
>
> A UA is never required to wait until the sessionEnd is called before
> it ends a session and cleans associated data/state. But is encouraged
> not to selectively clean session data/state while sessionEnd has not
> been called. In others words all or nothing is preferred. A session is
> automatically ended when a current browsing context is closed. A UA may
> also have additional methods to force a session to end.
>
>
> 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?

> Basic usage scenario:
> 1. The user has navigated to a document and follows a link on which the
> author registered a onclick event and the event handler calls
> sessionStart. The UA now creates a new session, event handler ends and
> the UA loads the indicated document. If this document is within the
> scope of the session and authentication is required and no prior
> credentials exists, it gathers these credentials either from an
> external source or from the user and associates these with the
> session if it intends to dispose of these automatically when the UA
> itself terminates.
> 2. The user reads, clicks, types and follows links to other documents
> within the same origin[/path]. Possibly causing additional session data
> to be associated with this session.
> 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.

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.
UAs would also have to notify users explicitly about logouts triggered by
scripts.

Documents shouldn't have to concern themselves with session management.
It's very unclear how this will interact with authentication agents.
In fact, it
may be simpler for this to clear only sessionStorage (and maybe select
other datastores in a JavaScript VM's care).

>
> What if's:
> 1. the user follows a link, clicks on a bookmark or enters a URL
> outside the origin[/path] for the current session. If auto_end was set
> to true. The session is ended as in step 3 of above scenario.
>

Bjartur, yet another end-user.