Java-web prevent duplicate commit, dynamic verification code __HTML5

I. Situations where duplicate submissions may occur in the project:
1, repeatedly click the Submit button due to slow server or network latency.
2, has been submitted successfully, refresh the Success page (forward).
3, has been submitted successfully, through the fallback, click the Submit button again.
Attention:
1, back back, refresh the form page, submit it again instead of repeating the submission, but send a new request
2, under Firefox, repeated submission to the same address is invalid
Second, the solution of the form of duplicate submission program:

1. Program one, using javascript:
Resolved repeated-click button Repeat submit request, but did not resolve refresh page repeat submission.

	var Flag=false;
	function Save () {
	     if (!flag) {
	     	document.forms[0].submit ();
	     	flag=true;
	     } else{
	     	alert ("You have submitted the page");
	     }
	 

Note:
         If you are using the <input type= "Submit", You need to return the form form's onsubmit= "to false;", or the onclick= of the submit button to go back to save (), and the Save method always returns to Flase;

2, using a unique random string (using session)
(1) UUID:
Pages that contain form forms must be generated dynamically by a server program that assigns a unique random identification number to the form form in each resulting page and sets the identification number in a hidden field in the form form. This identification number is also saved in the session domain of the current user.
When the user submits form forms, the server program that receives the request compares the identification number in the form hidden field with the same identification number that is stored in the session domain of the current user and, if the same, processes the form data and clears the identification number stored in the current user's session domain when the same is done. The server program ignores the submitted form requests in the following cases:
The form identification number does not exist in the session of the current user
No identification number field in user submitted form data
The form identification number that is stored in the session domain of the current user differs from the identification number in the form data
Only when the browser requests a page that contains the form form again to the Web server does the server program produce another random identification number and saves the identification number in the session field and as a hidden field value in the newly returned form form.

To prevent duplicate submissions using UUID:
A, use the UUID class to generate random strings
b, getuuidstring, generate UUID values coexist in session
C, verify that the UUID value from the form is compared with the value in the session.
4, reset UUID value.

Sample code:

Package test.util;

Import Java.util.UUID;

Import Javax.servlet.http.HttpServletRequest;

Import Org.apache.commons.lang3.StringUtils; public class Tokenutil {public static void GetToken (HttpServletRequest request) {String Randomvalue = Uuid.randomuui D (). toString (); Value String randomname = Uuid.randomuuid () to session. ToString ();//to the session the name Request.setattribute ("Randomvalue", ran
		Domvalue);
		Request.setattribute ("Randomname", randomname);
	Request.getsession (). setattribute (Randomname, Randomvalue); /** * Request the random number in the form and the random number in the session correspond to return true * * @param request * @return/public static Boolean validate (HttpServletRequest request)
		{//Get the page upload hand over.
		String Randomvalue = Request.getparameter ("Randomvalue");

		String randomname = Request.getparameter ("Randomname");
		Gets the string Randomvalueinsesson = (string) request.getsession (). getattribute (Randomname) in the session; Return Stringutils.isnotblank (Randomvalueinsesson) && stringutils.Isnotblank (Randomvalue) && randomvalue.equals (Randomvalueinsesson);
		public static void Resettoken (HttpServletRequest request) {String Randomname = Request.getparameter ("Randomname");
	Request.getsession (). removeattribute (Randomname); }
}

(2) STRUT1 synchronization token
(3) Implement one-time verification code with session
The primary purpose of a one-time captcha is to restrict people from using tool software to use brute force guessing passwords. The principle and the use of session to prevent the form of repeated submission of the principle of the same, just the form identification number into the form of verification code, and the user will be prompted to the verification code manually fill in a form field, Instead, it is automatically passed back to the server through the hidden fields of the form.
After the server program receives the form data, it first determines whether the user has filled in the correct authentication code, only when the CAPTCHA matches the authentication code saved on the server side, the server program begins the normal form processing process.
Password guessing tool to try each password before the first condition is to enter the correct code, and the verification code is one-time valid, so basically block the password guessing tool automatic processing process.

Servlet output Graphics Verification code:
BufferedImage used to generate memory graphics
BufferedImage image=new BufferedImage (WIDTH,HEIGHT,BUFFEREDIMAGE.TYPE_INT_BGR);
Graphics used to generate a drawing object that can be drawn
Graphics G=image.getgraphics ();
G.fillrect (0, 0, Width, height)/fill Rectangle
G.drawrect (0, 0, width-1, height-1);//Draw Rectangle
G.setfont (New Font ("Song Body", font.bold,35);//Set Font
g.DrawString (rank, codex* (i+1), Codey);//Output string
G.drawoval (x, y, 0, 0);//Draw confusing line
G.dispose ();
ImageIO object, for output pictures
Imageio.write (image, "JPG", Response.getoutputstream ());//Output picture

Attached: IE7 Firefox Verification code no response problem
Problem: The picture below IE6 is normal, but not refreshed under IE7 and Firefox
Situation Analysis: If the new picture and the old picture address is not the same, the effect will come out. That is: The picture has changed. But like the "Captcha" feature, the address of the old and new picture is the same because it is a dynamically generated picture of the servlet. In view of the above, it is possible that the image address is the same, causing the browser to read the cache automatically.

Workaround one (using random numbers)
Change the JavaScript to this way:

function Nextpic () { 
            var Img_=document.getelementbyid ("pic");     
            img_.src= "${pagecontext.request.contextpath}/ 
                   imageservlet?" +math.random (); 
       } 
       

That is: Each access address is not the same, because there is a random number. So the problem is solved.

Workaround two (using the timestamp), change the JavaScript to this way:

function Nextpic () { 
           alert (date.parse (New Date ())); 
           var Pic=document.getelementbyid ("pic"); 
           pic.src= "${pagecontext.request.contextpath}/ 
imageservlet?" +date.parse (New Date ()); 
      } 

      

Date.parse (): Resolves a string that contains a date and returns the number of milliseconds between that date and midnight of January 1, 1970