jsp submits questions repeatedly

After reading the Internet, there are several ways:
1 add this code to the HEAD section 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 to save in user session, add an hidden field in form, and display the token
The value of the card, after form is submitted, a new token is generated, and the user submits the token and session
If the token is the same, it is repeatedly committed
3
Use the Response.Redirect ("selfPage") statement in your server-side control code. But most Numbers don't use this method.
There are many other ways...
4
< input type="button" value=" submit "onclick=" this. disabled=true; this. form. submit ()" >

5

Add an hidden field to the FORM form on the JSP page
< input type="hidden" name="url"value= < %=request.getRequestURL()% > >

Add the following statement to your serverlet
String url=request.getParameter("url");
response.sendRedirect(url);
I usually use this method to return JSP page. I don't quite understand what you mean by repeated refresh

6 ajax no refresh commit

7 Web development prevents the browser's refresh key from causing a repeat commit of system operations
What's the solution? Redirection can solve the problem of repeated submission of data caused by page refresh, and we can naturally use redirection to solve this problem. mapping.findword (); Jump, the default is to find the project folder to jump to the page. How to solve this situation?
Modify the struts-config.xml file, there is a property of redirect redirection in action, false is the default in struts, add this property, change it to true, and write the absolute or relative address of the page to jump to in forword
The changes are 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> 

Repeat commit, repeat refresh, prevent back issues and handling

1. preface
You will see this problem in any professional BBS, even if you are under Google1, you will find that there are a lot of people paying attention to and asking about it, but the solutions given by everyone are very different, (some people advocate using scripts to solve it; Some want to redirect to another page; Others raise the issue to the point of view of Token.) why is there such a big difference?

2. Problem scenario
First of all, we should understand why we are dealing with such a problem. Or professional 1 is what is the appropriate scenario for it? (it seems that only people ask and no one explains)

1. Repeat commit, repeat refresh scenario
Repeat commit, repeat refresh are to solve the system record repeat problem. This means that someone is submitting a record multiple times (why? Perhaps it is idle and has nothing to do; Most likely, the user doesn't even know if his or her submission has been executed. !). .

However, such a problem does not have to be dealt with, depending on the type of system you are developing. You take is a resource management system, for example, the system itself from the perspective of demand does not allow a "repeat" records, in such a demand constraint conditions, to repeat the submit action will only cause the production of "business-level exceptions", cannot be performed successfully and you can't avoid not avoid problems.

2. Prevent backward scenarios
Now that we have seen the repeated refresh and commit scenarios, let's take a look at the reason for the "prevent backstepping" operation. For example, if you are developing a voting system, it has many steps, and these steps are related to each other. For example, step 1 will send some information to step 2, step 2 will cache the information, and step 3 will send its own information. Wait, if the user is in step 3 at this point, let's imagine that one of the naughty user's users clicks the back button, then the screen appears in the page of step 2, he modifies again or submits again, and goes to the next step (step 3), the error will be generated here, right? ! What mistake? The most typical is that such an operation directly results in the loss of information about the first step! (if this information is stored by Request, of course you can store it in Session or a larger context, but that's not a good idea! About the problem of information storage, we will discuss it in detail next time.)


3. How to deal with the problem
(such as reservation systems, of course, a lot of system itself is from the demand allows individuals to duplicate booking) is a must to avoid repetitive refresh, submit, and prevent back problems, but even such a problem, also want to distinguish how to deal with where and processing (online just tell you how to deal with, but seldom go to distinguish where the processing), clearly the means of processing is client or server, and in the face of the location of the different processing ways is also different, but there is 1 point to prior statement: The handling of any client (B/S in particular) is not trusted, and the best and most appropriate handling is on the server side.

Client processing:
Facing the client we can use the Javascript script to solve the problem, as follows

1. Refresh and commit repeatedly
Ways One: set 1 variable and allow only 1 submission.

<script language="javascript"> 
var checkSubmitFlg = false; 
function checkSubmit() { 
if (checkSubmitFlg == true) { 
return false; 
} 
checkSubmitFlg = true; 
return true; 
} 
document.ondblclick = function docondblclick() { 
window.event.returnValue = false; 
} 
document.onclick = function doconclick() { 
if (checkSubmitFlg) { 
window.event.returnValue = false; 
} 
} 
</script> 
<html:form action="myAction.do" method="post" onsubmit="return checkSubmit();"> 

Way Two :  Will submit button or image Set to disable 
<html:form action="myAction.do" method="post" 
onsubmit="getElById('submitInput').disabled = true; return true;"> 
<html:image styleId="submitInput" src="images/ok_b.gif" border="0" /> 
</html:form> 

2. Prevent user backtracking
There are various ways to change the history of the browser, such as using the window.history.forward () method. Some "replace the current history with URL for the new page, so that there is only one page in the browsing history and the back button never becomes available." For example, javascript: location. replace(this. href); event. returnValue = false;


2. Server-side processing (only Struts framework processing)
The synchronization token (Token) mechanism is used to solve the problem of repeated submissions in Web applications. Struts also provides a reference implementation.

Basic principles:
The server side will compare the token value contained in the request with the token value saved in the current user session before processing the incoming request.
See if it matches. After the request is processed, and before the reply is sent to the client, a new token is generated that is passed out
Outside of the client, the old token saved in the user session is also replaced. So if the user goes back to the submission page and does it again
In case of submission, the token sent by the client is different from the one sent by the server, thus effectively preventing the occurrence of repeated submission.

if (isTokenValid(request, true)) { 
// your code here 
return mapping.findForward("success"); 
} else { 
saveToken(request); 
return mapping.findForward("submitagain"); 
} 

Struts generates a 1-only (for each session) token based on the user session ID and the current system time
The generateToken() method in the TokenProcessor class.

1. // verify the transaction control token, < html:form > An implied input token is automatically generated based on the identifier in session to prevent two commits
2. In 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 session The token  

3. action has a method to generate tokens

protected String generateToken(HttpServletRequest request) { 
HttpSession session = request.getSession(); 
try { 
byte id[] = session.getId().getBytes(); 
byte now[] = 
new Long(System.currentTimeMillis()).toString().getBytes(); 
MessageDigest md = MessageDigest.getInstance("MD5"); 
md.update(id); 
md.update(now); 
return (toHex(md.digest())); 
} catch (IllegalStateException e) { 
return (null); 
} catch (NoSuchAlgorithmException e) { 
return (null); 
} 
} 

conclusion
For repetitive submission, refresh, prevent back and so on are all belong to the system in order to avoid duplicate records and need to solve the problem, on the client side to handle need for every one may put forward the corresponding solutions, however on the server side seems to be just a problem for the authenticity of the test data, processing is 1 LaoYongYi method based on the token.

At the same time, we also see that from different perspectives to look at the problem, its solution is also different. The client side is more pursuing the user's operation, while the server side is paying attention to the data processing, so in a seemingly easy problem for the server side, the client side to solve a lot of trouble! The reverse is still true. So there are some issues that we need to balance, and we need to do it on the client side, right? Or is it handled on the server side?