SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 37
  1. #1
    if ($zee == "Guru") { $zee--;}
    Join Date
    Nov 2005
    Location
    Karachi - Pakistan
    Posts
    1,134
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Avoid double submit (Refresh / Back button)

    Hi

    I need a guidance / suggestion about how to prevent the DOUBLE DATA SUBMISSION to database.

    This usually occurs when after the submit, user hit REFRESH button, or hit the Go Back button.

    In short, the DATA INSERTION script is refreshed and submit the data again.

    Here is my idea.
    Have a code may be md5(time()+session_id) in a hidden field of the form. And upon insertion, first do a check if that code is already there in the database, if the answer is NO, INSERT that, else show a message !

    What do you people think, is this idea OK, or there can be some better ways ?

    Thanks
    Z

  2. #2
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  3. #3
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,807
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    The only time a double submit would be a problem is where you have an insert with an autoincrement. Anything else would have no effect since you'd just be replacing data with the same thing, be unable to insert a duplicate, or be unable to delete something already deleted. So in most cases using post-redirect-get is just adding additional processing for no additional benefit - particularly since it doesn't actually prevent the data being submitted again (it just reduces the chance of it happening by accident).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  4. #4
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    The only time a double submit would be a problem is where you have an insert with an autoincrement.
    Which is probably 90% of mysql tables out there :P

  5. #5
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,807
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by hash View Post
    Which is probably 90% of mysql tables out there :P
    You are assuming that most databases are badly designed since that ought to be a very rare occurrence with properly designed databases. You might be right though.

    That of course would then mean that the best fix for the problem in those cases would be to redesign the database properly to get rid of the meaningless autoincrement field and replace it with a more appropriate key.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  6. #6
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    After you coded your first site, you shouldn't even be able to think of a way not to use:
    Quote Originally Posted by AnthonySterling View Post
    (you could, but then you would always end the thought with: "but that's stupid" )

  7. #7
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,807
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Vali View Post
    (you could, but then you would always end the thought with: "but that's stupid" )
    Yes - using post/redirect/get is stupid most of the time. It always adds an overhead to the processing without actually doing much in return. Even with that code in place you would still need additional code to prevent a double submit of the same data in those instances where a double submit would result in a database corruption simply because there is nothing in a post/redirect/get to prevent someone deliberately double posting to corrupt the data.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  8. #8
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    You are assuming that most databases are badly designed since that ought to be a very rare occurrence with properly designed databases. You might be right though.

    That of course would then mean that the best fix for the problem in those cases would be to redesign the database properly to get rid of the meaningless autoincrement field and replace it with a more appropriate key.
    I'm assuming because it's used everywhere. http://codex.wordpress.org/Database_...able:_wp_posts for example.

    Is it really so bad? Is the extra header really so much overhead? I understand normalization and key constraints, but surely convenience is also a factor.

  9. #9
    SitePoint Wizard PHPycho's Avatar
    Join Date
    Dec 2005
    Posts
    1,201
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AnthonySterling View Post
    Thanks for the link.
    Good visual explainations:
    http://en.wikipedia.org/wiki/File:Po...mitProblem.png
    http://en.wikipedia.org/wiki/File:Po...itSolution.png

  10. #10
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,807
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by hash View Post
    Is it really so bad? Is the extra header really so much overhead?
    No it isn't really a huge overhead but it doesn't really achieve what a lot of people claim it does either since it doesn't actually prevent a double submit of the same data. All it really does is to reduce the chance of it happening by accident and get rid of an alert in Internet Exploder when you hit the back button to go back to the page that was submitted. You still need the exact same code to prevent database corruption from a double submit if you do use that processing as you need if you don't use it.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  11. #11
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    felgall, you are right.
    It does not prevent from double posting. From spamming Send button, for example.
    But it is not bad either.
    Also, in this very case OP were asking about REFRESH button, so, his problem solved.

    What database design you are talking about? Little example please. This thread has an autoincrement id = 653767
    What you claim it to be in the perfect world?

  12. #12
    rajug.replace('Raju Gautam'); bronze trophy Raju Gautam's Avatar
    Join Date
    Oct 2006
    Location
    Kathmandu, Nepal
    Posts
    4,013
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If we cannot say that Post/Redirect/Get is much huge overhead then i think this reduces the risk of inserting duplicate data/row in the insertion case and it is better to go for it. I normally do that. If we don't redirect then we have to check to prevent posting same record in the same submit twice or more if the same records whether the same data are already inserted to the db or not even though we don't really want such duplicate validation.
    Mistakes are proof that you are trying.....
    ------------------------------------------------------------------------
    PSD to HTML - SlicingArt.com | Personal Blog | ZCE - PHP 5

  13. #13
    if ($zee == "Guru") { $zee--;}
    Join Date
    Nov 2005
    Location
    Karachi - Pakistan
    Posts
    1,134
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well !

    So it means that Post/Redirect/Get is not ok to use, so what about my solution ?

    "Have a code may be md5(time()+session_id) in a hidden field of the form. And upon insertion, first do a check if that code is already there in the database, if the answer is NO, INSERT that, else show a message !"

  14. #14
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,807
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by rajug View Post
    If we don't redirect then we have to check to prevent posting same record in the same submit twice or more if the same records whether the same data are already inserted to the db or not even though we don't really want such duplicate validation.
    You still have to do that same duplication check because the redirect doesn't prevent someone deliberately inserting a duplicate, it only prevents some situations where people would insert the duplicate by accident. So the validation is still required to protect the integrity of the data from deliberate attack regardless of whether you use the redirect to prevent accidental duplication.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  15. #15
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zeeshanhashmi View Post
    Well !

    So it means that Post/Redirect/Get is not ok to use, so what about my solution ?

    "Have a code may be md5(time()+session_id) in a hidden field of the form. And upon insertion, first do a check if that code is already there in the database, if the answer is NO, INSERT that, else show a message !"
    post redirect get is perfectly fine. The point felgall is trying to make is that it's not enough on it's own. You also need unique keys (eg username) to prevent duplication, and your code should handle errors like duplicate record.

  16. #16
    SitePoint Addict reboltutorial's Avatar
    Join Date
    Jan 2009
    Posts
    309
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    You still have to do that same duplication check because the redirect doesn't prevent someone deliberately inserting a duplicate, it only prevents some situations where people would insert the duplicate by accident. So the validation is still required to protect the integrity of the data from deliberate attack regardless of whether you use the redirect to prevent accidental duplication.
    I think that we are not talking on the same level of patterns:

    the technical level
    the business level

    On the technical level, sure one assumes that if the database is well designed (with key/key foreign constraints) there should be no duplicate problems as it would violate the database integrity.

    But the Application Business Level Pattern is not about technical integrity, like a User may inadvertly add a new line item in his shopping cart : technically this should not be forbidden as the user may indeed want to add the same item a second time (say for making the same gift to 2 friends) but in that case it would be a right business practice to warn the user and make him confirm or indeed forbid him and require him to modify the quantity field.

    This level should not be the coder's responsability but the product manager responsability (in the case of corporate organisation otherwise nothing prevent the same guy to wear the 2 roles but they are conceptually separate ).

  17. #17
    if ($zee == "Guru") { $zee--;}
    Join Date
    Nov 2005
    Location
    Karachi - Pakistan
    Posts
    1,134
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well

    Thanks a lot ! you people are always great !

  18. #18
    SitePoint Enthusiast
    Join Date
    Mar 2009
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is discouraging - if this thread accurately describes the available solutions.

    In my case I do have an autoincrement key. I don't believe there is general agreement that this is a bad thing. In fact I have come to use it more over many years, converted from the opposite camp.

    Anyway, the choices seem to be change the database design or accept double writing the record, so long as it is the same record you keep writing.

    I also have automatic date and timestamps, so it would never really write the exact same record a second time.

    I continue my search for the solution I am looking for.

  19. #19
    SitePoint Evangelist priti's Avatar
    Join Date
    Aug 2006
    Location
    India
    Posts
    488
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why it is considered to be bad design if your primary key is "auto increment" ?.

  20. #20
    SitePoint Zealot
    Join Date
    Jan 2006
    Posts
    125
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I found this thread while searching for a solution to the same problem as the OP. Nobody answered the last poster's question, namely why is it considered poor design to use autoincrement fields for primary keys? When I was learning database design (lo these many years ago) that's the standard that was recommended.

  21. #21
    SitePoint Zealot
    Join Date
    Jun 2010
    Posts
    142
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm also interested to see what "gurus" have to say about having auto_increment as bad practice. Other databases use triggers in order to have a similar feature.

    Saying that a database is poorly designed because it has tables with auto_increment fields is such a terrible statement, I'm really wondering what out of the world example would there have to be that auto_increment would be deemed BAD practice.

    I'll add more oil to fire - having FK constraints is much more terrible design in my book than having an auto_increment column. Why? Good luck debugging piece of software using a database with 300+ tables, everything FKeyed to oblivion by, oh so intelligent guy who created the db and read so many books using words like "database integrity" and "foreign keys".

    As for the original topic - Anthony covered it good, Post / Redirect / Get is the way to go.
    If there's a malicious user who's trying to insert duplicates in order to harm others - that's another thing, and totally different preventing accidental inserts.

  22. #22
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,807
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by bcalagoure View Post
    I found this thread while searching for a solution to the same problem as the OP. Nobody answered the last poster's question, namely why is it considered poor design to use autoincrement fields for primary keys? When I was learning database design (lo these many years ago) that's the standard that was recommended.
    It is a matter of whether there is another field in the table that is suitable to use as the primary key. If there is then you should use that as the key and not add an extra field just to use autoincrement.

    To be in third normal form all the fields in the table must be dependent on the primary key and nothing else and so having an alternative field that could be the primary key usually means that the table is not properly normalised. Now you may have decided to undo that normalisation for efficiency reasons (if the primary key field is huge) but the original logical design doesn't require an autoincrement in these cases (and rarely does require one if you design the database properly).

    The main reason so many people use autoincrement so frequently is that they don't know how to design databases. Each autoincrement field you add when an alternate field is an appropriate key comes at a cost of adding another way to break the integrity of the data.

    I am not saying you should never use autoincrement but the situations where it should be used is a small fraction of those instances where it is used and the simplest way to fix the double insert problem in most cases is to get rid of the unnecessary autoincrement.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  23. #23
    SitePoint Zealot
    Join Date
    Jun 2010
    Posts
    142
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The main reason so many people use autoincrement so frequently is that they don't know how to design databases.
    No, the main reason isn't that people don't know how to design databases.
    The main reason is that an integer uniquely identifying a record within a table is perfectly suited for being a primary key.
    It also removes the requirements of creating a trigger or similar application-level controlled means to create a way of creating a key that will uniquely identify a row.

    Each autoincrement field you add when an alternate field is an appropriate key comes at a cost of adding another way to break the integrity of the data.
    Care to provide an actual real life example which 10,000 web developers can relate to?

    I simply fail to grasp why an autoincremented integer fails as a primary key candidate in tables such as the table that contains this topic's information.
    How does it break integrity of the data?

    I am not saying you should never use autoincrement but the situations where it should be used is a small fraction of those instances where it is used and the simplest way to fix the double insert problem in most cases is to get rid of the unnecessary autoincrement.
    The actual problem was that user was able to hit F5 and resend the data.
    Whether you used autoincrement as primary key or not, whether you chose to notify the user that they're attempting to insert yet another similar record - how does that remove the ability to actually hit F5 and that browser asks you to resend the data or cancel?
    Why would you even BOTHER to perform a query in the first place when you can avoid it completely?
    Isn't that yet another overhead?

    Also, since I'm purely wondering - if people who don't know how to design databases are out there, how come that they make such popular software such as phpBB, Invision Board, vBulletin, WordPress and such that use auto_increment columns when used in combination with MySQL? Isn't your statement a little bit far-fetched when it comes to judging who is able to design databases and who isn't?

    The problem is that someone who's new to development with MySQL will take this advice seriously and the effect will be just the opposite - instead of teaching someone how to do things properly, the person will be under impression they're doing things right when they aren't.

  24. #24
    SitePoint Addict Shaydez's Avatar
    Join Date
    Jul 2006
    Location
    Boca Raton, Florida
    Posts
    356
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    no freakn way... I think the opposite; its bad NOT to use auto_increment. I design databases all the time and you're basically telling me my database design is all wrong for all the major corporations i design database for; and the teams i worked with and worked all use Auto_Increment to keep a consistency through the ERD / Database designs.

    Everyone has their own ways of coding and database design but... in these case its kind of saying Well an Apple is Red.. and you're trying to convince everyone the Apple is really Blue.

  25. #25
    SitePoint Zealot
    Join Date
    Jun 2010
    Posts
    142
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not the Apple. Honestly.
    (sorry for OT)


Bookmarks

Posting Permissions

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