Inputbutton is a very serious problem. on a refund page, I have a button & lt; inputname & quot; btn_cancel & quot; type & quot; submit & quot; value & quot; cancelOrder & quot; & gt; press this button to execute the SQL statement, which is to return the total amount paid by others to their website account. The problem is that it is a very serious problem to press the input button.
I have a button in a refund page.
Press this button to execute the SQL statement, that is, return the total amount of money paid by others to their website account.
The problem is that if you click "cancel order", the browser needs to respond in 1 or 2 seconds. However, if you press the button continuously, the refund will be superimposed!
For example, if a user needs to refund 10 yuan, and he has ordered 10 yuan in a row by clicking "cancel order", the user's account will have 100 yuan more, regardless of the number of yuan they have ordered, 10 items are returned.
How should this be solved?
------ Solution --------------------
The button is hacked after the submission. In addition, use session variable control. When submitting, check whether repeated submission is required.
------ Solution --------------------
If the payment page involves cash, an order ID must be hidden in the form. the problem of repeated submission does not exist because the database is doing transactions.
Here, if your application is common, to prevent repeated messages, there is still a way to achieve it. Because PHP itself cannot do this transaction, that is, check whether the ID is paid and marked as payment. only the database can ensure the atomicity of the transaction, another method is the atomic addition of memcache.
Here, IDs are not stored by session because session variables are localized after session_start and cannot be shared among php processes. Therefore, only session_id can be used to store hidden form IDs in memcache.
Refresh the form should cause the id in memcache to be placed in the hidden field. submitting the form should cause memcache to add 1 to the id atom and determine whether the return value of atomic addition is form id + 1, if yes, the submission is successful. Otherwise, the submission fails. This is a disguised form of using memcache atomic addition to implement the transaction, because atomic addition avoids us to first take and then add, but increases the atom by 1 and returns the result, as long as we judge whether the value after-1 is equal to the id, it is also an odd trick, which is similar to idempotence or something. some distributed lockless operations do this.
------ Solution --------------------
Disabled can be used in the browser to disable it.
We recommend that you add a judgment on the server side. Otherwise, you will be done when someone else simulates repeated submissions.
