Analysis of the issues and solutions for repeated submission, repeated refresh, and backoff prevention

one. Preface <br />You will see this kind of question in any professional BBS. Even if you Google it, you will find that many people are paying attention to and asking about it. However, the solutions they give are very different. (Some people advocate using scripts to solve it; some want to redirect to other pages; some raise the issue to the perspective of Token.) Why are there such big differences?
two. Problem scenario <br />First of all, we should understand why we should deal with such a problem? Or to be more professional, what scenarios is it suitable for? (It seems that only people come to ask but no one comes to explain)
1. Scenarios of repeated submission and repeated refresh Repeated submission and repeated refresh are both to solve the problem of duplicate records in the system. That is to say, someone submits a record multiple times (why? Maybe he has nothing to do; most likely, the user does not even know whether the result of his submission has been executed?!).
However, it is not necessary to deal with such problems. It depends on the type of system you are developing. For example, if you are in charge of a resource management system, the system itself does not allow "duplicate" records from a demand perspective. Under such demand constraints, performing repeated submission actions will only trigger "business-level exceptions", which will make it impossible to execute successfully and there is no need to worry about whether the problem can be avoided or not.
2. Scenarios for Preventing Backwards Now that we know about the scenarios of repeated refresh and repeated submission, let's understand the reason for the "prevent backwards" operation. For example, if you are developing a voting system, it has many steps, and these steps are related to each other. For example, the first step will send certain information to the second step, the second step caches this information, and sends its own information to the third step. . . . . Wait, if the user is in the third step at this time, let's imagine that a naughty user clicks the back button, and the second step page appears on the screen. He modifies or submits again and enters the next step (that is, the third step). Will an error occur here? ! What's wrong? The most typical case is that such operation directly leads to the loss of information about the first step! (If such information is stored in Request, of course you can store it in Session or a larger context, but this is not a good idea! Regarding the issue of information storage, we will discuss this issue in detail next time)
three. How to deal with the problem
Of course, many systems (for example, the ticket booking system itself allows individuals to make repeated reservations) must avoid repeated refreshes, repeated submissions, and prevent backoff issues. But even for such problems, it is necessary to distinguish how to handle them and where to handle them (the Internet only tells you how to handle them, but rarely distinguishes where to handle them). Obviously, there are only two ways to handle them: client-side or server-side, and the processing methods are different for different locations. But one thing must be stated in advance: any processing on the client side (especially the B/S side) is not trustworthy, and the best and most appropriate method is the server-side processing method.
Client side processing:
When facing the client, we can use Javascript script to solve it, as follows
1. Repeated refresh, repeated submission
Ways One: Set a variable to only allow submission once.

Copy code

The code is as follows:

2. There are many ways to prevent users from going back. Some methods change the browser's history, such as using the window.history.forward() method; some methods "replace the current history with the URL of the new page, so that there is only one page in the browsing history, and the back button will never become available." For example, use javascript: location.replace(this.href); event.returnValue=false;

2. Server-side processing (here only the processing of the Struts framework is mentioned)
Struts also provides a reference implementation for using the synchronization token mechanism to solve the problem of repeated submission in Web applications.
Basic principle:
Before processing the incoming request, the server compares the token value contained in the request with the token value stored in the current user session.
See if they match. After the request is processed and before the reply is sent to the client, a new token will be generated. In addition to being passed to the client, the old token saved in the user session will also be replaced. In this way, if the user returns to the previous submission page and submits again, the token sent by the client will be inconsistent with the token on the server, thus effectively preventing duplicate submissions.
if (isTokenValid(request, true)) {
// your code here
return mapping.findForward("success");
} else {
saveToken(request);
return mapping.findForward("submitagain");
}
Struts generates a unique (for each session) token based on the user session ID and the current system time. For specific implementation, please refer to
The generateToken() method in the TokenProcessor class.
1. //Verify the transaction control token, <html:form> will automatically generate an implicit input representative token based on the identifier in the session to prevent double submission
2. In the action:

