Refresh Resubmits the page

[tangoforce]

Originally Posted by AndrewGSW

if the session value is already 1 then it will prevent the submission of the second set of data.

Thats the whole point of this topic - to prevent the form data being resent again

Originally Posted by AndrewGSW

Also, when they navigate away from the page, the session value would need to be reset to 0.

The session value is changed for each NEW call to the form. You can even have multiple session values in an array. As long as that value hasn't been unset the form is valid. As soon as the form is submitted without errors and you've actioned it, you unset the session variable. If the page is refreshed / resent then it won't be actioned because the appropriate form key (in a hidden form field) has gone from the session.

Originally Posted by AndrewGSW

There's a similar solution discussed here, although I haven't tried it myself yet.

Until you try these things you can't really have a good understanding of them to really comment and advise others. No idea why but I've debugged peoples code for them many times and found all sorts of errors and yet they're putting PHP lessons on their website for others I had one bloke ages ago who was doing this:

PHP Code:

if (!session_start())
{
session_start();
} 


He had tutorials on his website explaing that this was how you checked if the session was already started in any script that used sessions

Originally Posted by Len Whistler

The code below should work.

PHP Code:

if (isset($_POST['submit'])) {

} 


Under certain conditions without the use of IE (which has the majority of the browser market). For that reason, you're best avoiding the isset and submit button. More in my signature.

Originally Posted by codingrox

Lovely... thanks for your response...

If multiple users are on the same web page then wouldn't $_SESSION keep changing and hence it would never match with token stored in hidden variable?

Okay, I have checked this and it does remember the session token stored earlier and it just works fine.

But how does it do it. How does it know which user had which token variable stored in session variable.

A session is unique to each user. You can have 2, 3, 4, thousands of users on your website at the same time but they will all have a completely different session file stored on the servers hard drive. They are identified by a cookie sent to the browser. Whenever the browser makes a request back to your website, it automatically checks for any cookies issued by your site and sends them back. This is where php gets the session id from - the browser sending back the cookie data.

You can watch this in action if you use firefox - download live http headers and watch it all happen. Just be sure to uninstall the yontoo plugin/addon first which makes about a billion http requests that you'll have to trawl through.

Originally Posted by codingrox

What's the point of unsetting token in session variable if we are going to set it anyways to a new value??

You set is so that when the form is created, you put the value into a hidden form element. When the form is submitted, you check for the value in the session. If it is there you process the form and then delete the value in the session. If it isn't there, then the form has already been processed and the value was deleted previously. You therefore issue a "this form has already been processed" message. If your users wants to genuinely submit a new form then they will have to genuinly click onto that forms page again (generating a new session value and new hidden form field value). This doesn't stop the browser refreshing and resending the data (thats how all browsers work) but it does stop your site from accepting the data and storing / emailing it again.

[AndrewGSW]

@tangoforce
My original point remains valid: setting a session variable to 1 or 0 is not a solution to the original question - it needs to be a random number. The link I provided discusses the use of a random number in more detail. The fact that I hadn't worked through the code that the page provides in detail won't prevent me from offering a link to it, if I believe it would be useful to the OP in understanding the problem.

[tangoforce]

@Andrew: I wasn't specifically commenting on the 0 or 1 thing. My point was that you didn't actually seem to understand the principle of using a token / session method to stop a form being resubmitted yet you were commenting on the unworkable side of the idea.

If you don't understand it yourself until someone like Fou explains it to you then how can you be sure you're offering good advice?

As for the 0 / 1 thing, yes it can work easily. You're forgetting that you can either use the token as the session key name OR the value. As long as it exists in one form or another it can be found by the processing script.

Using random numbers isn't really my preferred method as there is always the very remote chance that you may get the same random number. I would personally use a table in the DB with an autoinc value starting at 100000 and just inset a new row and then get that id. When the form is submitted you wipe that row off the table. That way the token is guaranteed never to match and will always be unique.

[Fou-Lu]

Randomness can be completely tossed as well as any hashing if desired. I'm personally too lazy to consume from storage, so if you want to avoid hashing and random, I'd suggest a simple call to microtime(true); would be sufficient (even just time()).
The keys to keep it simple here are:
1. Always generate a token
2. Always abandon or destroy a token when consumed
3. Always generate a token so it has a reasonably low probability of collision

So long as a resend of the post doesn't match a new token (or any token), then you can safely assume that its been consumed already.
I'll double check that this works properly whilst holding down the submit button with enter. I'll have to test that when I get home.

[tangoforce]

Originally Posted by Fou-Lu

I'm personally too lazy

Me too!