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.
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).
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.
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.
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.