//<input type="hidden" name="org.apache.struts.taglib.html.TOKEN"
// value="6aa35341f25184fd996c4c918255c3ae">
if (!isTokenValid(request))
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("error.transaction.token"));
resetToken(request); //Delete the token in the session
3. Action has a method to generate a token
protected String generateToken(HttpServletRequest request) {
HttpSession session = request.getSession_r();
try {
byte id[] = session.getId_r().getBytes_r();
byte now[] =
new Long(System.currentTimeMillis()).toString().getBytes_r();
MessageDigest md = MessageDigest.getInstance_r("MD5");
md.update(id);
md.update(now);
return (toHex(md.digest()));
} catch (IllegalStateException e) {
return (null);
} catch (NoSuchAlgorithmException e) {
return (null);
}
}
In summary, repeated submission, repeated refresh, and prevention of backoff are all problems that the system needs to solve in order to avoid duplicate records. To handle them on the client side, corresponding solutions need to be proposed for each possibility. However, from the server side, it is just a problem of verifying the authenticity of the data. Token-based processing is a once-and-for-all method.
At the same time, we also see that looking at the problem from different angles will lead to different solutions. The client is more concerned with user operations, while the server focuses on data processing. Therefore, a problem that seems easy for the server is much more troublesome to solve with the client! The opposite is also true. So when dealing with certain issues we need to make comprehensive considerations and balance, should we use the client to solve them? Or is it handled on the server side?

Web page anti-refresh duplicate submission, anti-backward solution Disable the submit button after submission (most people do this)
What if the customer presses F5 to refresh after submitting?
Using Session
Before the submitted page is processed by the database:
if session("ok")=true then
response.write "Error, submitting"
response.end
end if
After the data is processed, modify session("ok")=false.
Redirecting to another page immediately after successful data processing and refreshing is indeed a problem. You can use jump page and close this page. If it is controlled by parameter data conditions, it should be easy to do. You can directly modify the value of window.location and change all the parameters. That's almost it.
Disadvantages: Simply using Response.Redirect will no longer work, because as the user moves from one page to another, we have to clear location.history in client code. Note that this method clears the last access history record, not all access records. Click the back button, and then click the back button again, you can see that the page opened now is the page before this page! (Of course, this is assuming that JavaScript is enabled on your client side.)
What if the customer presses back?

Prevent web page from going back - disable caching When we are adding to the database, if we allow going back and the page happens to be refreshed, the adding operation will be performed again. This is undoubtedly not what we need. Like many codes that prohibit caching on the Internet, they are sometimes unreliable. At this time, you only need to add it to the operating page, specify the new page to be directed to in the web page, and then click back to see if you will not return to the previous operation page. In fact, this history has been deleted.
ASP:
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
ASP.NET:
Response.Buffer=true;
Response.ExpiresAbsolute=DateTime.Now.AddSeconds(-1);
Response.Expires=0;
Response.CacheControl="no-cache";
How exactly can I "disable" the browser's back button? or “How can I prevent users from clicking the back button to return to previously viewed pages?”
Unfortunately, we cannot disable your browser's back button.
Prevent web page from going back - use window.open to pop up the form page in the newly opened window, and close the page after clicking submit; the ASP page that handles submission also uses pop-up, sets the target of the form, clicks window.open("XXX.asp","_blank"), then uses JS to submit the form, and window.close() after completion;
Simply put, when the form is submitted, a new window pops up and the current window is closed. How to retract the window opened by window.open()? Where can you retreat to?
Haha, I've said a lot of nonsense. Do you know how to deal with it? Mix client-side and server-side scripting.

I have read the online article about jsp repeated submission and found several methods:
1 Add this code to the HEAD area of your form page:
<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache, must-revalidate">
<META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 1997 08:21:57 GMT">
2
Generate a token and save it in the user session. Add a hidden field in the form to display the value of the token. After the form is submitted, a new token is regenerated. The token submitted by the user and the session
The tokens in the comparison are repeated if they are the same.
3
Use the Response.Redirect("selfPage") statement in your server-side control's code. But most numbers don't use this approach.
There are many more methods. . .
4
<input type="button" value="Submit" onclick="this.disabled=true;this.form.submit()">
5
Add a hidden field to the FORM form of the JSP page
<input type="hidden" name="url"value=<%=request.getRequestURL_r()%>>

Add the following statement to your serverlet
String url=request.getParameter_r("url");
response.sendRedirect(url);
I usually use this method to return to the JSP page. I don't quite understand what you mean by repeated refresh.
6 ajax no refresh submit
7 How to prevent the browser's refresh key from causing repeated submission of system operations in Web development? Redirection can solve the problem of repeated submission of data caused by page refresh. We can naturally use redirection to solve this problem. However, if you use mapping.findword() in the struts action to jump, the default is to find the page to jump to in the project folder. How to solve this situation?
Modify the struts-config.xml file. There is a redirect attribute in action. The default value in struts is false. Add this attribute and change it to true. Write the absolute or relative address of the page to be redirected in forword. Modify it as follows:
<action-mappings>
<action attribute="newsActionForm" name="newsActionForm"
input="/addnews.jsp" path="/newsAction" parameter="method"
scope="request" type="com.yongtree.news.action.NewsAction">
<forward name="list" path="/listnews.jsp" redirect="true"></forward>
<forward name="error" path="/addnews.jsp"></forward>
</action>
</action-mappings>

