41–50 of 109 posts
Earlier quoted context omitted.
There's something particularly ugly about people who feign ignorance of the way people less technical than them do things, in order to make themselves sound more elite.
It's not being less technical: using double click simply means you did desktop computing in the mid nineties on Windows. Anyone younger simply doesn't have that memory.
HTTP already handles this just fine if you have sensitive forms: your form can include a one-time token which your server validates. If the token has already been used, you don't process the second request. What we definitely shouldn't do (as the author suggests) is disable form submissions on subsequent clicks. What if the first response fails? You'll have to enter the entire form all over again, instead of being ab…
Forms should probably have a one-time token generated when the form is rendered. This will also help prevent CSRF and DDOS via hogging of resources. In fact, the same technique should apply to session tokens in general. They should be signed by the server, which removes the need to do I/O to filter out unauthorized sessions and mitigate DDOS attacks. So yes, this is the correct way to do it. But additionally, I don't…
Earlier quoted context omitted.
There's something particularly ugly about people who feign ignorance of the way people less technical than them do things, in order to make themselves sound more elite.
It's not being less technical: using double click simply means you did desktop computing in the mid nineties on Windows. Anyone younger simply doesn't have that memory.
Are double click actions still a thing? Windows has had an option for single-click mode since forever, and most users I know use it – mainly because they're used to single click from the web. The remainder and most Mac/Linux users don't even bother and navigate with the keyboard. I can't remember the last time I had to double-click anything, except for text selection.
Earlier quoted context omitted.
There's something particularly ugly about people who feign ignorance of the way people less technical than them do things, in order to make themselves sound more elite.
It's not being less technical: using double click simply means you did desktop computing in the mid nineties on Windows. Anyone younger simply doesn't have that memory.
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 or…
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.
Earlier quoted context omitted.
While I agree that you should include a one-time token with all sensitive forms, I don't think that disabling links/submit buttons on the first click is a bad idea in general. It's an easy fix that will immediately prevent most accidental redundant server requests, but as it's a client-side fix it's inherently unreliable. What's wrong though is the author's solution of disabling _all_ links and submit buttons on the…
This gets seriously annoying if you have an intermittent connection. I know the first click didn't succeed, so I have the choice of refreshing and losing all my typed content or manually using the web inspector to re-enable the button. It's shitty user experience.
HTTP already handles this just fine if you have sensitive forms: your form can include a one-time token which your server validates. If the token has already been used, you don't process the second request. What we definitely shouldn't do (as the author suggests) is disable form submissions on subsequent clicks. What if the first response fails? You'll have to enter the entire form all over again, instead of being ab…
While I agree that you should include a one-time token with all sensitive forms, I don't think that disabling links/submit buttons on the first click is a bad idea in general. It's an easy fix that will immediately prevent most accidental redundant server requests, but as it's a client-side fix it's inherently unreliable. What's wrong though is the author's solution of disabling _all_ links and submit buttons on the…
Of course, a common source of duplicate form submissions is when then submission request is taking long (>1000ms) and the user gives the button another click in a little while.
Browser makers like Mozilla think it's appropriate that holding down F5 should repeatedly pummel the server in accord with keyboard repeat rates. It's like the browser makers are being intentionally hostile towards web servers. E.g. https://bugzilla.mozilla.org/show_bug.cgi?id=224026 https://bugzilla.mozilla.org/show_bug.cgi?id=873045 There's no excuse, but they don't fix it.
> There's no excuse, but they don't fix it. Browsers exist for my convenience, not yours.
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 or…
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 underlyi…