[whatwg] Session Management

02-03-11 18:42:41 schreef Bjartur Thorlacius:
>On 3/2/11, Dave Kok <updates at davekok.net> wrote:
>> 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?
>>
>I beg to differ. When credentials have been entered, it may be 
> feasible
>to cache them as long as they're valid. In fact, writing autologin
>daemons, renewing security tokens periodically, is on my to-do list.

So what does your argument boil down to. Having a method that a site 
can communicate to a UA that a session starts and ends, means that a UA 
can not provide a feature to keep a user always logged in? And because 
this interests you such a feature should not be included in the spec? 
Even for those UA's that do not have such a feature or in which it is 
very much desirable to have such a feature. Isn't it simply more 
interesting to say that a site may communicate when a session starts 
and ends and that a UA behaves the way a user wants it to (or a 
developer of the UA, proxy or what not, designed it to do). Whether 
this means clearing credentials or not. As far as I am concerned all
that a site needs to know about, is about a session. And all it should 
be able to do is tell the UA when it starts or ends. Does having such a 
feature make it impossible for you to implement what you intend to?

>
>> 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
>You're suggesting that documents *should* duplicate UA functionality?
>So I can use inconsistent UIs specific to each site, rather than
>customizable UI that works with all sites?
>
>This is not a use case that should be catered to specifically.

No no no, there is no duplication. A UA doesn't manage sessions. Sites 
manage sessions. All a UA does is cleanup when it knows sessionStorage,
session cookies and cached credentials are not going to be used any 
more or when a user requests those to be cleaned. A site enters stuff 
in the sessionStorage and creates session cookies when it needs 
to. And if it hampers functionality of the site cleans these thing up 
so if the user wishes to end and start a new session without opening a 
new window it gets a clean session. The only thing which makes the 
session unclean is those credentials still hanging around somewhere. 
Personally I just don't understand why you aren't thrilled about having 
this feature. It sounds like you are very infested in HTTP 
authentication. If all sites where to use it this would definitely 
broaden your scope for what you are doing. I just don't see how having 
a form of session control added to the spec restricts a UA in anyway 
of providing any feature a user desires. Just because a site says: 'UA 
session ends', doesn't mean that the UA has to do anything. Only 
those things that are sensible for the user experience. And for those 
UA's for which it is sensible to clear cached authentication tokens, 
they can do so. For those for which it is not, those don't. I am just 
providing a rational for having session management and what it could 
do. Implementers however will have to decide what to do with the 
signals session start/end. No way do I intend to restrict UA's. Just 
asking for additional signals between UA's and sites.

>
>> 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?
>>
>If neither the sysadmin, nor the user, clear the credentials - who
>will?
>This specifically is probably the main use case for expiring auth
>tokens.

I don't get it. What are you pointing out here? How does a sysadmin 
figure into to this. Aren't sysadmins like always capable to do 
anything. And isn't a user always capable of clearing session data. To 
my knowledge all UA's provide this feature. How does this proposal 
effect that?

>
>>>> [..] 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.
>>
>Yes, but authentication forms being an UI is absolutely unacceptable.
>There are things I expect my computer to do for me. APIs such as the
>one you're proposing will only encourage authors to create forms that
>only
>a human will understand. Heck, people have had trouble discarding my
>Facebook credentials because my Facebook is localized in French,
>whereas said people read only Icelandic, English and Danish.

You clearly are operating on a very different wavelength. I very much 
appreciate your feedback but I am afraid I can't follow you in this
instance. Boiling it down. My proposal adds session management control 
for sites to the spec. HTTP protocol remains unaffected. Session 
management means a site can tell a UA that a session starts and ends. 
Ideally this encourage HTML5 authors to start using HTTP-authentication 
and stop using form-based authentication. Whether this means they do it 
with a form and then pass the username and password to a 
XMLHttpRequest.open function or leave it up to the UA to popup a dialog 
should not impact how credentials are manage by the UA. I expect this 
to be fully transparent to any intermediate proxy or some 
authentication deamon. In these cases they will simply see a outgoing 
HTTP request with an auth token included. Am I overlooking something?

>
>>>> 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 still can't imagine a case when a document knows a session has been
>terminated, but neither the user nor the UA know.
>Enlighten me.

The user knows because he takes the action to end the session. He is 
the one following a link that would ideally end the session. When the 
user follows a link which he/she assumes ends the session (because it 
is named a certain way), the UA doesn't know about it. Cause all the UA 
knows is that he/she is following a link and loads that page. However 
the site author named that link and put it on the page so when 
the user follows it the author knows that the session ends. Have I got 
it wrong? If not isn't a good idea to that the site can tell the UA 
about this? Giving the UA the opportunity to do some cleanup if it 
configured or implemented to do so.

>
>>>
>>>>>
>>>>>
>>>>>> 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.
>>
>I don't see the proposed interfaces as simplifying anything.
>Being able to log out of all sites the same way is simplest for the
>user. Anything else is unnecessarily complicated.

Please appreciate the notion that HTML5 is broader then just browsing 
the internet. It is perfectly feasible to use a browser as a front-end 
to a local application. In these instances it would be undesirable to 
have any UA UI's getting in the way. As for the normal browsing 
experience your argument has merit. But HTML5 isn't just for browsing 
the web. It is perfectly legal to use it as UI interface language. As 
far as I can see there seems to be a trend to do so. Way else do 
implementers include features like app-mode?

>
>>>Also an HTML renderer and JavaScript VM  may not have a 
>>> communication
>>>channel with a HTTP UA feeding it data.
>As in a pipe from htmlfmt to http.
>
>>
>> That would be unfortunate.
>>
>But simpler.
>My ideal browser would be compromised of combination of a stateful
>credential store (e.g. Factotum), UAs keeping various amounts of
>state, depending on protocol requirements, and contemporary PDF, HTML,
>JPEG, SVG, tab/csv, flv and Ogg rendering utilities spawned as needed
>(with markdown easy to add).
>
>Mainstream browsers don't seem well suited for rendering email
>messages. Yes, know about, and like/tolerate Thunderbird.
>

Can your ideal browser not exist with this feature? And should the 
HTML5 spec be restricted to just cater for the needs of browsing, or 
may it be broader? Why should developers only use HTML5 when creating 
web sites/application and not reuse their skills with HTML5 when 
writing desktop applications?

Received on Thursday, 3 March 2011 01:25:11 UTC