Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 20 of 20
  1. #16
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,341
    Thanks
    60
    Thanked 527 Times in 514 Posts
    Blog Entries
    4
    Quote Originally Posted by AndrewGSW View Post
    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

    Quote Originally Posted by AndrewGSW View Post
    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.

    Quote Originally Posted by AndrewGSW View Post
    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

    Quote Originally Posted by Len Whistler View Post
    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.

    Quote Originally Posted by codingrox View Post
    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.

    Quote Originally Posted by codingrox View Post
    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.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  2. #17
    Senior Coder
    Join Date
    Apr 2011
    Location
    London, England
    Posts
    2,120
    Thanks
    15
    Thanked 354 Times in 353 Posts
    @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.
    "I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.
    Validate your HTML and CSS

  3. #18
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,341
    Thanks
    60
    Thanked 527 Times in 514 Posts
    Blog Entries
    4
    @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.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  4. #19
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    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.

  5. #20
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,341
    Thanks
    60
    Thanked 527 Times in 514 Posts
    Blog Entries
    4
    Quote Originally Posted by Fou-Lu View Post
    I'm personally too lazy
    Me too!
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!


 
Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •