[whatwg] Proposal: HTTP Headers + sessionStorage stored session-ID
David Bruant
bruant.d at gmail.com
Thu Oct 31 04:01:41 PDT 2013
Hi Kyle,
Le 30/10/2013 22:54, Kyle Simpson a écrit :
> Thoughts?
Kyle wrote:
> BUT we cannot, currently, have that sessionStorage-stored session-ID
> automatically transmitted with each normal page request.
>
> This means that the initial page-response from the server, even in the
> case where someone has a valid session, must be session-unaware, and
> the SPA code on the client side must update the page with
> session-aware info "later", since the session-ID on the client wasn't
> provided with the initial HTTP request like a session-cookie would
> have been.
>
Why not just use cookies ? I feel they're sufficient to do what you need.
Asked differently: in what way are cookies insufficient so that we need
a new different API/feature?
I'm worried about your proposal as it reinvents a new sort of cookies
with the same issues of current cookies (consequences of ID theft,
ability of third-party tracking, XSRF, etc.). On cookies, I recommand
reading the 6.3.4.2 section of
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm
(notice it's been written a bit before 2000 so with an understanding of
the web back then).
On designing "sessions" without cookies, I recommand reading
http://waterken.sourceforge.net/web-key/ (where everything uses URLs
without the need of HTTP headers at all).
Cookies were a mistake. They've made web dev (marginally?) easier, but
I'm not sure their cost in terms of security and privacy (after a year
of trying hard, Mozilla still fails at getting rid of 3rd party cookies)
was worth it. If we applied the principle of constituency on cookies
today, they'd probably be refused right away... but we can't go back of
course. Yet another web regret.
David
More information about the whatwg
mailing list