I don't see the problem. Contrary to the post, double clicking a link doesn't open it twice, and double clicking a submit button doesn't submit the form twice; at least, not on Chrome or Firefox on Linux.
Double-clicking on the Web
71–80 of 109 posts
Re: Double-clicking on the Web
#72HTTP 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…
Re: Double-clicking on the Web
#73If submission gets stuck and doesn't go through (because mobile networks, public wifi, and "cloud" servers have more failure modes than we'd like…) user is stuck with permanently-disabled buttons and can't retry submitting.
Re: Double-clicking on the Web
#74Re: Double-clicking on the Web
#75HTTP 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…
Re: Double-clicking on the Web
#76We're not "trained to double-click anything", unless some particular trainer is extremely misguided.
Double-clicking is used when there is some action available for an item in addition to the single-click action, where the double-click usually leads to both actions taking place: we single-click to select files and double-click to open them, single-click the title bar to activate the window and double-click to maximize, single-click the window menu to view the menu and double-click to close the window (which is one of the options in the menu).
Some examples of things we only single-click: buttons, scrollbars, tabs, menus, dropdowns, text (for selection).
Single-click is everywhere. Everything that can be double-clicked can also be single-clicked. Single-click is the default. If a single-click only leads to an item beings selected, that's a pretty good hint to try double-click if you also wanted it to be opened.
(Incidentally, what do those who double-click everything do when they want to select a file? Do they just open it, close it again (leaving it selected) and accept that as normal?)
Re: Double-clicking on the Web
#77Browsers do not provide immediate visual feedback on some things for which they should. When you click on a link which exits the page, something visual should happen immediately, long before the new page loads. The browser knows you're leaving. Dimming the page, or some other visual transition, would be a good start. That would make a clear distinction between page-exiting actions and ones which keep the page active.
Re: Double-clicking on the Web
#78Are 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.
We single click links just like we single click buttons. Form buttons on a browser should behave like regular buttons in the operating system: single click. Clicking an item in a list should select the item. Double clicking an item in a list should open it. This is the part that might be broken in the web browser because I see check boxes and all sorts of other UI gymnastics to enable the functionality of how a list…
Re: Double-clicking on the Web
#79Earlier quoted context omitted.
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…
Signing is slow, if anything signing the CSRF tokens just became your bottleneck, if not you just inflated the request size by kilobytes for no good reason.
And also the CSRF token doesn't need signing, it comes from the session data stored on the server. The session id is what needs signing.
Re: Double-clicking on the Web
#80Earlier quoted context omitted.
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…
So the DDoS attacker can't retrieve said tokens?
Once an account is created, throttling resources is straightforward. If you want, you can allow a person to have one X per Y (time, points, whatever).