How to force new session when opening new browser window?

[Ronald Heukers]

Hi all,

I have looked in the javaranch forums for the underlying problem, but did not find a satifying answer. Who can tell us what to do?

In our servlet/JSP application the users can of course open a new window within their browser.

The problem is that both windows are now using the same session because the other session has not yet been invalidated and that gives problems in the use of session variables etc.. How can I force that the the new window is using a new session? Or otherwise at least deal elegantly with this problem. It must be a well known problem I think.

Regards,

Ronald

[Ronald Heukers]

By the way, with session I mean of course here: HTTP session

[Ben Souther]

You can't.

Browsers behave differently depending on the make and how they're opened.
For example: MSIE will open a completely separate instance with it's own session cookie space if you start it from the Start button on the desktop.
If, however, you open a new instance by typing CTL+N or from the browser's File->New.. menu, both the new and old instance will share the same session cookie space.

Mozilla/Firefox has profiles and tabs. The behaviour in this respect will also vary according to how new instances are opened.

[Pradeep bhatt]

What problems will occur if a new window is opened?

[Ronald Heukers]

The problem is: depending on where in the flow you are, some session variables will have different values. You do not want that in one window the user is going on and then in the other window goes on doing something while the session variable has now a wrong value.

regards,

Ronald

[vidhyasagar reddy]

<script>
function op()
{
<% invalidate session here %>
window.open("new.html");
}
</script>
<a href onklick="op()">click</a>

[Pradeep bhatt]

Originally posted by vidhyasagar reddy:
<script>
function op()
{
<% invalidate session here %>
window.open("new.html");
}
</script>
<a href onklick="op()">click</a>

How will this help.

[Ronald Heukers]

I also do not see how this solves the problem because you can still open a new window from the existing application without using the javascript hyperlink.

But there must be solutions for this. Many developers must encounter this problem. Session variables can change over time, this is normal behaviour.
How to protect a proper working of your application in this context?

[Ben Souther]

Originally posted by vidhyasagar reddy:
<script>
function op()
{
<% invalidate session here %>
window.open("new.html");
}
</script>
<a href onklick="op()">click</a>

That code will do nothing more than invalidate the session before sending the output to the browser.
You can not call methods on the server from Javascript functions on the client.

[Gareth Faulkner]

This is a common problem with client server developments.

A common solution is to continue the session on the new window and invalidate the session on the old window if any action is taken on that window.

The way to implement this solution will depend on how your screens interact with each other.

One way is to hold a session variable of the current screen function or current timestamp, and write that out to the JSP, these two variables can then be compared when the next call to the server is made and if they do not match then the session can be invalidated.

Gareth

[Ronald Heukers]

Ben,

Two questions:

1. do you know a way to deal elegantly with the problem of session variable confusion. I know you are very experienced.

2. regarding the serverside calls starting from a javascript client: can the new emerging technonolgy AJAX (Asynchronous JavaScript and XML) play a role in this?

regards,

Ronald

[Pradeep bhatt]

I dont think that AJAX does not solve the problem. Ben's solution is a good one.

[Ronald Heukers]

??? But what is the solution then?

[Ronald Heukers]

Sorry, I had not yet received Gareth's answer yet, that seesm like a reasonable solution.

Thanks,

regards,

Ronald

[Ben Souther]

Originally posted by Ronald Heukers:

do you know a way to deal elegantly with the problem of session variable

What problem, exactly are you having?
I don't have a simple, blanket solution for all cases.

[Ronald Heukers]

Our application is a standard MVC application with some JSP's with HTML forms for data-entry, and a controlling mechanism for the navigation through the JSP's.

Some status information about what the client has been doing we store in session attributes. When he is navigating through the JSP's the value of some session variables change.

Suppose on the first JSP he has been opening a new browser-window with CTRL-N. And he decides to navigate to a next JSP in browser-window 1, which makes that a servlet attribute changes.

Then he goes to browser-window 2 which is still focused on the first JSP and he starts doing there things, but having there another session attribute value than he expects on that place. There things go wrong.

Most of all I would like that I could forbid him to open a new window or invalidate the old browser window when he opens a new one.

I hope this explains it a bit. Or is there a better place to store our status information and can our application get a better design. But where to store the status information then?

Thanks in advance,

regards,

Ronald

[Ronald Heukers]

Sorry, I meant session attribute where I said servlet attribute, in the middle of the alinea

[Gareth Faulkner]

So long as every page in your application calls a Servlet and not another HTML or JSP page directly, you can use the method I mentioned above by having a hidden input field holding the timestamp that page was called. That timestamp is also stored in the session so you can compare the two each time.

Gareth

[Ronald Heukers]

Maybe I lost you now Gareth,

You mean, make a timestamp put it in your session, write it as a hidden HTML-forms input field in your jsp and ask it up again the next time? But if he does CTRL-N in the browser, the same timestamp gets copied to the new browser window does it not? Or do you mean something else?

regards,

Ronald

[Ben Souther]

Originally posted by Ronald Heukers:

Most of all I would like that I could forbid him to open a new window or invalidate the old browser window when he opens a new one.

