No, the problem is that you shouldn't put dynamic state into the
HttpSession. The Http RFC says that POSTs should be idempotent, that is
the POST and associated data should be enough to carryout the request.
You can use the session to identify, track and assist the user, but
the pages you present should be self standing. If you don't then
bookmarks, caching proxies, browser caches etc fail miserably.
I access many web pages via a caching proxy (proxiweb) on
my palmPilot, and many sites are very had to navigate because
they assume that what is on my screen is the last request they
sent, when often it has come out of the cache.
In the scenario below, the request that does the POST of the changed
data
_must_ include a unique identifier of the record to be updated.
Tim.
Albert Wong wrote:
>
> The problem in this scenario is a cookie is being used to identify the
> session to the Servlet. Since the cookie is shared between browser windows,
> all requests from these windows will look like the same session to the
> Servlet.
>
> A possible answer might be to disable cookies on your web server forcing the
> Servlet to utillize URL rewriting for it's session management. Under this
> scenario, if the user opened up a new browser window he would initially have
> the same url (eg. http://myServer/MyServlet?JSESSIONID=1234) but design your
> web application to force him/her to some MainAdministrationScreen.jsp. This
> page could then contact your Servlet requesting a new session.
>
> So both windows would have their own sessionID and still have access to the
> two sessions.
>
> -----Original Message-----
> From: Marc Krisjanous [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 30, 2000 2:28 PM
> To: [EMAIL PROTECTED]
> Subject: protection against multiple child browsers
>
> Hi all,
> I have an interesting question! Based on the scenario below what solutions
> could be provided?
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> The diaster scenario might take the form of an account manager opening up a
> customer's profile, ready to make a slight change in it. The manager
> remembers that another customer has similar values and proceeds to open up
> another, and simultaneous, browser window. This second window inherits the
> firsts cookie and hence client state. As far as the server is concerned,
> the singular browser instance just switched to a new customer profile. The
> manager views the second customer's information and then switches to the
> first browser window, makes some changes, and then submits them to the
> server. If the client state contained the primary key contained the primary
> key to the customer, the server might update the second customers record
> with the first customers data.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Best Regards
>
> Marc
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
