The problem of repeated submission of form data often occurs when users operate form Post data, especially in Web development. Refreshing the page, backing up the previous page, and multiple buttons in a single machine will result in repeated data submission. This type of problem is caused by the browser repeatedly submitting HTTP requests.

Four common solutions are listed below:

Add a unique field to the database

Add primary key constraint in ID field, add unique constraint in account and name information when database is created. Ensure that only one data can be added to the database.

This method fundamentally prevents duplicate data submission.

2. Disable the add button with js

After the user submits the form, you can use JS to hide the submit button (disable property), preventing the user from clicking the button more than once to submit data.

Note: This method does not work if the client has JS disabled.

3. Use Post/Redirect/Get

Post/Redirect/Get (PRG) is a Web design pattern that can prevent the repeated submission of form data. Typical problems of repeated submission of form data, such as refreshing the submission response page, can be avoided by USING PRG mode. For example, after the user submits successfully, the client redirects to the successful submission page.

Note: THE PRG design pattern does not apply to all duplicate submissions, such as:

1) Repeated submission caused by user refreshing submit POST request due to slow server response.

2) The user clicks the back button to return to the data submission interface, resulting in repeated data submission.

3) The user clicks the submit button for many times, resulting in repeated data submission.

4) Users maliciously avoid the client to prevent multiple submission means and repeat data submission.

4. Use Session to set the token

When a client requests a page, the server assigns a unique random id to each generated Form, sets this ID in a hidden field in the ORM, and stores this ID in the current user’s Session. When submitting the form, the server compares the hidden and session id to see if they are the same, continues, and clears the session after processing, otherwise the server ignores the request.

Note: Malicious users can take advantage of this property to repeatedly visit the page, resulting in an increase in the number of identifiers stored in the Session, which ultimately severely consumes server memory. This can be solved by recording the time a user posts in a Session and then limiting the number of consecutive posts by an interval.

* Welcome to follow my public account (synchronous update article) * : DoNet technology sharing platform \

Read the original