Assume the following background - Cookies are disabled; client state is sent using the URL (URL encoding is used); the user is able to cut and paste the generated URL from one browser instance to another. Desired goal is the following:
- Posted by: Suresh Murthy
- Posted on: March 06 2001 21:40 EST
The generated encoded URL for each HTTP request should be unique. Two instances of the browser on the same machine should be prevented from being shared across the two instances.
Any ideas and thoughts will be well appreciated
- Issue with the URL rewriting technique by Nathan Bronson on March 07 2001 03:42 EST
- Issue with the URL rewriting technique by Gordon Reynolds on March 07 2001 13:32 EST
It is not possible to tell requests from different browser windows apart. There are a couple of possible workarounds:
- You could embed a one-pixel applet in the page. The applet would open a connection to the servlet in the start() function and shut it down in the stop() function, allowing the servlet to determine if the page was visible in a browser anywhere. This could potentially take A LOT of resources on your server, and this won't work if users don't allow applets to run. A malicious user could capture the HTML, edit it to remove the applet, and display it in multiple windows, or a non-malicious user might have browser problems and end up with hung applets that prevent them from using your service.
- You could make the entire display of your application run within the applet via a single continuous connection to your server. Very difficult to circumvent, but has all of the disadvantages of the previous solution + the disadvantage that you are no longer writing an HTML application.
(I am only suggesting solutions 2 and 3 from a theoretical perspective.)
Just a guess, but maybe what you need is the Long-Lived Optimistic PseudoTransactions (Version Numbering) pattern.
Gokul, I've seen a scheme presented in a book I own that places a String token (setAttribute) in each request that is copied to a hidden field in the page. A copy of the token is kept in the Session as well. When the user submits the current page, the token is picked up from the hidden field and compared with the token from the Session. If the compare works, a new token is generated for the next page; otherwise an error is generated. It's a thought ...
Could you post the name of the book you make a reference to in your reply...?
The book is:
Web Development with Java Server Pages
by Fields and Kolb
published by Manning
See page 229 (introductory) and page 269-271 (more depth).