Hi All,
An other approach is to use a Flow Controller (a state machine) and a
Session Manager in your project. This is a pure server side solution (with
minimum javascript). The reason we have to go for this solution is because
our project is run on any device...so javascript is out of the question for
WAP enabled browsers in cell phones or PDA's. The 'Session Manager' manages
the user's session(s) (if he /she logs in multiple times) based on the user
id. If the user opens a new window say from FILE -- > new window, he/she
might be able to get past the first flow. When the user tries to navigate
from the old window, the Flow Controller will catch the user and determines
that the user is in an invalid flow. Therefore the user is send a kill page
for the old window( in webbrowsers it is window.close). The user is
therefore forced to close the old window. In case of wap browsers, a flag is
set in the 'Session Manager' for that session. So whenever a user makes a
request from that session id, the session will be invalidated.
When the user opens a new separate browser window and logs in, the Session
Manager detects that the user has logged in more than once. It then sends a
page to the user informing him/her that the user was already logged in and
presents the user with options ....
. Close this window and continue working in the old session.
. Log out of the other window. ( If user selects this option next time
whenever a request is made from the old window, a kill page is send thus
destroying the web browser ).
. A security breach has occured, therefore lock your account and call
customer service.
Hope this helps for somebody interested in a pure server-side solution.
NOTE : In struts 1.1 there is talk of a Flow Controller ( a state machine)
which manages states, so in the long run using this kind of approach would
be befitting, cause all you have to do is write a Session Manager.
Any comments / suggestions welcome.
cheers,
Amar..
-----Original Message-----
From: Peter Alfors [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 11, 2001 10:15 AM
To: [EMAIL PROTECTED]
Subject: Re: The Joy of File : New Window
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
