I've handled it in this manner and it works fine in my application. Each
HttpRequest must provide a key value for looking up information about a specific
user (i.e. parameter userid) using hidden fields and encoded URLs. This ID is
then used to look up an object reference in the session (i.e. userid + "Root").
Kevin Jones wrote:
> I haven't thought too much about this but it may be possible to solve this
> by using client side script and hidden fields or encoded URLs. So when a
> document is loaded into a browser or a new browser window is opened get (or
> generate) a unique id (using script), and pass this back with every request.
>
> I'm not sure how practical this is or how easy it would be to implement but
> it strikes me as a possible solution,
>
> Kevin
>
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jesper Jorgensen
> Sent: 27 July 1999 08:24
> To: [EMAIL PROTECTED]
> Subject: Re: Sessions and multiple browser windows
>
> I completely agree that it must be a common problem and I have myself
> spent some time considering how to solve this problem.
>
> However, I really don't think that there is any "easy" solution since
> browser-servlet applications are inheritly stateless. We only have the
> cookie for maintaining state and the cookie is only browser specific and
> not window specific. I have never done any GUI programming but I would
> guess that such a problem is solved in GUI programming by using a unique
> window id for each window.
>
> You can divide the problem into two categories:
>
> 1) A users opens a new window because it was part of the application
> (i.e. the link he following used javascript to open a URL in a new
> window.
>
> 2) A users chooses himself to open a URL in a new window or he goes
> directly to the URL by typing it in manually or using bookmarks.
>
> In the first case, one could use a URL rewriting-like technique to
> attach a "window id" to the new window and in that way identify it.
> Generally this case should be easy to work around since the app designer
> is in full control.
>
> In the second case, the app designer have no control on when a URL is
> opened in a new window, so there is really not much to do here. However,
> I have noticed that in this case the browser will not send a "refererer"
> request header so it is actually possible to detect this special case.
>
> To really get something good to work it would be necessary to design a
> good framework for working with these special techniques so that they
> are hidden from the app designer most of the time. Several "hard"
> decisisions would also have to be made along the way. For example, what
> should happen to a user that "walks directly into an application" using
> a direct URL ? Finally it would be necessary to check different browsers
> behavior.
>
> Sincerely,
> Jesper Jorgensen
> http://www.caput.com
>
> ===========================================================================
> 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".
>
> ===========================================================================
> 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".
===========================================================================
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".
