[apologies I accidentally sent the previous reponse prematurely - please
reference this one]
> You sir are correct!
>
> However, what we do is we have user sessions that hang off the browser
> session. We can detect if a user is sending us a virgin request (i.e. one
> we haven't stamped with an ID yet), and create a new user session, that we
> store with the browser session, and then we send back the user id stamp
> with the page that is served up so that subsequent requests from that user
> session can be identified from others.
>
> In general, all of the apps we do this for require a login, which acts as
> a formal front door for this to happen, but as long as you have the code
> in place to check identity you can do this from any page, it just is a
> little extra work.
>
> Here is a little write up I did a while back explaining what we do. We
> actually have another layer between the user session and the browser
> session that I cann the web application object. The attached diagram trys
> to show the setup.
>
HTH,
Dan
> --
> Daniel Kirkdorffer
> NACN IS: 425-580-6225
> Sr. Consultant, Syllogistics LLC
> Email: [EMAIL PROTECTED]
> Web: http://www.syllogistics.com/
>
>
<<sessions.gif>>
Managing Distinct Application Instances
A given browser can be identified by its session using the HttpSession
object. Therefore the same user, using different browsers (perhaps Netscape
and MS IE), can access the same web application, but data stored with the
session objects will not conflict, as each would be working with a different
session object.
If, however, a person wished to create multiple instances of the same
browser (i.e. by opening multiple browser windows of that browser), and
access the same web application through each of these, we would have a
problem because they would all be sharing the same session object.
In order to enable multiple disctinct instances of a web application,
accessed through the same browser, we need to ensure each application has
its own application space. To do this, we simply need to do two things:
* Create an application object that will be used for storage instead,
and store this object with the browser's session object, and,
* Ensure each application object is uniquely named.
The diagram above illustrates this architecture. Within a given browser
session we will maintain application specific objects, that in turn contain
application instance objects (correspoding to a user login perhaps) within
which we store that application instance's (user's) data, database
connections, etc... The manner in which these are implemented will be
specific to the application, but the following guidelines apply to every
application:
* The first servlet call (often the login servlet call) is responsible
for creating the application object (if one doesn't yet exist) and unique
application object instance. An acceptable convention to follow would be to
append a timestamp to the end of an application specific object name. An
application timestamp string could be used to uniquely identify the
application object. If the application object would normally be
"XYZAppSession", the unique application object could look something like
"XYZAppSession19990504104835729".
* Each subsequent servlet call will need to correctly reference the
unique application object, by either providing the unique application object
name, or at the very least, the unique identifier/timestamp. In order to do
this the client web page will have to have access to this info. Therefore
at least one page displayed (this could be one frame in a frameset), must
have a "hidden" INPUT value containing the information, perhaps like so:
<input type=hidden name=appTimestamp value="<%= appTimestamp %>">
* In the above example the appTimestamp is being set through a JSP
Bean of type String. This will require the page in question is a JSP page
so that it can receive the variable. Whenever a call to a servlet or JSP is
made this value needs to be a part of it. Other Web FORMs, possibly in
other frames will need to grab the value and fill their own hidden
"appTimestamp" field prior to a submit (this can be done though normal
cross-frame referencing). "Get" method calls will need to append the
appropriate parameter info to the end of the URL. The point of only
populating one of many frames is to eliminate the need to explicitly set
value references in each page, which could entail more work. One should
look for a frame that doesn't change very often, if at all, as the primary
holder of the identifying information. Only populating one of the frames
with the unique identifier, however, could yield code that is more difficult
to maintain, as too many cross references could create confusion. The web
developer should try to apply the appropriate approach that will both be
easiest to implement and easiest to maintain.
* Each reference to the application object will use the information
passed in each request to access the unique application object correctly.
For example:
AppSession jspexampleSession =
(NACNAppSession)browserSession.getValue("XYZAppSession");
AppSession userSession =
(NACNUserAppSession)jspexampleSession.getValue("XYZAppSession" +
req.getParameter("appTimestamp"));
The above code uses the timestamp to uniquely identify the appropriate
application object instance within the application session space (which in
turn is stored within the browser session space).
> ----------
> From: Joel Reymont[SMTP:[EMAIL PROTECTED]]
> Reply To: Joel Reymont
> Sent: Tuesday, November 16, 1999 5:17 PM
> To: [EMAIL PROTECTED]
> Subject: Tracking sessions in browser windows
>
> How do you do this? I was under the impression
> that the cookie is set per browser app (IE, NN)
> and not per browser window. Am I mistaken?
>
> Thanks, Joel
>
> > -----Original Message-----
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Kirkdorffer, Daniel
> > Sent: Tuesday, November 16, 1999 12:59 PM
> >
> > Well, my application distinguishes user sessions so that a user can
> login
> > multiple times in separate browser windows.
>
> ==========================================================================
> =
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>
sessions.gif
sessions.gif