[whatwg] Session Management

[Roger Hågensen]

On 2011-03-03 10:44, Dave Kok wrote:
> Op 02-03-11 22:11:48 schreef Roger Hågensen:
>> 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"*
> May I point out that the HTTP is outside the scope of the HTML5 spec.
> Also the HTTP is stateless. This requires both parties keep state which
> breaks the statelessness property of the HTTP. I, for one, prefer to
> preserve the statelessness property of HTTP.

"Please appreciate the notion that HTML5 is broader then just browsing
the internet." - Dave Kok

And indeed it is. HTTP Authentication (especially Digest) is far from 
stateless,
it's state chances with every single nonce number change.
It's basically a constant (but very cheap cpuwise) 
handshake/hmac/diffie-hellman agreement.
Also if you are thinking about the HTTP status codes, those are beyond 
stateless,
but if you insist, then simply re-use the 403 with some minor tweaks so 
it acts as a logoff,
because re-using 401 would break the statelessness as you say.

I'm surprised you advocate ajax/XMLHttpRequest and allow to close from a 
form,
that would open up to some security issues.
The beauty of HTTP Digest Authentication is that the password is never 
sent as plaintext or in any form that can compromise the user's password.
Only the user themself (and thus indirectly the browser) or the server 
should be able to initiate a session close of Auth Digest,
allowing it to close from a script is just bad, and... dare I say it, 
counter to the statelessness of HTTP *laughs*

At least we agree on one thing, that where HTTPS is not available or 
where the site owners have either not discovered or is too lazy or 
unable to take advantage of StartSSL.com which is free,
then HTTP Digest Authentication should almost be a requirement for any 
site that need login credentials. (like forums, shops etc.)
Funny how many stores only pull out the HTTPS stuff when paying for 
things you buy (or use a specialist service), but not at all when you 
log in to your account with them otherwise. *sigh*

Heck, I even have https on my own little site, my hoster provided the ip 
for free, they set up the certificate etc, for free, excellent service. 
(I only pay the hoster a small yearly fee, domeneshop.no for you 
Norwegians out there)
and combine that with startssl.com and my total cost of "securing" the 
communication with my site should I ever need it or others need 
it....??? PRICELESS, since it was absolutely free, not a single cent paid.
But... a lot of web hotels or hosters out there do not allow you to do 
SSL or it costs extra, or they can not give you a ip or it costs extra, 
and, and, and.
So I have sympathy for those unable to. but hey with the CA that 
provides free domain/server certs there is no excuse if you ARE able to,
and programmingwise it's less work too, Auth Digest needs some extra 
massaging from PHP to work nicely in a "integrated" way but even then 
the logout issue still exist (and even if you "log out" the sie is still 
spammed by the browser with login credentials all the time)
I've never really worked with the Apache auth_digest stuff, but it's 
probably even more restricted than doing it yourself via PHP.

And don't forget that you complain that my suggestions messed with HTTP 
which HTML5 had no business to mess with,
yet you yourself suggested XMLHttpRequest and some ajax stuff to 
close/end a HTTP authentication?
This already proves that HTML5 isn't just HTML + CSS + Javascript + lots 
of other stuff, but we can also add + HTTP
Now if this Auth Digest is so important for web apps, then shouldn't 
WHATWG work together with (um what is the HTTP group called?)....


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