Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problem using Browser Back or Refresh

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
starigopula@yahoo.com
 
Sander Fieten
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
atif wasi
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
my opinion about ur question is, i think u should us javascript and this script u should open new window without toolbar of back and refresh button, and in this new window u should take inputs as u want.
atif
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Cynthia Yao
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, did you read this security article: http://dailynews.yahoo.com/h/zd/20010305/tc/tag_-_you_re_hit_1.html
 
Geoff Tate
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
Anil Vupputuri
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
U cann't depend merely on java script as it may change browser to browser.So u handle it in application using process flow control i.e., write a class with a method setPageNo(), which is supposed to be called by every Jsp and Servlet, sets page no's to all the Jsp's and servlets and pass that object through out ur application using session object and write methods like getPreviouspage() which gives previous page no, which we set already using setPageNo() and compare page no's and act appropriately. If request comes from the page which it shouldnt then throw it to error page with message.
Or u can totally block ur browser back button using following javascript stmt.
<SCRIPT Language="JavaScript">
window.history.forward();
</SCRIPT>
Anil
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic