[whatwg] Session Management

On 2011-03-02 18:42, Bjartur Thorlacius wrote:
>>
>>> 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.
>

Three Ways...

Method #1:
Browser timeout. For legacy reasons the browser could default to within 
a sensible min/max timeout.
Once the timeout is triggered, the HTTP Authentication is ended, and the 
the user has to log in again.
Like say maybe 30 minutes to 60 minutes.
This can easily be done right now for all current browsers. No UI 
changes or any real code changes at all.

Note:
Ideally the user should be able to adjust the default timeout within 
some sensible min/max range,
but this would require a UI change/addition.

Method #2:
A second way to "logout" from a HTTP Authentication would be to end the 
HTTP Authentication when the LAST tab or window is closed that is using 
the authentication to that site/directory.

Note:
It's a shame one can not use javascript to let the webdesigner provide a 
button or url with "javascript:window.close()" or similar.
Perhaps a "javascript:crypto.httpauth_closesession()" or similar could 
be added in the future.

Method #3:
The server (or serverside script, like PHP or similar) sends the 
following to the browser:
     header('HTTP/1.0 401 Unauthorized');
     header('WWW-Authenticate: Close realm="My Realm"');
     *PS! the auth stuff is much longer here obviously, this was just to 
show the use of "Close"*

Note:
If Method 1 or 2 is used the browser should probably send the following 
to the server:
     GET /private/index.html HTTP/1.1
     Authorization: Close username="something"
     *PS! the auth stuff is much longer here obviously, this was just to 
show the use of "Close"*


I think that Method 3 is the real key piece here, on it's own it allows 
the server to "timeout" the client/user AND notify the client that this 
has happen.
combined with Method 1 and 2 it is now possible for either the client or 
browser to end the http authentication session and notify each other, 
and let the user know as well.
Method 3 alone would not need a UI change, it would simply instruct the 
browser to clear it's auth session, the page content itself could hold a 
message from the server to the user that they are now logged out.

Explained as easily as possible, the closing is exactly the same as 
serverside "WWW-Authenticate: Digest" and clientside "Authorization: 
Digest" but
instead of the word Digest it is replaced with Close, the rest of the 
auth should otherwise be just like a normal Digest auth to ensure it's 
not a fake close.
just doing "WWW-Authenticate: Close" might be an issue with future 
improvements beyond Digest method, so maybe "WWW-Authenticate: Close 
Digest " would make more sense.
Just avoid calling it "Digest Close" as that could be confused with a 
normal "Digest".
"Close" is just an example, "End" or "Quit" or "Clear" could just as 
well be used, the word doesn't matter, the hint brings from the server 
to the browser is the vital key though.

It is basically the server saying to the browser that "those session 
credentials are no longer valid, please stop spamming me with them" 
*laughs* at which point the browser clears the auth session,
and starts talking to the site with a clean slate again. If something 
like Method 3 was implemented then I'm pretty sure that the devs of 
phpBB, vBulletin and who knows how many CMS devs out there would be 
happy to support this.

Sidesubject:
Hopefully the old WWW-Authenticate: Basic is fully deprecated soon as it 
is no different from plaintext html login forms (almost all forums and 
websites out there that do not use SSL/certificates).
WWW-Authenticate: Digest should be minimum requirement. I'm not sure but 
I believe that Opera did fix some of the issue with Basic being fallen 
back to, no idea how all browsers lay on this currently.
It would be tempting to fix the Basic issue and security "hole" by 
instead changing things so that it's called: "WWW-Authenticate2: Digest" 
and "WWW-Authenticate2: Close Digest" where Basic is not allowed at all,
this would prevent exploits that try to sneak Basic into the header and 
make the browser use plain text instead.

-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/

Received on Wednesday, 2 March 2011 13:11:48 UTC