This week's giveaway is in the Java/Jakarta EE forum. We're giving away four copies of Java EE 8 High Performance and have Romain Manni-Bucau on-line! See 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>