How can I control the effect of browser back button?
 

I have an HTML page containing a number of form fields but containing absolutely no user identification as the submission of the form must be anonymous.
When submitted, it calls a CGI script that creates and returns another HTML page with one more unique value (a random passphrase) besides summarizing the entries made in the first form for confirmation.
Clicking the browser back button from this second page returns the visitor to the reset first page allowing to reenter values, generating another "one more unique value" and the cycle can be repeated indefinitely.
However, because files have already been created on server according to it, I need that "one more unique value" to remain unchanged which necessitates skipping part of the code in CGI script when the value exists on subsequent visits.
I can only rely on that "one more unique value" to prevent duplication/multiplication of submitted forms.

Although no expert at it, I am aware of Javascript localStorage which could help.
Another solution would be an added hidden input field but this needs a recorded unique value in the first HTML page before being "downloaded" by the browser but I can not figure what the easiest solution to this problem could be.
I thought I should find it solved on Google but there is absolutely nothing similar or I am not Googling the right keywords.

Can anyone make a suggestion?

Thank you for your help.

One suggestion would be to use a session variable. Each page needs to start the session and the first would check to see if it exists and maybe pass a hidden field.

You don't.


You cannot entirely prevent duplicate submissions of truly anonymous data - if you don't know who someone is, you don't know whether they've made a submission already.

What you can do is generate your unique identifier on page 0, and traverse pages using POST form submissions only, requiring a valid unused unique identifier for both page 1 (where the data is filled in) and page 2 (where the data is saved).

If you receive a GET request for page 1/2, either display an error or goto the start of the process with a suitable message.
If you receive a POST request with an already used identifier, you either show an error or allow users to revise their submission.

Obviously don't store your unique identifiers in relation to other information (including via any logging or error tracking) - simply store the fact that they were generated, plus a reduced-resolution expiry time (e.g. always round up to the next hour), and clear them after a suitable period (maybe a couple of hours after generation, or whatever is appropriate).

This doesn't prevent deliberate attempts to submit twice - again, you can't do that with anonymous submissions - but it will help with accidental duplications.

None of this relies on LocalStorage/JavaScript/cookies/etc - it's all basic HTML and HTTP.

Thank you for the answers.
The intention is to prevent visitors who discover that pressing the back button gives them an opportunity to find another passphrase that they hope could be more easily memorised and, in the process, create hundreds of empty files on the server and hundreds of fictitious entries in a database (not to mention the security risk). Unless the confirmation of the passphrase is received, submissions go to device null, so duplicated submissions are not really the problem.
I stumble on this, I have no idea how to do it. The identifier would have to be generated at the client and returned in the post so the page is identifiable from the same page visited by other clients.
AFAIK, identifiers apply only on elements, what I could not find was how to (easily) apply a unique identifier to a page, perhaps you can suggest how to Google this so I can learn what I don't know.
Providing the passphrase on page 0 reduces the problem mentioned above but does not eliminate it.

If I'm understanding what you're saying correctly, you have designed a system where "eliminating" this problem is not going to be possible.

That said:

Consider, if you haven't already, that the CGI script has access to headers.

Here's a key technical point that I'm not clear on.

If two people enter the exact same text into the form, do they get the same password, or do they get different passwords?