[whatwg] Fwd: Session Management

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Sun, 12 Dec 2010 01:30:08 +0000
Subject: Re: [whatwg] Session Management
To: Dave Kok <email at davekok.nl>

On 12/6/10, Dave Kok <email at davekok.nl> wrote:
> Op 06-12-10 00:28:04 schreef Bjartur Thorlacius:
>>On Thu, 25 Nov 2010 09:05:12 -0000, Dave Kok <updates at davekok.net>
>>wrote:
>> I don?t believe so.
> My apologies, but to answer you questions anyways.
>
>> Please provide an example situation in which the author will know
>> that a session has ended, but the UA does not.
>> In the nonstandard authentication cookie world the user usually
>> informs a site that a session is over, which returns a instruction
>> for the UA to delete session information. Informing the UA directly
>> is way simpler and eliminates security implications of an UA loosing
>> the connection to a site (possibly due to a DoS attach).
>
> If I understand you correctly than the author would know a session has
> ended when the user clicks on a logout button on a page within the UA.
> However a session could also end when the user navigates away from the
> origin. This would only be known to the UA. Please note that I am
> discussing HTTP authentication not cookie-based authentication.
>
Why would clicking a logout button in a page within the UA be
preferable to telling the UA directly to discard credentials?

>>Logout (ie, session terminating) buttons are already implementable.
>>The UA can delete session information when it desires. The only thing
>>that may need to be standardized is the informal of the site. The site
>>could delete all session state it holds, disabling session hijacking
>>after the UA has terminated the session. It's unclear to me what that
>>state would be, whether holding said data is reasonable in the first
>>place and what harm it may do to keep it.
>
> To my knowledge there is no way to implement a logout button for HTTP
> authentication. At least not without resorting to quirks and
> workarounds. But if you know of a standard way, please share. I
> haven't been able to find something workable for all browsers.
> Off course a UA can delete the session state whenever it desires. As
> long as the UA does not reintroduce session state from a terminated
> session to a new session. This talk is mostly about usability not about
> security.
>
It doesn't need to work the same way in all browsers. They're multiple
because they're different (or should be, in theory). Standardization
would only be to limit diversity. Imposing standardized user
interfaces in technical standards not specifically about user
interfaces is considered bad practice.

Discussions regarding implementational UI details should probably be
addressed to implementors. Try moving the discussion to
<implementors at lists.whatwg.org> or filing bugs.

>>IMO servers should be kept completely stateless and transparent to
>>  whether an UA manages sessions or not. The standard authentication
>>methods are completely stateless, sessions are an implementational UI
>>detail.
>
> I completely agree. Servers should be stateless and transparent and it
> is this implementational UI detail I wish to discuss. Right now a user
> can login to a site using standard authentication methods but these
> standard methods do not provide a means to logout, as they are indeed
> stateless and should be. UA's do not provide an obvious way to clear
> credentials to be of help to a user wishing to logout. IMO they should
> not either. A web developer should be able to provide such an obvious
> way within the page. However no means of control is provided to a web
> developer to clear credentials. It least no standardized method. As
> this is purely a usability issue at the end-user site and not an issue
> with the HTTP protocol, HTML5 would be a perfect target for providing a
> standard method at least in my opinion.
As "this is purely a usability issue at the end-user site," this
should be solved at the end-user site.

> Best I can come up with is
> giving a web developer the means to tell the UA a new session should
> start on a origin. After that a web developer can tell the UA a session
> should end. Doing this purely in HTML5 would have no impact on existing
> web applications or HTML documents, protected or otherwise. Nor thus it
> alter the way HTTP protocol itself works.
This brakes HTTP layering. do you expect all HTTP UAs to scan their
payload for state instructions? Currently, you can make a simple UA
that fetches files from a HTTP server, looks their Content-Type up and
executes a suitable viewer for that type, and said viewer has only to
know how to invoke another fetch. With your proposal, it also has to
know how to tell the HTTP client to delete state. OK, script-set HTTP
cookies might be a PITA. But we don't need more of that, not if the
desired use cases can already be fulfilled.
> All that has to be done
> within the UA is track when a session is started. Link all credentials
> entered to HTTP authentication to this session and delete those
> credentials when the session is either terminated programmatically or
> when the user navigates away from the origin. Note that sessions in
> this context could be nested. Nested session should also terminated
> when the top session is terminated.
>
It's none of a web developers concern when a user decides to terminate
sessions or wether he uses them at all. A HTTP server sees a request,
authorizes it and responds with a HTML document. Rinse and repeat.
Sessions don't matter at all. It's just a UI convention a UA may use.

An graphical interactive UA may provide a "logout button" if desired.
An user may click such a button if he likes to. Why would you want to
complicate this with origins and potential security risks? Nobody but
the UA and the UA's master, the user, may trigger state resets.

This

> Hopefully I have expressed myself in a non-confusing way.
You have expressed yourself, but we seem to have fundamentally
different views of the purpose of HTML. I still don't understand why
it would be feasible to allow documents to log users from HTTP
servers.

Received on Saturday, 11 December 2010 17:30:55 UTC