STRUTS2 note--9. Input checksum

Check is divided into client checksum server checksum. The client relies primarily on JavaScript code to complete, and server-side verification is done through programming in the program. The client can only prevent normal misoperation to reduce the load on the server, while the server side can prevent malicious attacks.

Write a validation rule file

STRUTS2 provides an input checksum based on a validation framework, so we only need to write a simple configuration file, and the framework will automatically help us with server client validation. With this framework, we don't need to make any changes to the code, just add a validation rule file. Create a Actionname-validation.xml file as a checksum file under the action directory that you want to validate.Each action has a checksum file. Verify the validators of the root element of the file, he can include validators or field, for each attribute that needs to be verified, there is a field child element. When the checksum fails, it jumps to the result of the action's input and is somewhat similar to the type conversion. Not only that, but the same information as the type conversion failure information is encapsulated in the fielderror and placed in the action context. The same applies to S:fielderror to output error messages. The Struts2 label form automatically outputs error messages. The validation rule file is as follows:

<?xml version= "1.0"  encoding= "UTF-8"? ><! doctype validators public  "-//apache struts//xwork validator 1.0.3//en"   " Http://struts.apache.org/dtds/xwork-validator-1.0.3.dtd "><validators><field name=" name "> <field-validator type= "requiredstring" ><param name= "trim" >true</param><message >you must input name</message></field-validator><field-validator type= " Regex "><param name=" regex "><! [Cdata[(\w{4,25})]]></param><message>you can only input letters and  numbers, length between 4 and25</message></field-validator></field ><field name= "Pass" ><field-validator type= "requiredstring" ><param name= "trim" >true</param><message>you must input password</message></ Field-validator><field-validator&nbSp;type= "regex" ><param name= "regex" ><! [Cdata[(\w{4,25})]]></param><message>you can only input letters and  numbers, length between 4 and 25</message></field-validator></ Field><field name= "Age" ><field-validator type= "int" ><param name= "min" >1 </param><param name= "Max" >150</param><message>must between ${min}  And ${max}</message></field-validator></field><field name= "Birth" >< Field-validator type= "Date" ><param name= "Min" >1900-01-01</param><param name= " Max ">2050-02-21</param><message>must between ${min} and ${max}</message ></field-validator></field></validators>

From the configuration file we see that each field element corresponds to a property that needs to be presented in an action. field, each of the field-validator is a validation rule. If the checksum fails, the action returns to the input view, and if the view is a previous s:from, the framework automatically outputs the message message on top of each textfield. This feature is very convenient.

After entering the login information, the message displayed:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/71/9B/wKioL1XVKoyRGM6AAADUf1i9-aU399.jpg "title=" Qq20150819210637.jpg "alt=" Wkiol1xvkoyrgm6aaaduf1i9-au399.jpg "/>

If you want to display the prompt in an internationalized manner, simply use the key property in the message property to invoke the key-value pair in the internationalized resource.

<message key= "Gender"/>

This code is identified, when the need to display this message, the schema will be called in the Internationalized file (now the action scope, and then the scope of the package, and finally in the global internationalization resources) value is the key value of gender, it is displayed on the input logical page.

Using client-side checksums

The client-side checksum requirement form must be generated by the Struts2 label, and the form's Validate property is true. This way the checksum is not committed to the server, and the address bar addresses the same. The only difference between the server checksum and the client-side checksum code is the Validate element in the form form. When using client-side validation, there are several points that require additional attention:

1. Because it is not for action, internationalization can only be done globally with global resources.

2. The textbook said that the client-side check enabled form Action,action and namespace to separate write, but I in the test, separate write error, not separate instead of error.

3. The theme property of a form cannot be simple.

4. The form page cannot be accessed directly. This form can be placed in the web-inf, so that the visitor accesses all resources through the core filter.

Two kinds of calibration styles

field precedence and non-field precedence are two kinds of validation styles. The above is the field first, because validator the following element is field, that is, to classify each field first. If you specify the validator first, and then add the name fieldname to it, and the value is the Param child element of the property name, the non-field takes precedence. This style requires only one message for the same validator.

Short Circuit check

When one of the TextField does not conform to the rule, the system stops verifying the following field, which is called a short-circuit check. You only need to set its short-circuit to ture in validator or Field-validator.

Search rules for verifying files

Because there are multiple methods in an action, each method requires a different validation rule. The STRUTS2 framework allows you to specify different validation rules for different control logic. A validation rule file should be written separately for each action's processing method. The naming rules are as follows: Actionname-actionaliasname-validation.xml

This file is also preceded by the name of the action implementation class, but an action alias is added to the middle. This name is the Name property of the action in Struts.xml. An alias check rule, in effect, is the sum of the total check rules and exclusive rules. That is, the ActionName rule takes effect for that particular method in the ActionName class, and the Actionaliasname rule also takes effect. If a conflict occurs, the following rule overrides the previous rule.

Various built-in validators

1. Required Checker: required. The specified field must have a value

<field-validator type= "Required" ><message>information</message></field-validator>

2. Required String: requiredstring. The specified string must be a non-empty length greater than 0. Its Trim property is used to determine whether or not to remove this property before or after the check.

<field-validator type= "requiredstring" ><param name= "trim" >true</param><message> Information</message></field-validator>

3. Integer checker: int, long, short. Verify that the field is an integer and must be within a certain interval. There are max,min of two attributes.

4. Date Calibrator: Data. The validation date must be within Max and Min range.

5. Expression Checker: Expressions. This is a non-field style validator that requires the OGNL expression to return TRUE or not pass validation.

6. Field Expression Validator: fieldexpression. Requires that the specified field satisfies a logical expression. This logical expression is made by the name Param of expression.

7. Email address checker: email. It has only one message property, and the system automatically determines that the field is not a standard email address.

8. URL Checker: URL. A validator for verifying legitimate URLs based on regular expressions.

9.visitor Validator: Used to verify the composite property in the action, such as user in action.

10. Conversion Checker: Conversion. Used to check whether a field has an error during the type conversion process. There is a Repopulatefield property that specifies whether form fields that fail type conversions retain the original information when the type conversion fails to enter the input page.

11. String length Checker: Stringlength. There are minlength and MaxLength properties.

12. Regular Expression validator: Regex. Used to check if a verified field matches a regular expression. The regex parameter is used to provide a regular expression. The casesensitive is used to specify whether the match is case-sensitive.

Annotation-based input validation

This method only needs to use annotations before the set method of the corresponding property in the action.

Manual completion of input validation

For some input checks that do not have a fixed logic, you can use manual methods. Override the Validate method in action to perform a manual check. When a rule is not met, the error message is added using the Addfielderror method. Added in the form of a key-value pair, so that we can take out a single value. Although it is labeled with value, the form label of struts outputs all the fielderror information. The schema determines whether the fielderror is empty to determine if the checksum is fully compliant. Because there may be a lot of processing logic in an action class, and we just rewrite a validate method, it cannot be used to specify which method to complete the checksum. In fact validate will validate all the methods. We can rewrite a series of validatexxx methods, XXX is the corresponding processing logic method. For example, the login class has the Regist method, you can override the Validateregist method to manually complete the validation of the Regist method.

This article from "Fingertip Light Fly" blog, declined reprint!

STRUTS2 note--9. Input checksum