Re: [whatwg] Window id - a proposal to leverage session usage in web application
Ian Hickson schrieb: On Thu, 4 Feb 2010, Sebastian Hennebrueder wrote: About half a year ago I came up with an idea to add a unique window id as request header to each browser request. I published this initially on my website http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html The best way to get something like this into the specs is to follow the steps outlined here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F HTH, Hello Ian, thank you for the pointer. I had been busy the last weeks and will continue working on this the next week. In the web app mailing list people pointed out that this could be part of another spec as well. I need to carefully read both and will come back. -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de
Re: [whatwg] Window id - a proposal to leverage session usage in web application
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
[whatwg] Window id - a proposal to leverage session usage in web application
Hi all, About half a year ago I came up with an idea to add a unique window id as request header to each browser request. I published this initially on my website http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html About a week ago, I have stumbled upon the WebApps Working Group which sent me over to the whatwg user group. What is the idea about? The browser should generate an id unique per browser window and sent it as request header with every browser request. Request Header -- X-Window-Id: 279078917624897 This allows to identify which windows sent a request and helps to leverage the use of the HTTP session in multi page web application. I will describe this in more detail below. Why is it useful? Imagine you want to use accordion style menus (sample: JQuery UI - http://jqueryui.com/demos/accordion/) or menu groups like the one of JSF Richfaces (http://livedemo.exadel.com/richfaces-demo/richfaces/panelMenu.jsf?c=panelMenutab=usage). If you want to show the same menus or widgets opened after a page reload, then you need to memorize somehow what is opened or closed. We need to keep track of the application's state. Using the REQUEST We could store the information in the request. As a consequence, every form and link of our screen needs to include a list of opened menus/widgets. This could be achieved by manipulating all links and forms using JavaScript. The advantage is that it works with multiple windows and does not require a user session. The disadvantage is that it pollutes the request and enlarges the data sent by every request. In an application with a lot of stateful information it could be impossible to follow this approach. Using the SESSION The other solution is to store the state in the users session. Every time a menu/widget is opened, we send an Ajax request to keep track of opened menus. The downside of session usage is that it is impossible to use multiple windows in the browser because they would overwrite other window's state (opened menus). This is because a user session is normally stored as browser cookie and cookies are merged into a single space for all browser windows (new exception: secure browser windows) Using the Window id Having a window id, we can save the list of opened menus/widgets per window in the user session. We split up the user session in slices. In pseudocode it looks like this: id = request['x-window-id'] context = session[id] menus = context['menus'] It is quite interesting that HTML 5 solves the problem for the client side of JavaScript applications. The sessionStorage allows fine grained controll if data is seen by all windows or just by the current. The problem only persists for client – server applications. Another use case are dialogs or conversations which span multiple pages. We could think of a complex dialog to edit an item or the checkout process of a shop application. With a windows id, we know that the complex dialog was started in a window and that the user is now visiting another area. This allows to clean up the session area for this window. I created a plugin for Firefox which adds the window-id to a request. You can use my ruby based sample application to test the be behaviour. You can find the original article, the plugin etc in my blog. http://www.laliluna.de/blog/categories/ideas/ I am looking forward to your feedback. -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de
Re: [whatwg] Window id - a proposal to leverage session usage in web application
Tim Hutt schrieb:
On 4 February 2010 20:49, Sebastian Hennebrueder use...@laliluna.de wrote:
What is the idea about?
I think Web Storage does what you want and is already implemented
(apparently even in IE). The description from the spec:
This specification introduces two related mechanisms, similar to HTTP
session cookies, for storing structured data on the client side.
The first is designed for scenarios where the user is carrying out a
single transaction, but could be carrying out multiple transactions in
different windows at the same time.
Cookies don't really handle this case well. For example, a user could
be buying plane tickets in two different windows, using the same site.
If the site used cookies to keep track of which ticket the user was
buying, then as the user clicked from page to page in both windows,
the ticket currently being purchased would leak from one window to
the other, potentially causing the user to buy two tickets for the
same flight without really noticing.
To address this, this specification introduces the sessionStorage IDL
attribute. Sites can add data to the session storage, and it will be
accessible to any page from the same site opened in that window.
For example, a page could have a checkbox that the user ticks to
indicate that he wants insurance:
label
input type=checkbox onchange=sessionStorage.insurance = checked
I want insurance on this trip.
/label
A later page could then check, from script, whether the user had
checked the checkbox or not:
if (sessionStorage.insurance) { ... }
If the user had multiple windows opened on the site, each one would
have its own individual copy of the session storage object.
Hi Tim,
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.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