If I remember correctly, using CTL+N does not even make a call to the server to populate the page (although it would probably have to if the page wasn't cached).
This will make it almost impossible to distinguish beteen the original browser and the new one.

One pattern you may want to read up on is the "Synchronizer Token" pattern.
In it, a unique hidden variable is sent with each HTML form and compared with one in session when the form is submitted. Struts uses this technique.
The book I have "Core J2EE Patterns" actually shows the Struts code as an example of this.
This technique may be helpful to you in solving some of these concurrency issue but, as I said before, there is no one magic bullet that will solve the problem in all cases.

[David O'Meara]

Just to jump in at this late stage:

I had a similar app a long time ago. A work-in-progress was storred in the session and the only real requirement was to make sure the user didn't open a second window, select a new record, then update the first thereby writing some of object 1's data over the top of object 2. We just passed an object ID around and used it as a sanity check before allowing any operation to touch the object in memory.

A slight modification to Gareth's suggestion, but rather than using the current time you only need a counter. On each request, write the value to the session and send it as a hidden field to the client. When they respond with a token, check it is the same as in the session, increment both by one (check thread safety ) and send it back.

I haven't done as much Struts as I should have, but does it have this built in somewhere to prevent forms being resubmitted?

[Ben Souther]

My previous post repeats some of what Gareth and Ron mentioned.
I should have refreshed the thread before typing my comment.

[David O'Meara]

Heh, the synchronizer token was what I was referring to as well.

I have a curve ball though: assuming you could detect that a new window was open (maybe using the token) and assuming you were maintaining the session using URL rewriting and not a cookie AND assuming you could somehow find a new session ID from the server, you could change the session in the second window to the new session and it would carry on happily. Don't try this at home though, you'll put your eye out.

[Ronald Heukers]

)))

Good work, David!

[Gareth Faulkner]

Ronald,

Are you happy with this now?

The point is that once something has been done on the new window, the old window will be left with the old timestamp (or counter) therefore the server will know its an old window.

Its not a great solution, as mentioned above, there is no perfect solution for this one....

Gareth

[Ronald Heukers]

Yes Gareth, I understand your solution and I am going to propose it to our development team and discuss it with them. Thanks a lot for the help I'll also do some reading on the "Synchronizer Token" pattern. (Thanks Ben)

It seems true what Gareth and Ben say there is no perfect solution or magic bullet for this one.

It surprises me though because the developer community for this kind of applications is quite big and pretty mature and I thought there would be a waterproof design pattern for it, which always gives the perfect solution.

But we'll have to live with it.

Regards and thanks for all the contributors to this discussion.

Ronald

[vinod bonde]

One simpler solution i would like to suggest here that whenever u have change in the session variable value in either of the window u can refresh/reload the other window so that both the windows are having sessions in sync
what do u say ?

[Ronald Heukers]

How Vinod?

regards Ronald

[Ronald Heukers]

I assumed a little we had closed this discussion but one extra thing kept coming to my mind. I believe that in some situations the use of AJAX
()see here for AJAX can be of extra help. I talked with some SUN architects about it and they were really enthousiastic about it.

I have to say that my knowledge about it is only theoretical. Anyway the XMLHttpRequest of AJAX is supported by all modern browsers. You can use it in a javascript routine. You do not need a forms submit anymore or something like that to make a request to the server. Now, from a self written javascript routine which is called by the onload event of the HTML body for example, you can make a call to a self written servlet that checks
with Gareth's technique with timestamps if you are working on the right version of the generated HTML (with the hidden input field). If not you can invalidate the session or something like that. Now also when you open a new browser window with CTRL-N (even if it comes from the browser-cache) it has to execute the javascript as far as I can see, execute in this way the XMLHttpRequest, and it does its work. For our application I find it too much work and Gareths technique is sufficient, but I think it has possiblities.

I would like some reflection on this from others.

Regards,

Ronald

[vinod bonde]

Originally posted by Ronald Heukers:
How Vinod?

regards Ronald

U can throw some javascript code (That reloads the other window either opener or the child window ) along with the response. u need to do it when there is any change in session variable value

[Ronald Heukers]

Hi Vinod,

Thanks for your answer, I understand it. It still requires administration in the javascript routines to keep track of all the open windows, a complication that I would rather not have. And a more important complication: what do you do if he sends a request from browser window 1 to the server which changes a session variable, which makes that he actually would have to refresh both windows, but that he has changed already browser window 2 and clicked submit before the server is back with its response on browser-window 1. Can things not go wrong here?

regards,

Ronald

[Avraham Hamu]

Hi
I had a similar problem, when I open two differents windows of Firefox I get twice the same session ID with 'HttpSession session = request.getSession(true);'.
The problem occurs only with Firefox, using IE 7 everything works well.
I use struts 1.3.9 and JSP so this is what I do to solve the problem.

When the user log in I create a new sessionID:
HttpSession session = request.getSession(true);

After that I read the timestamp and save it into the SID.

Date now = new Date(System.currentTimeMillis());
session.setAttribute(now.toString(), MyObject);

and I forward this SID to the others JSP pages:

ActionForward actionForward = mapping.findForward("success");
ActionForward newActionForward = new ActionForward(actionForward);
newActionForward.setPath(actionForward.getPath() + "?id=" + now.toString());
return newActionForward;

If I can�t transmit the SID through struts I send it with a hidden field in my html form.

If the SID is transmitted through the form I retrieve its value with
sessionID= request.getParameter("id");

and if its sent with struts I retrieve its value with request.getQueryString(); and parse the return value.
Once I have the SID value on the other page I can retrieve My session object with

session.getAttribute(sessionID);

By this way I use the same HttpSession object for many instance of firefox opened without perturbation between them.
With IE its saves in a different cookie each HttpSession created, even from the same IP