Web Project Evolution Series--Verification system

Objective

The data verification is divided into 2 parts, one is the front-end JS to check the user input data, the other is the back end when the request data validation. Some Web projects only in the front-end to verify the user's input data, but for the request to the back end of the data is not processed, this will leave behind a serious system vulnerability, or developers in the front and back to write the verification code, when the validation rules need to be adjusted, it is necessary to maintain together, slightly inadvertently there will be validation out of sync. For Web projects, there is an idea to take into account that all requested data is unsafe, because HTTP is stateless and requests can be simulated.

So this article is based on the previous article to increase the verification system, so that developers only need to develop back-end validation, by adding the corresponding class library support can directly generate the corresponding component HTML, and the front-end needs to develop components to give support, although it takes a lot of time to design, refactoring, But when it's done, the benefits are great, not only to greatly reduce the code that needs to be developed, but also to reduce the cost of maintenance.

Before I wrote about Easyui-based extensions, you can refer to this first:

• Easyui-based WebForm extension
• WebForm extension based on Easyui (cont.)
• Easyui-based MVC extension
• MVC extension based on Easyui (cont.)

Then the nonsense will not say more, go straight to the beginning.

Front

The backend class library can generate only the HTML of the front-end component, so it is necessary to design the component first, then draw the corresponding HTML according to the validation rules of the component, and implement the backend class library according to the rules.

The article is based on the angular component, because I am not familiar with HTML, so the example is relatively simple, the effect is only to change the text box background, the correct case is white, the error is red, the HTML code is as follows:

Angular component <br type= "text" valid-type= "validation rule" Data= "bound value" Uc-input/>//actual html<br type= "text" valid-type= "[' Stringlength ', {min:6, max:12}] "Data=" Data.name "Uc-input/>

The validation rule for this component is length validation: the length is between 6-12 and the validation component implementation of angular is not described in detail here (another article will be written later).

With the specific format of the front-end component, you can then start coding back-end code to support it.

Back end

First look at the length validation class, the code is as follows:

Validation class [AttributeUsage (Attributetargets.property, AllowMultiple = False, inherited = False)]public class stringlengthattribute:attribute{public    int MinLength {get; private set;}    public int MaxLength {get; private set;}    Public Stringlengthattribute (Int32 maxLength): This (maxLength, 0) {} public    Stringlengthattribute (Int32 maxLength , Int32 minLength)    {this        . MinLength = MinLength;        This. MaxLength = MaxLength;    }    public override bool Valid (object value)    {        var valuelength = (value?? string. Empty). ToString (). Length;        Return Valuelength >= this. MinLength && valuelength <= this. MaxLength;}    } Model public class entermodel{    [Stringlength (5)] public    string Name {get; set;}}

Although there is a model and the model has been added for validation, it can be used to generate component HTML, but with a real-world validation rule that is varied, an interface is still needed to provide a way to convert validation into THML.

In order to be compatible with the original Easyui, so I added the corresponding angular class to inherit stringlengthattribute and conversion interface, the code is as follows:

Public interface ivalidationconverter{    string ToHtml ();} public class Angularstringlengthattribute:stringlengthattribute, ivalidationconverter{public    Angularstringlengthattribute (int maxLength): base (maxLength) {} public    angularstringlengthattribute (int maxLength, int minLength): Base (MaxLength, MinLength) {} public    string ToHtml ()    {        var sb = new StringBuilder ("valid-type=\" [' Stringlength ', {");        Return SB. AppendFormat ("min: {0},", this.) MinLength)            . AppendFormat ("Max: {0}", this.) MaxLength)            . Append ("}]\"). ToString ();    }}

Although there is also a way to not add the Ivalidationconverter interface, directly in the generation of the angular component of the method to traverse attribute and determine what type of authentication, but switch to distinguish, and generate the corresponding HTML, This violates the principle of single responsibility, so it is convenient to use the interface, the model code is adjusted as follows:

public class entermodel{    [Angularstringlength (5)] public    string Name {get; set;}}

Next, you only need to write a class to generate the Angular validation component, the implementation of the method is simply the need to pass in the property name and the name of the binding, then the way the page binding is: <%= angular.input ("Property name", "Binding Name")%>.

If you want the binding method to support the expression, such as: <%= angular.input<tmodel> (m = m.name, "binding name")%>, then you need to parse the property name from the expression, the Get the value of an expression inside a lambda expression. This article explains.

The above method of generating angular component HTML is written here, left to you to achieve.

with the above verification support, the next step is to add the relevant validation support in the Mvchandler, we have implemented the object required to extract the routing method from the request, so we just need to validate the object in the next step, and if the validation pass calls the routing method, If it is incorrect, the error is called, and the Mvchandler validation code is as follows:

var isValid = Reqtype.getproperties (). All (P =>{    var attrs = P.getcustomattributes (false);    if (attrs. Length = = 0)        return true;    Return attrs. All (attr =    {        if (attr is ipropertyvalidation)            return (attr as Ipropertyvalidation). Valid (P.getvalue (req, null));        return true;    }); if (!isvalid) {    setting.error ("Data is incorrect!"). Executeresult (context);    return;}

Conclusion

Most of the code above can be put into the public library, I just opened a head, the latter part of the work will be based on specific projects to adjust, a wide range of validation and components, developers and artists need to work together to complete.

So it is here, if there are any questions or questions, welcome message, thank you.

Web Project Evolution Series--Verification system