Web development, frequently asked questions about JSP, repeated submissions to prevent backwards.

There are several ways to look at the Internet:
1 Add this code to the head area on 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, 1997 08:21:57 GMT" >
2
Generate a token to be saved in the user session, add a hidden field to the form to display the order
The value of the card, the form commits to regenerate a new token, the user submits the token and the session
The token comparison in, as the same is repeated commit
3
Use the Response.Redirect ("Selfpage") statement in the code of your server-side control. But most of the 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 a hidden field to the form form of a 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 to the JSP page, I do not quite understand what you say the duplicate refresh is what concept

6 Ajax No Flush commits

7 Web development prevents the browser's refresh key from causing the system operation to repeatedly commit
How to solve it? Redirection can solve the problem of repeated submissions of data caused by page refreshes, and we can naturally use redirection to solve this problem. But struts action inside Mapping.findword (); jump, the default is in the project folder to find the page to jump. How to solve this situation?
Modify the Struts-config.xml file, there is a redirect redirection property in the action, the default in struts is False, add this property, change to True, write in ForWord to jump page absolute or relative address on the line
Modify the following:
<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>

Repeated commits, repeated refreshes, preventing back-up problems, and how to handle them

One. Objective
You in any more professional BBS will see this problem, even if you Google, you will find a lot of people in the attention and inquiry, but all the solutions are different, (some people advocate the use of script to solve, some want to redirect to other pages; Some will raise this issue to the point of token) Why is there such a big difference?

Two. Problem Scenario
First of all, we should first understand why we should deal with such problems? Or professional, what is the right scene? (It seems that only people come to ask no one to explain)

1. Repeatedly committed, repeated refreshes of the scene
Repeated commits, repeated refreshes are all to resolve the system duplication of records. Which means someone commits a record multiple times (why?) Perhaps it is idle, there is nothing to do, most likely the user is not aware that their submissions have been executed?! ）。

But there are problems that do not necessarily have to be dealt with, depends on the type of system you are developing. For example, you take over a resource management system, the system itself from the point of view of demand does not allow the "duplicate" record, in such constraints, to perform repetitive commit action will only lead to "business-level exception" generation, it is impossible to implement the success of the problem is not to avoid avoiding.

2. Scenes to prevent retreat
Learn about recurring refreshes, repeating submissions, and what are the reasons for the Prevent back operation? For example, you are developing a voting system, it has many steps, and the steps are connected, such as the first step to send some information to the second step, the second step to cache the information, and send their own information to the third step .... And so on, if at this time the user is in the third step, we imagine a naughty user's user clicked the Back button, the screen appears the second step of the page, he again modified or submitted again, into the next step (that is, the third step), the error will be generated here?! What's wrong with it? The most typical is that this operation directly leads to the loss of information for the first step! (If this information is stored on request, of course you can store it in a session or a larger context, but that's not a good idea!) For information on the issue of storage, the next time in the detailed discussion on this issue)

Three. How to deal with the problem
Of course a lot of systems (such as the booking system from the demand itself is to allow individuals to repeat the booking) is necessary to avoid repeated refreshes, repeated submissions, and prevent back problems, but even the problem, but also to distinguish how to deal with and where to deal with (online just tell you how to deal with, but rarely to distinguish where to deal with) , obviously the way to deal with is nothing more than the client or server-side two, and the face of different location processing is different, but one thing to declare beforehand: any client (especially the B/s side) processing is not trustworthy, the best and most should be the server-side processing methods.

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

1. Repeat refresh, repeat commit
Ways One: Sets a variable that is allowed to be submitted only once.
<script language= "JavaScript" >
var checksubmitflg = false;
function Checksubmit () {
if (CHECKSUBMITFLG = = True) {
return false;
}
CHECKSUBMITFLG = true;
return true;
}
Document.ondblclick = function Docondblclick () {&NBSP;
    window.event.returnValue = False;&NBSP;
  }&NBSP;
   Document.onclick = function Doconclick () {&NBSP;
        if (CHECKSUBMITFLG) {&NBSP;
          Window.event.returnValue = false; &NBSP;
      } &NBSP;
  }&NBSP;
</ Script>&NBSP;

The same as: Place the submit button or image as disable

onsubmit= "Getelbyid (' submitinput '). Disabled = true; return true; " >

2. Prevent users from retreating
The approach here is to change the history of the browser, such as using the Window.history.forward () method, or "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, using Javascript:location.replace (THIS.HREF); Event.returnvalue=false;

2. Server-side processing (this is only what the Struts framework handles)
Using the synchronization token (token) mechanism to solve recurring problems in Web applications, struts also gives a reference implementation.

Basic principle:
The server side compares the token values contained in the request with the token values that are 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 to the
The old token that is saved in the user's session is also replaced by the client. So if the user rolls back to just the submission page and again
When submitted, the token passed by the client is inconsistent with the server-side token, thus effectively preventing duplicate commits from occurring.

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's session ID and the current system time, and the implementation can refer to
The Generatetoken () method in the Tokenprocessor class.

1.//Verify the transaction control token, 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 a token from the session

3. Action has a way 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); &NBSP;
           Md.update (now); &NBSP;
           Return (Tohex (Md.digest ())); &NBSP;
      } catch (IllegalStateException e) {&NBSP;
           return (NULL); &NBSP;
      } catch ( NoSuchAlgorithmException e) {&NBSP;
            return (NULL); &NBSP;
      } &NBSP;
  } 

Summarize
For repeated submissions, repeated refreshes, prevent back-up and so on is the system to avoid duplicate records and need to solve the problem, in the client to deal with each one of the possible to propose a corresponding solution, but on the server side seems to be only a test of the authenticity of data, token-based processing is a one-stop method.

At the same time, we also see that from different angles to look at the problem, its solution is different. The client is more in pursuit of the user's operation, and the service side will focus on the data processing, so in a server-side seemingly easy problem, with the client to solve but a lot of trouble! The reverse is still. So we need to think about and balance some of the problems we are dealing with, is it a client-side solution? Or do you use the server side to handle it?

Web development, frequently asked questions about JSP, repeated submissions to prevent backwards.