Topic: Time limit between posts/entries into db

[Canuck]

I am working on a site where users fill in a form, and when submitted, a table is updated.

If you continue to refresh the page where an entry is submitted it continues to add the entry to the database. What is the best way to prevent this?

Thanks!

[Steve]

i had that problem with a html submission form i did not that long ago. the helpful links i came across were these two

http://www.web-source.net/web_development/form_submission.htm
http://www.elated.com/articles/preventing-multiple-form-submits/

[Mike]

I am working on a site where users fill in a form, and when submitted, a table is updated.

If you continue to refresh the page where an entry is submitted it continues to add the entry to the database. What is the best way to prevent this?

Thanks!

Don't let them sit on the page that does the actual submission.  Do the work and then send them away.  You can also setup an ID (unique for every page load) for the submission and then keep track of ones that went into the database.

[Perspective]

I am working on a site where users fill in a form, and when submitted, a table is updated.

If you continue to refresh the page where an entry is submitted it continues to add the entry to the database. What is the best way to prevent this?

Thanks!

Don't let them sit on the page that does the actual submission.  Do the work and then send them away.  You can also setup an ID (unique for every page load) for the submission and then keep track of ones that went into the database.

Or just make the key the primary key of the table so subsequent inserts fail silently.

[ober]

I normally go with Mike's idea.  Have a page that does the dirty work and then forwards them to the final destination when complete.

[Steve]

Like a processing page? Not a bad idea

[charlie]

What if they use "back" to go back to that processing page, will it re-add the stuff to the database?

[micah]

here's what i do to solve that problem (on a page the processes credit cards)

PAGE A: on the page where the user enters their card information; on load, make sure they can use sessions.  set something like $_SESSION['ok_to_process'] = true;

then on the page that actually processes the card info have
PAGE B:

Code: [Select]

<?php

if($_SESSION['ok_to_process'] && !isset($_SESSION['already_processed'])){

//... process their card

 $_SESSION['already_processed'] = true; // or this could be their confirmation number or some other value

//then forward them to the confirmation page.
header("Location: PAGE_C.html");
}
?>
now, if they go back to the processing page it wont process their card again because the only way the script will work is if they came to the page from PAGE A  and they haven't already had their card processed.

[Mike]

What if they use "back" to go back to that processing page, will it re-add the stuff to the database?

If you are smart about the redirection then it will go back to the form page and not the work page.

Or just make the key the primary key of the table so subsequent inserts fail silently.

IMO the primary key should be related to the data and not for use with form processing.  Plus doing that leaves you wide open for a nice little DOS attack to the DB server.

[Canuck]

Thanks for the suggestions, Ill look into it this weekend and ask if I have any more issues.

Thanks!