[whatwg] Window id - a proposal to leverage session usage in web application
Sebastian Hennebrueder
usenet at laliluna.de
Wed Feb 10 03:12:18 PST 2010
Martin Atkins schrieb:
> Sebastian Hennebrueder wrote:
>>
>> thank you for the feedback. I hope that I see your point correctly.
>> You are right, that for JavaScript based applications this can easily
>> be solved with a sessionStorage. All technologies around
>> GoogleWebToolkit, Dojo, Echo etc which hold the state in the client
>> and make use of a stateless server side application can use the
>> session storage to distinguish browser windows.
>>
>> But there are a lot of web technologies which hold the state on the
>> server using the browser session. Technologies like Ruby on Rails,
>> JavaServerFaces, Wicket, Struts, Tapestry to name a couple of them.
>> Those technologies can not make a simple use of the session storage.
>> They are only aware of the browser session which is a common space of
>> all browser windows. The windows id let them split the session in a
>> per browser window scope.
>>
>> Originally, when playing with the window id concept, I simulated a
>> window id by storing it in a session storage and adding it with the
>> help of JavaScript as parameter to all links and as hidden field to
>> all forms. It works to some extend but it pollutes the URL and is
>> likely to cause problems with bookmarking and there is a use case
>> where it fails. If you open a link in a new windows. In that case the
>> first request is sending the wrong windows id.
>>
>>
>
> The server-side session management you describe is usually implemented
> via cookies, which as you note are scoped to a particular site and do
> not consider a particular window.
>
> Cookies and sessionStorage are conceptually similar in that both of them
> are mechanisms to allow a site to store data on the client.
> sessionStorage sets the scope of this data to be a (site, window) tuple
> rather than just site.
>
I am aware of this and agree.
> So it seems like your use-case could also be addressed by providing an
> interface to sessionStorage that uses HTTP headers, allowing the server
> to use sessionStorage in the same way that cookies are used, without
> requiring client-side script and thus requiring the data to be set via
> an HTML page.
>
> To emulate the server-side session mechanisms you describe, you'd simply
> use a single sessionStorage value containing a session id which gets set
> in response to any request that does not provide it.
>
This sounds interesting and is probably a lot better aligned to the
current sessionStorage/localStorage functionality. Just to make sure,
that I have understood you correctly.
Case a)
Users enters a fresh URL.
Server receives a request without a window scoped sessionStorage id.
Server renders the page and adds a response header
sessionStorage.myid: 3452345 // a random number
Browser reads the header and creates a JavaScript call
sessionStorage.myid=3452345;
Case b)
A follow up request of the browser includes the sessionStorage.myid value
The server can read data from his scoped HTTPSession.
// pseudo code of the server
id = request['sessionStorage.myid']
session = getSessionHashMap()
contextHashMap = session[id]
someValue = contextHashMap['someValueKey']
Case c)
open a link in a new browser windows
would behave like a)
-> possible issues to address
Request header might become too large. Somehow the browser should be
instructed to add only specific sessionStorage/localStorage values to
the request. This could be a flag in the response header or / and a
cookey like approach.
A lot more security related behaviour need to be defined. I assume that
it will follow about the same caveats as the sessionStorage/localStorage
on the client.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
More information about the whatwg
mailing list