We have a JSP page that contains order information of a user. By cliking the submit button on the page, we create appropriate records in the database and forward the user to a another page. The problem I have is after forwarding the user to another page, he can use the browser BACK to get back to order page and submit the page again. This is causing duplicate orders to be created. Is there good way to prevent the browser BACK or REFRESH from reposting the same data again. Another situation could be a page that processed a credit card transaction. If the user keeps using the REFRESH or BACK, how can we prevent the transaction to be submitted several times. Any help would be appreciated. Thanks in advance. email@example.com
I would suggest that you maintain the state in which the user transaction is as Session information. Then you can check if the action is allowed to occur in the current State of the users transaction. greetings Sander
I'm a strong believer in building these fundamental constraints as deep into the model as you can. Not just setting a flag or two, but making it part and parcel of the way your software operates. In fact this often happens almost automatically if your design is solid. To prepare an order, I guess there is something like a shopping cart, probably maintained as session state. This cart object should be removed from the session as soon as the order is committed. If you do this, there is no way a duplicate order can ever be generated no matter what happens. Should you be persisting your cart in a database (for example to facilitate fail-over), you can impose a database-level constraint so that no more than a single order can be generated for a given cart ID. For example, include the cart ID in the order table and impose a uniqueness constraint on it. - Peter
[This message has been edited by Peter den Haan (edited March 08, 2001).]
Trying to protect your application bylimiting the visbility of buttons is virtually pointless. It's so easy for any user to get around: You still get a menu of operations (on a right-click, for example), even with no buttons, so you can save the page, bookmark it, and probably go back and refresh the page from this menu too. There is also no guarantee that any particular browser will actually honour your request to remove facilities from the user in this way. Take Peter's advice (it's always worth listening to) and build an understanding of the order process into your model. Then you can use any client, and allow the user to do anything they want with no nasty side effects.
Take a look at these - I don't know how browser-compatable they are though do seem to work in IE. response.setHeader("Pragma","No-cache"); response.setHeader("Cache-Control", "no-cache"); <head> <meta http-equiv="pragma" content="no-cache"> <meta http-equiv="expires" content="0"> Of course theres no substitute for putting it in your application logic where it belongs. Remember that someone can always hack your app with a script or program so a browser should only be used for presentation. Validation logic should not be in a browser or at least NOT be the only form of validation. And a browser should not be relied upon as "piece of logic" for the app. It maybe OK for an internal intranet app to do use the browser for validation, but not when exposed to the outside world. Cynthia - the fact that the shopping cart reads from the HTML parms to get its price is pretty scary.
[This message has been edited by Geoff Tate (edited March 08, 2001).]
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR> fantastic, a towel? <HR></BLOCKQUOTE>