CSRF and double posting

And WTF? When did Narf use the word 'sychronous'? Your entire tirade is based on a misreading.

No, you can "forget" about asynchronous requests if you're not updating your form tokens.

Concurrency is not asynchronicity; the OP is having the double-submit problem exactly because concurrency is not a problem.

I said concurrent AJAX requests, you can't send concurrent synchronous AJAX requests since JS is single threaded so I'm not sure what else to take from that. Yes you can multi-thread with web workers but the DOM paints in a single blocking thread.

And the A in AJAX stands for 'AND', is that the A you were referring to?

The first A. Asynchronous JavaScript And XML.

And no, "if they can get it once they can get it 100 times" is simply not true. What if I got it by getting you to click on a malicious link? Are you going to click on that link 100 times? No, you are not.

That's only one way and there's a lot more possibilities with XSS attacks.

I'm not arguing the theory, that would be pedantic, but in reality the limits imposed by per request CSRF tokens simply aren't worth the theoretical security advantages. Can you imagine how an app like Google Docs would function without multiple concurrent requests? Our app is an editor that's very similar and it wouldn't be worth building under those constraints.

I replied under the same line of reasoning. Having a user click back and being unable to submit a form provides a bad user experience and security should never trump usability. If it does another approach to security is needed not the other way around.