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
