Like others have pointed out, there is no fool proof solution as long as the
user is able to break out of your box and do their own thing. URL encoding
solutions mean that the URL can be copied and pasted into another window and
your system will not know the difference. But how likely is this, and
should you really be responsible for ensure it works if they do? I'd say
don't worry about it. This isn't much different than the problem of Frame
context should a frame be accessed without the parent Frameset. Name
references and JavaScript references can be broken if that is done. The
user learns that that's not the best way to access the page. This may not
be a perfect answer, but with the Web there are always imperfect solutions
that we put up with because of all the other benefits we wish to enjoy, and
because companies can't agree on standards.
So I say, write a solution that identifies the user with each server call,
via hidden POST data or additional parameters in your URL, and move on.
Dealing with this issue beyond that is not worth it given the few people who
would ever have this problem, and who couldn't avoid it by simply being
better informed.
Dan
> ----------
> From: David Wall[SMTP:[EMAIL PROTECTED]]
> Reply To: David Wall
> Sent: Monday, July 26, 1999 5:13 PM
> To: Kirkdorffer, Daniel; [EMAIL PROTECTED]
> Subject: Re: Sessions and multiple browser windows
>
> I do have a user object connected to a session, but if that user then
> opens
> multiple browsers, such as by shift-clicking on a link in Explorer, that
> additional window will just appear like more requests coming from the same
> user on the same session.
>
> So, if I keep something simple like the "last pages viewed" for a recently
> visited navigation bar, it will get confused because it will interleave
> the
> pages visited by those two browser windows. Or, if I try to keep anything
> in the session object, like the "current object being worked on," it can
> be
> overwritten if that additional browser window switches that so-called
> "current object." The first window will basically lose track of its
> "current object" on its next invocation.
>
> For the most part, I am able to keep pages context free, but this can be
> tedious when it comes to a complex object retrieved from the database
> based
> on a somewhat complex query, and that object needs to be passed from pages
> via links, and from pages via FORM POSTs. If I just pass the object ID, I
> will have to retrieve it over an over again, but if I store it in a
> session-oriented bean, it can be trashed by multiple windows.
>
> It must be a very common problem, and I was querying to see how such
> issues
> are being handled out there.
>
> David
>
>
> ----- Original Message -----
> From: Kirkdorffer, Daniel <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; 'David Wall' <[EMAIL PROTECTED]>
> Sent: Monday, July 26, 1999 9:21 AM
> Subject: RE: Sessions and multiple browser windows
>
>
> > David,
> >
> > We've had to create "user" objects we hang off the session object, and
> pass
> > identifiers around to identify who is who. It is an important
> > consideration.
> >
> > Dan
> > --
> > Daniel Kirkdorffer
> > NACN IS: 425-580-6225
> > Sr. Consultant, Syllogistics LLC
> > Email: [EMAIL PROTECTED]
> > Web: http://www.syllogistics.com/
> >
> >
> > > ----------
> > > From: David Wall[SMTP:[EMAIL PROTECTED]]
> > > Reply To: David Wall
> > > Sent: Saturday, July 24, 1999 12:23 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Sessions and multiple browser windows
> > >
> > > I know this has been talked about before, but what are people doing
> with
> > > objects that are at session scope when users have multiple browser
> windows
> > > open at the same time? It seems that very little may really be kept
> at
> > > the session level to avoid conflicts among many windows, since I can
> find
> > > a way to identify a request coming from a different window.
> > >
> > > David
> > >
> > >
> >
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