The browser's back button allows us to easily return to previously visited pages, which is undoubtedly very useful. But sometimes we have to turn this feature off to prevent users from disrupting the scheduled order of page visits. This article introduces various solutions for disabling the browser back button that can be found on the Internet, and analyzes their respective advantages and disadvantages and applicable occasions.
1. Overview

Many people have asked, "How can I 'disable' the browser's back button?", or "How can I prevent users from clicking the back button to return to previously browsed pages?" This question is also one of the most asked questions in the ASP forum. Unfortunately, the answer is very simple: we cannot disable the browser's back button.
At first I was amazed that anyone would want to disable the browser back button. Later, I was relieved to see that so many people wanted to disable the back button (they only wanted to disable the back button, not the browser's forward button). Because by default, after submitting the form, the user can return to the form page through the back button (instead of using the "Edit" button!), and then edit and submit the form again to insert a new record into the database. This is something we don't want to see.
So I decided to find a way to avoid this situation. I visited many websites and referred to the various implementation methods introduced on these websites. If you often visit ASP programming websites, you may have seen some of the content introduced in this article. The task of this article is to introduce all possible methods to everyone and then find the best method!
2. Disable caching Among the many solutions I found, one of them suggested disabling page caching. Specifically, use the server-side script as follows:
<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
%>
This method is very effective! It forces the browser to revisit the server to download the page instead of reading it from cache. When using this approach, the programmer's main task is to create a session-level variable that determines whether the user can still view the page that is not accessible via the back button. Since the browser no longer has the page cached, when the user clicks the back button the browser will re-download the page, and the program can then check the session variable to see if the user should be allowed to open the page.

For example, suppose we have the following form:

<%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
If Len(Session("FirstTimeToPage")) > 0 then
&single; The user has visited the current page and is returning to visit it again.
&single; Clears session variables and redirects the user to the login page.
Session("FirstTimeToPage") = ""
Response.Redirect "/Bar.asp"
Response.End
End If
&single; If the program runs here, it means that the user can view the current page
&single; Let’s start creating the form
%>
<form method=post action="SomePage.asp">
<input type=submit>
</form>

We use the session variable FirstTimeToPage to check whether this is the first time the user visits the current page. If it's not the first time (ie Session("FirstTimeToPage") contains a value), then we clear the value of the session variable and redirect the user to a start page. Thus, when the form is submitted (when SompePage.asp is opened), we must assign a value to FirstTimeToPage. That is, we need to add the following code in SomePage.asp:
Session("FirstTimeToPage") = "NO"
In this way, if a user who has opened SomePage.asp clicks the back button, the browser will re-request the server to download the page. The server checks that Session("FirstTimeToPage") contains a value, so it clears Session("FirstTimeToPage") and redirects the user to another page. Of course, all of this requires the user to have cookies enabled, otherwise the session variables will be invalid. (For more explanation of this issue, see For session ariables to work, must the Web visitor have cookies enabled?)
Alternatively, we can use client-side code to prevent the browser from caching web pages:
<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
If you use the above method to force the browser to no longer cache web pages, you must pay attention to the following points:

"Pragma: no-cache" prevents the browser from caching the page only when using a secure connection. For unsecured pages, "Pragma: no-cache" is treated the same as "Expires: -1", in which case the browser still caches the page but marks it as expired immediately. In IE 4 or 5, the "Cache-Control" META HTTP-EQUIV tag is ignored and has no effect.
In real applications we can add all these codes. However, since this method does not work on all browsers, it is not recommended. But if it is in an Intranet environment, the administrator can control which browser the user uses, I think some people will still use this method.
3. Other methods

The approach we'll discuss next is centered around the back button itself, rather than the browser cache. Here is an article Rewiring the Back Button which is worth referring to. However, I noticed that if this method is used, although the user will not see the page where he previously entered data when clicking the back button once, he only needs to click twice, which is not the effect we want, because many times, stubborn users can always find ways to bypass preventive measures.
Another way to disable the back button is to use client-side JavaScript to open a window without a toolbar, which makes it difficult for the user to return to the previous page, but not impossible. A safer, but rather annoying, approach is to open a new window when the form is submitted, and at the same time close the window containing the form. But I don't think this approach is worth serious consideration, because we can't let the user open a new window every time they submit a form.
So, can we add JavaScript code to the page that we don't want users to return to? The JavaScript code added to this page can be used to produce the effect of clicking the forward button, thus offsetting the action generated by the user clicking the back button. The JavaScript code used to implement this function is as follows

As shown:
<script language="JavaScript">

</script>
Again, while this approach works, it is far from being the “best approach.” Later I saw someone suggest using location.replace to go from one page to another. The principle of this method is to replace the current history record with the URL of the new page, so that there is only one page in the browsing history and the back button will never become available. I think this may be what many people are looking for, but it is still not the best approach for every situation. An example using this approach is shown below:
<A HREF="PageName.htm" onclick="javascript:location.replace(this.href);
event.returnValue=false;">Disable the link to return to this page</A>
Back links to this page are prohibited!
The downside of this approach is that simply using Response.Redirect will no longer work, because every time the user navigates from one page to another, we have to clear location.history in client-side code. Also note that this method clears the last access history, not all access records.
Clicking on the link above will open a simple HTML page. Click the back button again, and you can see that what is opened is not the current page, but the page before this page! (Of course, you must have client-side JavaScript enabled in your browser.)
After some careful searching, I still couldn't find a way to completely disable the browser back button. All of the methods described here can prevent users from returning to the previous page to varying degrees and in different ways, but they all have their own limitations. Since there is no way to completely disable the back button, the best solution should be a mixture of client-side and server-side scripts.

<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
<script language="JavaScript">

</script>
</html>
Asp.net prevents repeated submissions and backoff in simple operation methods to prevent backoff and refresh
Add in Page_Load
Response.Cache.SetNoStore();
//The variable "IsSubmit" stored in the Session is used to mark whether the submission is successful
if (!IsPostBack)
if (Session["IsSubmit"]==null)
Session.Add("IsSubmit",false);
if ((bool)Session["IsSubmit"])
{
//If the form data is submitted successfully, set "Session["IsSubmit"]" to false
Session["IsSubmit"] = false;
//Show submission success information
TextBox1.Text = " * Submit successfully!";
}
else
{//Otherwise (not submitted, or the page is refreshed), no information is displayed
TextBox1.Text = "";
Response.End();
}
Add to submit button
Session["IsSubmit"] = true;
Response.Redirect ("this page");

in addition:
1. Usually, judgment (uniqueness) should be made at the business level to solve this problem
2. Write Response.CacheControl = "no-cache" in the page loading event to clear the cache
3. Some people also said: I have encountered such a problem before. It was a person's resume that was submitted in steps. After completing the first page, it jumped to the second page. In order to prevent the user from using the back button to return to the first page and then resubmit the first page, when the user submits the first page for the first time, the self-incrementing id number of the record inserted into the database is put into the session. When the user returns from the second page to the first page and submits the page again, I use the value in the session to check the database. If the id is found, I use the update statement to write the data of the first page into the database. If the id is not found, I use the insert statement.

<<: Detailed explanation of four types of MySQL connections and multi-table queries

>>: Control the vertical center of the text in the HTML text box through CSS

Analysis of the issues and solutions for repeated submission, repeated refresh, and backoff prevention

js Promise concurrent control method

Use Visual Studio Code to connect to the MySql database and query

HTML markup language - form

Use render function to encapsulate highly scalable components

Detailed tutorial on installing mysql 8.0.20 on CentOS7.8

Deeply understand how nginx achieves high performance and scalability

Detailed steps for installing and using vmware esxi6.5

Let's talk about bitwise operations in React source code in detail

Linux firewall iptables detailed introduction, configuration method and case

How to use rem adaptation in Vue

Recommend

Summary of the minesweeping project implemented in JS

Implementation of FIFO in Linux process communication

Example of how rem is adapted for mobile devices

Summary of the use of special operators in MySql

MySQL DATE_ADD and ADDDATE functions add a specified time interval to a date

Details of using Vue slot

Detailed configuration of Nginx supporting both Http and Https

How to prevent iframe from jumping to the page in HTML and use iframe to embed WeChat web version in the page

Detailed explanation of Nginx+Tomcat load balancing cluster installation and configuration case

Web Design Tutorial (5): Web Visual Design

How to use partitioning to optimize MySQL data processing for billions of data

Detailed explanation of jQuery's animate animation method and animation queuing problem solution

How to install vncserver in Ubuntu 20.04

A brief discussion on the solution to the problem of native page compatibility with IE9

The actual process of encapsulating axios in the project