Re^3: (CGI) Prevent a reload from resubmitting a form

Your token tracking does not really prevent a user from 'RELOAD' either. I can just randomly make up a token value and resubmit the same data again and again because you are only validating whether that token has already been submitted.

You will always to validate your data on the back-end regardless because someone can ALWAYS submit data against your script with random inputs.

Your original question was how do I prevent a user from pressing the button quickly and getting an accidental reload, well JavaScript can allow you to do this, as well as a Modal (look up jquery SimpleModal).

Comment on Re^3: (CGI) Prevent a reload from resubmitting a form

Replies are listed 'Best First'.
Re^4: (CGI) Prevent a reload from resubmitting a form by mzedeler (Pilgrim) on Jun 27, 2009 at 19:13 UTC
You're right that the user may resubmit a lot of values, but if the id has to be generated by the server in order to be valid, you can effectively enforce that the user is only allowed to insert data once, even when using low-tech user agents such as Lynx or WWW::Mechanize. Using JavaScript to disable a button will only work on well-behaved JavaScript-enabled browsers, and thus looks like a nice solution to the wrong problem.	[reply]
Re^4: (CGI) Prevent a reload from resubmitting a form by fmk (Acolyte) on Jun 27, 2009 at 19:32 UTC
I know that i have to validate the data never the less. My original Question was why this "accidental reloads" happen at all. There should be no need to hide the button if the script would work correctly. Im trying to catch the "real" reloads because i dont want my users to accidently change configuration options for example, and not because they are only allowed to submit somthing to db for just one time in a session. This works well, i just have to fix the "accidental reloads". regards.	[reply]
Re^5: (CGI) Prevent a reload from resubmitting a form by mzedeler (Pilgrim) on Jun 27, 2009 at 20:06 UTC
The reload-detection mechanism is probably triggered because one of the requests sent by the browser succeeds in updating the session, and the final request compares the session and the submitted value to find that they are identical. You can't expect that nothing has changed, just because a request is cancelled when the user clicks the submit-button again. The server may be done with the first request by the time it receives the second. I wouldn't rely on any mechanism to distinguish between the rapid re-submitting of a request and submitting once followed by a reload a while later.	[reply]