[whatwg] Window id - a proposal to leverage session usage in web application

[Sebastian Hennebrueder]

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