[whatwg] Session Management

[Dave Kok]

Op 03-03-11 12:17:22 schreef 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/
>
>

Hmm, within the scope of this feature request I am not advocating AJAX. 
Just mentioned it as it can be used to login, see XMLHttpRequest.open. 
It allows for a username and password to be passed in. Personally 
however I prefer to let the UA handle this. Please note that at 
XMLHttpRequest.open level nothing is known of HTTP or whether HTTP-
basic or HTTP-digest is used. To me this is an issue to be solved at 
a layer lower then HTML5. And whether HTTP, FTP or some other protocol 
is used to transfer data and do authentication it pretty much outside 
the scope of my feature request. Also I didn't suggest using AJAX to 
terminate the session. Read the full thread.

As to whether HTTP is stateless or not, then yes between the 
request and response, state is kept but not beyond. At least to my 
knowledge, I haven't read up on HTTP-digest yet beyond just using it. 
So no comment on that.

Also the reason why I target my feature request at this mailing list is 
because it targets the HTML5 spec. Certainly WHATWG can work together 
the IETF (and they properly do) but I don't expect them to just because 
I have an idea. If my idea concern HTML5 I drop a mail to this mailing 
list if it concern HTTP, I will draft a RFC. I my idea concerns both I 
do both and split my idea in two. I hope this attitude does not offend 
you and that you can appreciate, in the light of this, why I responded 
in the way I did.

Thanks for responding and brainstorming though. I trust that my 
response is of proper quality.

--
Dave