4 ms·

I believe it is solvable without JS - you can’t prevent the request from being created, but you can prevent the second submission for having any effect. You co

by 542458 3y ago

I believe it is solvable without JS - you can’t prevent the request from being created, but you can prevent the second submission for having any effect. You could add a hidden UUID to the form server side and only process any submission with a given UUID once. I believe something similar is commonly done for anti-CSRF purposes. Alternatively, just rate limit users. A user making multiple comments within a few seconds of each other is probably either accidentally double-submitting or spamming. I think this is what HN does.

feoren 3y ago
> You could add a hidden UUID to the form server side and only process any submission with a given UUID once. Not if you have a load balancer that might send the two requests to different servers. If all of your requests are idempotent (difficult to pull off, but often worth it), you might be able to just let both servers handle it. But you still have your users inadvertently hogging resources they don't need. And if your request is taking a long time, a pissed-off user could be spamming the submit button in frustration (I'm sure I've done this before). You should absolutely prevent the 2nd submit in JavaScript, but I'll accept that disabling the button is not the best approach for that. > I believe something similar is commonly done for anti-CSRF purposes. That's a crypto-signed token you can use to verify you've pre-authorized the submission, not just some UUID. (You could do it with UUIDs if you keep a list, but ... don't)
- 542458 3y ago
  > That's a crypto-signed token you can use to verify you've pre-authorized the submission, not just some UUID. (You could do it with UUIDs if you keep a list, but ... don't) I'm struggling to remember the exact details here, but I believe Drupal 7 does what I described and just keeps a big list (expiry on entries set to 6 hours) in their database. I remember having issues with it getting very large when we had issues with bad scrapers hammering our site. Part of the issue though is that Drupal tracks the entire form (in order to prevent form tampering issues) and not just the UUID, which makes the table much larger than necessary for the use case of preventing CSRF and double-submits. https://drupal.stackexchange.com/questions/69803/cache-form-table-size-is-enormous/69842#69842 https://drupal.stackexchange.com/questions/69803/cache-form-...

by 542458 3y ago

feoren 3y ago

> You could add a hidden UUID to the form server side and only process any submission with a given UUID once. Not if you have a load balancer that might send the two requests to different servers. If all of your requests are idempotent (difficult to pull off, but often worth it), you might be able to just let both servers handle it. But you still have your users inadvertently hogging resources they don't need. And if your request is taking a long time, a pissed-off user could be spamming the submit button in frustration (I'm sure I've done this before). You should absolutely prevent the 2nd submit in JavaScript, but I'll accept that disabling the button is not the best approach for that. > I believe something similar is commonly done for anti-CSRF purposes. That's a crypto-signed token you can use to verify you've pre-authorized the submission, not just some UUID. (You could do it with UUIDs if you keep a list, but ... don't)

542458 3y ago
> That's a crypto-signed token you can use to verify you've pre-authorized the submission, not just some UUID. (You could do it with UUIDs if you keep a list, but ... don't) I'm struggling to remember the exact details here, but I believe Drupal 7 does what I described and just keeps a big list (expiry on entries set to 6 hours) in their database. I remember having issues with it getting very large when we had issues with bad scrapers hammering our site. Part of the issue though is that Drupal tracks the entire form (in order to prevent form tampering issues) and not just the UUID, which makes the table much larger than necessary for the use case of preventing CSRF and double-submits. https://drupal.stackexchange.com/questions/69803/cache-form-table-size-is-enormous/69842#69842 https://drupal.stackexchange.com/questions/69803/cache-form-...