The Joy of File : New Window

[Erik Horstkotte <er...@msoft.com>]

I've run into a problem that seems to lie in the borders between Struts
and Tomcat. We're developing a fairly large JSP & EJB - based project
and have just run into the fun fact that when a user (of IE 5.5 or
Communicator 4.61 at least) "splits" the window, the session id cookie
is inherited by the new window, and therefore *both* windows start
sharing the same form beans. This causes havoc. I don't see how our app
can even *detect* the condition, much less *deal* with it.

How are you others out there dealing with this issue?

-- Erik

Re: The Joy of File : New Window

[Peter Alfors <pe...@irista.com>]

I recently asked this question (over and over and over).  I pretty much
beat it to death.  Using some suggestions from this list (check the
archives for 'session'), we came up with a pretty solid approach.  Thank
you to those that helped.  :)  It is ugly, but it solves all situations.

The only way that we have found to determine if the user has opened a new
window (through either a File --> new window or right-click --> open in New
window)
is to check the window.name property.  However, we do not really like this
approach, so if anyone knows a better way, please speak up.  :)
When a new window is created, the window name is empty.
This is a settable property, so after you find a window, set it to
something.
Remember, if you are using frames, set window.top.name

You would think that there would be a window.ID or something that is unique
for every window.  However, according to my javascript books and searching
the web, there doesn't appear to be.  Again, I hope that I am wrong.  :)

So.. Now that you know you have a new window, what now?
Here is one solution:
    You can manage your own session objects.  Yep, I said it was ugly.
Each new window is assigned a unique ID.  Each page must store this ID and
pass it on to the next page.  The action classes use this ID to retrieve
session objects from the common session object that is shared by all
windows.  Your app's session objects are stored in a hashmap (or something)
which is stored in the common session object using the unique ID.
Therefore, each action class has the ability to retrieve the correct object
to work on for its specific window.

What does the javascript check do?
    When the javascript identifies that a new window has been generated, it
can redirect to a new page (or the same one with a querystring flag
signifying that this is a new window and the action class should create a
new ID)

We struggled with this for a couple weeks to work out the bugs.  I believe
that now we have everything worked out so that no matter what the user
does, he/she cannot stumble on another windows object.

HTH,
    Pete

Erik Horstkotte wrote:

> I've run into a problem that seems to lie in the borders between Struts
> and Tomcat. We're developing a fairly large JSP & EJB - based project
> and have just run into the fun fact that when a user (of IE 5.5 or
> Communicator 4.61 at least) "splits" the window, the session id cookie
> is inherited by the new window, and therefore *both* windows start
> sharing the same form beans. This causes havoc. I don't see how our app
> can even *detect* the condition, much less *deal* with it.
>
> How are you others out there dealing with this issue?
>
> -- Erik

Re: The Joy of File : New Window

[David Crooke <da...@convio.com>]

The way we have dealt with this (servlets, not EJB) is to add a path extension
to our URL's, c.f.

http://www.mysite.org/zone/servletname/123456789?foo=bar&bash=wibble

This path extension (the 9 digit pseudo-random number) is picked up by our
common platform code, and maps back to an entry in a hashtable attached to the
HttpSession. We call this an application context. A new one of these is
allocated for each interaction sequence, so the windows which are split in this
way quickly end up with different app contexts (in fact, usually immediately,
since the typical behaviour of a user when opening a second window is to begin a
new interaction by clicking on the navbar).

We use BASE HREF in the served pages to ensure relative URLs behave consistently
whether we are using an app context or not.

There is nothing to stop a perverse user from keeping both windows in the same
application and interaction sequence, so we also do a check on any form
transaction from the browser which updates state on the server side, to make
sure we don't accept the same POSTed update twice in a row (also avoids Back
button and click again problems)

We also use it to support applications "calling" each other and returning while
keeping track of a return stack on the server side.

Check out http://www.austinkids.org/site/Donation (this URL will throw a
redirect to a secure server)

Cheers
Dave

Erik Horstkotte wrote:

> I've run into a problem that seems to lie in the borders between Struts
> and Tomcat. We're developing a fairly large JSP & EJB - based project
> and have just run into the fun fact that when a user (of IE 5.5 or
> Communicator 4.61 at least) "splits" the window, the session id cookie
> is inherited by the new window, and therefore *both* windows start
> sharing the same form beans. This causes havoc. I don't see how our app
> can even *detect* the condition, much less *deal* with it.
>
> How are you others out there dealing with this issue?
>
> -- Erik

Re: The Joy of File : New Window

[Wyn Easton <wy...@yahoo.com>]

Welcome to the world of web programming ;->

I had the same problem a while back.
What we did was create a "key" for each new logon.
By logon I mean that requests always came to one
servlet before going to other servlets or JSPs.
This "main" servlet would generate a unique key and
pass it to other servlets or JSPs in the request
as an attribute. (request.setAttribute("sessionKey",
theKey);) We used the Date() method to get a unique
key. The JSPs would always store this key in a hidden
variable in the form it sends back to the web server.
We stored the bean for this request in the session
using the key (session.setAttribute(key,theBean);
Then when a another request came in we first get the
key from the request (String theKey =
requesst.getParameter("mySessionKey");) then get the
bean for the request (session.getAttribute(theKey);)

For this to work you must not call getSession(true)
except in the "main" servlet. All other servlets
should use getSession(false);  then check for a null
return.
If it is null, send the request to the "main" servlet.




--- Erik Horstkotte <er...@msoft.com> wrote:
> I've run into a problem that seems to lie in the
> borders between Struts
> and Tomcat. We're developing a fairly large JSP &
> EJB - based project
> and have just run into the fun fact that when a user
> (of IE 5.5 or
> Communicator 4.61 at least) "splits" the window, the
> session id cookie
> is inherited by the new window, and therefore *both*
> windows start
> sharing the same form beans. This causes havoc. I
> don't see how our app
> can even *detect* the condition, much less *deal*
> with it.
> 
> How are you others out there dealing with this
> issue?
> 
> -- Erik
> 
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/