sry, for not taking part at the discussion the first time (#107358: Prevent multiple form processing: causing duplication of nodes/users), but I think there is some room to further improve it.

First of all the current implementation does only prevent duplicate submissions if the user is pressing the same button twice or more. It can be tricked by toggling between two different submit buttons. That might be also a problem, if a user changes his decision and he tries to press the other button after he has already pressed the first one - which would lead to duplicate submissions.
Furthermore the current implementation might introduce problems, if the user wants to submit the same post data twice, which might be a legitimate use case, e.g. the confirm_forms for which currently the duplication check has been turned off.

So I'd propose to adapt the current behavior of serializing and hashing $_POST to using the form build time. Attached is the patch, which does this. It's tested to work with #multistep forms (even if they submit on each step) and it also detects duplicate form submissions even with different submit buttons. It lets each generated form submit only once, which of course doesn't affect multiple opened forms!

Furthermore I think the old implementation has troubles with programmed forms, that are invoked from inside a form submit. That would avoid any detection of duplicate form submits, because the programmed form would overwrite the session data. I've fixed this also.

Patch for 6.x is attached.

In short the advantages of this approach are:
• it also detects different pressed submit buttons,
• it fixes legitimate use cases, that submit the same post data twice
• it works with embedded programmatic forms too

Comments

fago’s picture

StatusFileSize
new3.62 KB

as the code is also in 5.x, here is a patch for 5.x

m3avrck’s picture

Wow this is great!!! Yes it really does improve some limitations of the current implementation. I would love to see this get into 5.x too -- since it's mostly bug fixes and better implementation.

Don't have much time to test it now but subscribing to add more thoughts later.

robertdouglass’s picture

Needs a re-roll now that http://drupal.org/node/141636 has gone in.

fago’s picture

StatusFileSize
new2.05 KB

ok, here is a rerolled version for 5.x
I've left over the option $form['#skip_duplicate_check'] from the old (reverted) solution. But there shouldn't occur any troubles with this duplicate checks, so we could remove the option to disable it?
If preferred, I reroll it without the option.

robertdouglass’s picture

Version: 6.x-dev » 5.x-dev

I'm changing the version of this back to 5 because the D6 version of this solution is going to be very different.

fago’s picture

Status: Needs review » Closed (won't fix)

I just recognized that this might introduce problems, if users use the back button of IE7. In this case IE7 doesn't reload the page, so the system will detect a duplicate form submission, when the user submits the form again.

So I think now this can't be solved cleanly on server side.

m3avrck’s picture

Best bet is still the JS method: http://drupal.org/node/107358#comment-487851

This will automatically be built into my new theme that is due out early Feb: http://drupal.org/project/blueprint

fool2’s picture

I've tried to do this with JS. However, it won't work if the user disables javascript. In my case, the users are trying to glitch the system purposely so that they can get extra points. (I'm running a game on a drupal backend)

Traverus’s picture

Version: 5.x-dev » 7.x-dev
Category: task » bug
Status: Closed (won't fix) » Active

Marked as closed (won't fix) and most new duplicates point here. Is this really never going to be fixed? It is apparently a pretty common complaint, these are the issues I found with 5 minutes of searching.

#873650: Node Submit button creates double entries if button is clicked fast
#107358: Prevent multiple form processing: causing duplication of nodes/users
#139670: skip duplicate form submits the second
#805058: Duplicate nodes created if Submit button is clicked twice in rapid succession

NBZ4live’s picture

Priority: Normal » Critical

The problem with the duplicate form submits is a critical bug, IMHO.

If your Drupal site runs on a server with limited resources and someone wants to bring it down, he simply needs a script for automatic submit of a form like the user_profile_form and every submit will produce a lot of unnecessary DB requests. That can cause many problems with the server load.
For example if you make 30 -50 submits of the user_profile_form per second, it can kill your site. Every submit of the user_profile_form saves the Data to the DB. The same for comment edit forms or what ever edit form the user can access.

You don't need a distributed attack. Only a small curl script and ip change possibility.

If you have a virtual or dedicated server, you can use this Nginx plugin: http://wiki.nginx.org/HttpLimitReqModule
But this is not available on shared hosts and is not a clean solution for such problems.

xjm’s picture

Version: 7.x-dev » 8.x-dev
Priority: Critical » Normal
Issue tags: +Needs issue summary update, +Needs backport to D7

See: http://drupal.org/node/45111 for the definition of issue priorities.

Let's add an issue summary here that explains the issue and the different routes to reproduce it. Clear steps that users can test will help.

kenorb’s picture

For references:
4.x-5.x module: http://drupal.org/project/formsingle
6.x-7.x module: http://drupal.org/project/hide_submit

j0rd’s picture

Seems silly to reply to a comment from 2007, but I just ran into this problem today. I know both Ubercart or Drupal Commerce handle this on the client side via JS, but that seems like a poor solution, since I would assume "submitting same form twice, in rapid succession, creating duplicate content" is a feature few want.

I need a fix for D7 myself.

Is there not something that could get done with $form['#build_id'] to prevent duplicates. Seems to me, that if you submit a form with the same build_id or form_token, that it should only get submitted once.

If anyone has a good solution for this, please let me know.

j0rd’s picture

Issue summary: View changes

link to older issue should be a [#...], not explicit url.

jcovington’s picture

#11 says this needs a backport to 7.x but I am not sure where to find the fix for 8.x, if it has been fixed there.

elijah lynn’s picture

jcovington, I don't think it has been fixed in 8.x yet but the way the Drupal core issue queue works is that everything must be fixed in 8.x first and once it is then it needs to be backported to 7.x.

Hope that helps.

elijah lynn’s picture

Btw, a current contrib workaround is to use the hide_submit module.

mitokens’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

Any followers of this issue able to update the IS to summarise the current state? Seems likely that things have changed a lot in the last five years...

pameeela’s picture

Issue tags: +Bug Smash Initiative
pameeela’s picture

Revisiting this. The hide_submit module mentioned here does not have a D8/9 version, so I thought it must now be resolved. I have found that this was fixed for most forms in #1705618: Double click prevention on form submission. It is still possible to replicate this for comments, but as that is a much more narrow issue I think we are better served creating a new ticket for that. So I am marking this 'Closed (outdated)' since much of this is already resolved, even though not completely. I have created #3220709: No double click prevention on content entity form.

I guess possibly this could be moved to the D7 queue, so if anyone thinks that should happen instead please reopen and update the version.