JavaScript-How to organize duplicate submissions of a form

Background:
Today, I was tested for a bug, and I was wondering, because the bug was: There was no prohibition on repeating the form . Immediately feel the form form is really everywhere.

Generally we do not do the processing of repeated submissions, some places will use the way JS prohibit the submission of buttons, but also limited to the form submitted by JS.

So all kinds of Baidu, have said to use the session to mark, according to the mark to determine whether the first submission, but think this way to the back end is more complex, and the session is more expensive.

Today's test to mention the bug immediately let me have no clue, because this form is submitted synchronously, there is no JS participation. It is more impossible to write a set of JS for all synchronization forms.

So, in the face of this situation of synchronous submission of forms, how do you solve the problem of duplicate submissions?
Put your ace up your sleeve!

Reply content:

Background:
Today, I was tested for a bug, and I was wondering, because the bug was: There was no prohibition on repeating the form . Immediately feel the form form is really everywhere.

Generally we do not do the processing of repeated submissions, some places will use the way JS prohibit the submission of buttons, but also limited to the form submitted by JS.

So all kinds of Baidu, have said to use the session to mark, according to the mark to determine whether the first submission, but think this way to the back end is more complex, and the session is more expensive.

Today's test to mention the bug immediately let me have no clue, because this form is submitted synchronously, there is no JS participation. It is more impossible to write a set of JS for all synchronization forms.

So, in the face of this situation of synchronous submission of forms, how do you solve the problem of duplicate submissions?
Put your ace up your sleeve!

Onclick= "This.disabled=true" is a simple code that writes a set of???

For the front end, preventing duplicate submissions is a must ...
Of course, the backend depends on the situation, because the front-end only prevents users from manually clicking, but there is no way to prevent the impersonation request

Session set an expiration time, the use of database uniqueness (submitted is inserted into the database), submitted a local save a cookie, the second submitted to judge the Wood has

One result, n methods.
The session (or cookie) is more expensive but can be said to be more economical, after all, the other method is to make a new module call (CACHE,DB)
SESSION_ID can judge it.

I support disabling commits. It is not complicated to extract a common logic, and there is no need to write a single set for each table.

Prevent duplicate commits, in the final analysis, prevent one logical execution multiple times . However, it is not possible to require the full power of the backend, and the create operation is a counter-example. So a better practice is to start with the front end.

