4 ms·

Because never trust user input and race conditions. The author says "Server-side, this is a much harder problem to solve." and he is correct. But that doesn't

Because never trust user input and race conditions. The author says "Server-side, this is a much harder problem to solve." and he is correct. But that doesn't mean that if the browsers did solve this problem that you wouldn't still need to solve it server side. For the same reason you still need to implement server side validation even though you have client side validation (never trust user input). Say you had an order form only allowing one order per customer (some special offer) and on the server you have a check to ensure order.count==1 you might assume that because the browser prevents double clicks on the form you are now safe. Except you aren't. It's pretty trivial to still send that form submission multiple times simultaneously (curl, ab) and trigger a race condition where each order.count check returns 0.

dexen 12y ago
Agreed, this should be solved server-side. Indeed it is possible to implement idempotent behavior of POST forms server-side. Even if a bit tedious to implement at first, it meshes very well with multi-user web apps, when several people may be changing the same underlying data simultaneously. One possible approach is carry in POST both old (original) state and new (user input) state, and apply it as a diff to underlying storage. Used this approach with 100% success on WWW based kiosks used by tradesmen, some of whom were habitual doubleclickers. Since the form was very simple -- one or two fields -- the old state was carried in action url. In case of double clicks, the seconds ended up changing nothing in backend storage, and returning correct data.
- snowwolf 12y ago
  The problem isn't idempotency as that just solves the problem of multiple synchronous submits (If order submitted what happens if order is submitted again). The real problem is the asynchronous nature of the web where both submissions could arrive at exactly the same time. And this is solved generally by using some kind of global lock (often at the database level).
  - oldmanjay 12y ago
    coarse locking is only a possibility at fairly small scales, unless your users like waiting. CSRF protection is the solution here as well. this entire article could have one comment that says nothing more and it would perfect.
    - snowwolf 12y ago
      Who said anything about course locking? Most databases support row level locking (think lock user row so each user cannot submit multiple orders at the same time). And I think you are misunderstanding CSRF. As the name implies it is protection against Cross Site attacks and will do nothing to help you prevent race conditions.

dexen 12y ago

Agreed, this should be solved server-side. Indeed it is possible to implement idempotent behavior of POST forms server-side. Even if a bit tedious to implement at first, it meshes very well with multi-user web apps, when several people may be changing the same underlying data simultaneously. One possible approach is carry in POST both old (original) state and new (user input) state, and apply it as a diff to underlying storage. Used this approach with 100% success on WWW based kiosks used by tradesmen, some of whom were habitual doubleclickers. Since the form was very simple -- one or two fields -- the old state was carried in action url. In case of double clicks, the seconds ended up changing nothing in backend storage, and returning correct data.

snowwolf 12y ago
The problem isn't idempotency as that just solves the problem of multiple synchronous submits (If order submitted what happens if order is submitted again). The real problem is the asynchronous nature of the web where both submissions could arrive at exactly the same time. And this is solved generally by using some kind of global lock (often at the database level).
- oldmanjay 12y ago
  coarse locking is only a possibility at fairly small scales, unless your users like waiting. CSRF protection is the solution here as well. this entire article could have one comment that says nothing more and it would perfect.
  - snowwolf 12y ago
    Who said anything about course locking? Most databases support row level locking (think lock user row so each user cannot submit multiple orders at the same time). And I think you are misunderstanding CSRF. As the name implies it is protection against Cross Site attacks and will do nothing to help you prevent race conditions.