Preventing multiple execution of Save action

Preventing multiple execution of Save action

On a screen, we have a Save button that creates a new record in the database based on the user input. However, if the user manages to click the button quickly multiple times, multiple records are created, as the requests are handled by IIS in parallel. Is there an easy way to prevent this?
Hi Kilian, you can disable the button ononeclick with Javascript to prevent multiple calls to the server.

Best Regards
Yeah, I was afraid that using Javascript would be necessary. It's such a common use-case that I can't believe the platform doesn't supply a native solution.
Hi Kilian,

I went ahead and added this as a new idea:

Another pattern that sometimes requires a manual implementation is Post/Redirect/Get - this one is important to prevent duplicate submissions by people refreshing their browser (and not realizing what the browser warning means).
The link to the idea is not found. Was the idea correctly created?

Maybe he pressed the submit button twice.

Tiago Bernardo wrote:
The link to the idea is not found. Was the idea correctly created?
 The idea is there, but someone forgot to turn on SEO Rules after the intervention. It is in
Hi Tiago,

Please test now. It should be fixed. This was due to our maintenance this morning...
Yup! It was broken for a bit, but things are now coming back. ;)
Just stumpled on this problem right now on a recent production system... duplicate records were created...
When developing the application this situation can be avoided with extra validation code, but the whole purpose of RAD is undermined with this approach... The developer should not be worried about this so frequent cenario...
Well, one way to do this is to use tokens.

1. Add an hidden text field to your form and, in the Preparation, in the part that does't run during a screen refresh, set it with some random value. Also, assign this same value to a session variable.

2. Immediately at the begining of the action that handles the button, check that the values in the hidden field and the session variable match. If they do, clear the session variable, and do whatever the button should do, if they don't immediately exit the action.

As an added bonus, no more CSRF attacks on your form!

Note: if your users are *really* fast or you have a network with very high latency, since the requests do run in parallel, I'm sure we can all see where a race condition could happen.
I'm sure there are plenty of solutions for this, but have you taken a step back and looked at the overhead that you just introduced just to take care of this problem?... (an hidden text field, a session variable, complicating the logic of the action...)
Yup :)

Disabling the button using JavaScript works for most cases, and it's a lot easier, and has no overhead on the server.

However, for websites on the Internet where anyone can reach them, it may be necessary to prevent CSRF attacks too. And this does that too.

On that note, if you only want to prevent CSRF attacks, you may use a cookie instead of a session variable, and reduce the server overhead.

(But then again, I'm the kind of guy that enters alert('LOL!'); as a name in random websites...)
To save the hassle of adding javascript everywhere, I've made a small component to disable a button or link after it is clicked (with javascript).
Apparently this idead was merged with this one:
Carlos Ribeiro da Fonseca wrote:
(But then again, I'm the kind of guy that enters alert('LOL!'); as a name in random websites...)
 Oh, that made me giggle :).