Stopping users from backing up in a servlet

[DC Dalton]

I know this has been covered once or twice here but I don't think we have ever found a definitave answer. Ive got a form submitting and a TON of moronic users who dont read the big bold letters that say "DO NOT BACK UP & RESUBMIT THE FORM" needless to say I have sql errors all over the place from duplicate keys attmpting to be inserted. Has anyone ever been able to stop users from backing up....tha javascript stuff for this is WAY to browser dependant....how do you combat these idiots that CANT FOLLOW SIMPLE INSTRUCTIONS......thanks for any help in advance

[Ken Pullin]

DC
I don't think these people are idiots, you just have to count on a certain percentage of people not following directions. The first time they post into your servlet, you could always put a flag on the user's session and then you could check that flag everytime someone posts to the servlet. Something like this:
// this code is rough, but it illustrates the
// point
if (session.getAttribute("flag")) != null) {
// this means they have already posted
// redirect the user to another page or an
// error page
}
// set the attribute
session.setAttribute("flag", "true");

[Mike Curwen]

DC. I sympathize with you, really!

But it's been my experience that big signs that say "Don't do XXXX" will invariably lead many people to do just that! Have you ever seen Kids in the Hall? (Don't put salt in my eye... don't put salt in my eye... don't put salt in my eye... PUT SALT IN MY EYE!!)

Anyways... I've got a related (and yet completely different) problem, and perhaps a solution?

I was trolling for cool HTML/DHTML on Microsoft's site today (enough said about that).

I saw in one of their javascript files a sweet little trick, which struck like a lightening bolt, and I thought *holy !!!* they've figured out how to end the double-click madness. You know.. the PEBKAC error(problem exists between keyboard and chair, for those who didn't know) where someone submits the same form twice, because they double-click?

It's not right in front of me, but it basically went something like:
the <a href's onclick event (or is that on_click? I'm really NOT a javascript guy) had a function.
this function parsed the anchor's querystring for the presence of a parameter (?clicked=true)
If it wasn't there, it added it, and then called the object's (the link's) 'click' method.
The second click would then be on the modified object (think javascript/DOM manipulation) which *does* have that parameter, and so the method exits without calling the 'click' event.

I was going to cut and paste that small segment out and try it out, but then i realized that I had no real way of testing if it worked or not. :roll:

[Steve Deadsea]

If the actions that a user can perform depend on the state, both you and the user need to keep track of this state and you need to deny any actions that are performed at an incorrect state.
One way to do this is to send the user a ticket (random string) in a hidden form input. If the next request that that user sends has a different ticket than the last one you sent, the user used the back button or something and you can put up an error mesage.

[Mohan Panigrahi]

One suggesting is that in each of your page loads, just empty the browser cache. I don't have the code right now for doing that, may be I would post tomorrow

[Bear Bibeault]

One suggesting is that in each of your page loads, just empty the browser cache.

How friendly. I would also assume that such a mechanism would be highly browser-dependent as well. I think the "token" solution put forth in an earlier post is the best solution I've seen in practice.
hth,
bear