Verification method and device
By defining the verification parameter method in the policy class and using reflection to obtain annotations, the problem of request message styling verification in the prior art that is difficult to meet complex service functions is solved, and personalized verification of request message styling is achieved to meet the needs of flexible verification.
Patent Information
- Application Number
- CN202411743237.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-29
- Publication Date
- 2025-03-21
AI Technical Summary
The prior art is difficult to meet the demand for request message sports verification in complex service functions, and simple verification rules are difficult to achieve personalized and flexible verification.
By defining the verification parameter method in the policy class, using reflection to obtain the annotation of the target field, and obtaining the corresponding policy class instance according to the annotation class name, and calling the verification method for field-level verification.
It realizes field-level personalized verification of request message format, meets the needs of flexible verification, and reduces the intrusion of business logic.
Smart Images
Figure CN119670163A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of interface verification, and in particular to a verification method and device. Background Art
[0002] With the rapid development of Internet technology, there are security vulnerabilities in the interaction process between Internet devices. For example, there are security issues such as tampering with HyperText Transfer Protocol (HTTP) request parameters and unauthorized access. It is difficult to meet the needs of network security by only checking the front end. It is necessary to perform interface verification on the front end request message at the interface layer of the back end.
[0003] At present, you can use annotations to perform parameter verification on the fields in the VO entity object by relying on the API provided by the Spring Validation validation framework, so as to separate parameter verification from business logic. The verification rules for parameter verification are relatively simple, for example, a certain input field cannot be empty, and the email format must comply with the email specification.
[0004] However, as business functions continue to expand, simpler verification rules are unable to meet the needs. Summary of the invention
[0005] In view of this, the present application provides a verification method and device, which can realize personalized verification of the request message body.
[0006] The technical solutions provided by this application are as follows:
[0007] In a first aspect, the present application provides a verification method, the method comprising:
[0008] A verification parameter method is defined in the policy class, the verification parameter method includes method parameters, the method parameters include an object to be verified, a field of the object to be verified, and a first group list for verification, the object to be verified is a request message body, and the first group list includes verification rules;
[0009] Obtain the annotation of the target field through a reflection method, and compare the name of the annotation of the target field with the annotation class name maintained by the first global variable, wherein the target field is any field of the field of the object to be verified;
[0010] If the target annotation class name is hit, obtain a second group list corresponding to the target annotation class name;
[0011] If the first grouping list and the second grouping list have an intersection, and it is determined that the field value of the target field is not empty, obtaining the corresponding instance of the policy class according to the target annotation class name;
[0012] The target field is verified by calling a verification method through the instance.
[0013] In a possible implementation, comparing the name of the annotation of the target field with the annotation class name maintained by the first global variable includes:
[0014] Obtain the annotation of the target field of the object to be verified through the reflection method provided by the Feild class;
[0015] Write the annotation of the target field into the annotation array;
[0016] The annotation array is traversed to search for a target annotation class name that is the same as the annotation class name included in the first global variable.
[0017] In a possible implementation, obtaining an instance of a strategy class according to the target annotation class name includes:
[0018] An instance of a policy class corresponding to the target annotation name is queried from a second global variable, wherein the second global variable includes a key-value pair, wherein the primary key is the result returned by the method for obtaining the annotation class name of the instance, and the value corresponding to the primary key is the instance of the policy class.
[0019] In a possible implementation, the method further includes:
[0020] The strategy class that defines the verification parameter method is dependent on the ValidationUtil tool class.
[0021] In a possible implementation, the instance of the strategy class is created in the ValidationUtil tool class, and the instance of the strategy class is created in the following way:
[0022] Use Reflections to scan the specified package path and find the implementation class that implements the public interface; the public interface is pre-defined in the public component library, and the public interface declares a method for obtaining the annotation name and a method for implementing the annotation function;
[0023] Get an instance of the implementation class from the Spring container;
[0024] If the instance of the implementation class cannot be obtained from the Spring container, an instance is created through the reflection mechanism; the instance of the implementation class is encapsulated into the second global variable, and the annotated class name of the implementation class is encapsulated into the first global variable.
[0025] In a possible implementation, the method further includes:
[0026] Create a custom annotation class in the project;
[0027] Creating an implementation class in the project to implement the public interface;
[0028] Rewrite the method for obtaining the annotation class name of the public interface in the implementation class, and return the custom annotation class name in the method for obtaining the annotation class name;
[0029] Rewrite the verification method of the public interface in the implementation class.
[0030] In a possible implementation, the target field corresponds to multiple annotations, and the multiple annotations respectively correspond to a custom annotation class.
[0031] In a second aspect, the present application provides a verification device, the device comprising:
[0032] A definition unit, configured to define a verification parameter method in a policy class, wherein the verification parameter method includes method parameters, wherein the method parameters include an object to be verified, a field of the object to be verified, and a first group list for verification, wherein the object to be verified is a request message body, and the first group list includes verification rules;
[0033] A first acquisition unit is used to acquire the annotation of the target field by a reflection method, and match the name of the annotation of the target field with the annotation class name maintained by the first global variable, wherein the target field is any field of the field of the object to be verified;
[0034] A second acquisition unit is used to acquire a second group list corresponding to the target annotation class name if the target annotation class name is hit;
[0035] A third acquisition unit is used to acquire the corresponding instance of the policy class according to the target annotation class name if the first grouping list and the second grouping list have an intersection and it is determined that the field value of the target field is not empty;
[0036] A verification unit is used to verify the target field by calling a verification method through the instance.
[0037] In a possible implementation, the first acquisition unit is used to match the name of the annotation of the target field with the annotation class name maintained by the first global variable, including:
[0038] The first acquisition unit is used to obtain the annotation of the target field of the object to be verified through the reflection method provided by the Feild class; write the annotation of the target field into the annotation array; traverse the annotation array to query the target annotation class name that is the same as the annotation class name included in the first global variable.
[0039] In a possible implementation, the third acquisition unit is used to acquire the corresponding instance of the strategy class according to the target annotation class name, including:
[0040] The third acquisition unit is used to query the instance of the strategy class corresponding to the target annotation name from the second global variable, the second global variable includes a key-value pair, the primary key is the result returned by the instance acquisition annotation class name method, and the value corresponding to the primary key is the instance of the strategy class.
[0041] In a possible implementation manner, the device further includes:
[0042] The integration unit is used to make the strategy class defining the verification parameter method dependent on the ValidationUtil tool class.
[0043] In a possible implementation, the instance of the strategy class is created in the ValidationUtil tool class, and the instance of the strategy class is created in the following way:
[0044] Use Reflections to scan the specified package path and find the implementation class that implements the public interface; the public interface is pre-defined in the public component library, and the public interface declares a method for obtaining the annotation name and a method for implementing the annotation function;
[0045] Get an instance of the implementation class from the Spring container;
[0046] If the instance of the implementation class cannot be obtained from the Spring container, an instance is created through the reflection mechanism; the instance of the implementation class is encapsulated into the second global variable, and the annotated class name of the implementation class is encapsulated into the first global variable.
[0047] In a possible implementation manner, the device further includes:
[0048] The first creation unit is used to create a custom annotation class in the project;
[0049] A second creation unit is used to create an implementation class in the project to implement the public interface;
[0050] A first rewriting unit is used to rewrite the method for obtaining the annotation class name of the public interface in the implementation class, and return the custom annotation class name in the method for obtaining the annotation class name;
[0051] The second rewriting unit is used to rewrite the verification method of the public interface in the implementation class.
[0052] In a possible implementation, the target field corresponds to multiple annotations, and the multiple annotations respectively correspond to a custom annotation class.
[0053] In a third aspect, the present application provides a device, including: a processor, a memory, and a system bus;
[0054] The processor and the memory are connected via the system bus;
[0055] The memory is used to store one or more programs, and the one or more programs include instructions. When the instructions are executed by the processor, the processor executes the method described in any embodiment of the first aspect.
[0056] In a fourth aspect, the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium. When the instructions are executed on a terminal device, the terminal device executes the method described in any implementation of the first aspect above.
[0057] It can be seen that this application has the following beneficial effects:
[0058] The present application provides a verification method and device, in which a verification parameter method is defined in a strategy class, the verification parameter method includes method parameters, the method parameters include an object to be verified, a field of the object to be verified, and a first group list of verification, the object to be verified is a request message body, and the first group list includes verification rules; the annotation of the target field is obtained by a reflection method, and the name of the annotation of the target field is compared with the annotation class name maintained by a first global variable, and the target field is any field in the field of the object to be verified; if the target annotation class name is hit, the second group list corresponding to the target annotation class name is obtained; if the first group list and the second group list have an intersection, and it is determined that the field value of the target field is not empty, according to the target annotation class name, the corresponding instance of the strategy class is obtained; the verification method is called by the instance to verify the target field. In this way, the request message body field level verification can be realized based on the custom annotation created by the framework constructed by reflection and strategy mode, which is conducive to realizing personalized verification and meeting the needs of flexible verification. BRIEF DESCRIPTION OF THE DRAWINGS
[0059] Figure 1 A schematic diagram of a flow chart of a verification method provided in an embodiment of the present application;
[0060] Figure 2 A flowchart of a framework for building a reflection and strategy mode provided in an embodiment of the present application;
[0061] Figure 3 A schematic diagram of a process for constructing a custom annotation class provided in an embodiment of the present application;
[0062] Figure 4 A schematic diagram of a framework design provided for an embodiment of the present application;
[0063] Figure 5A schematic diagram of the structure of a verification device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0064] In order to facilitate the understanding and explanation of the technical solutions provided by the embodiments of the present application, the background technology of the present application will be described below.
[0065] The browser or mobile terminal transmits data with the backend server through request messages. To avoid illegal parameters in the request message and affect the normal business processing logic, the backend server performs interface verification at the controller layer. Interface verification verifies the correctness and legality of the request parameters input on the Internet to ensure the security and stability of the system. The method of performing parameter verification of request parameters at the controller layer is too invasive to the business logic. At present, mainstream SpringBoot applications use annotations to perform parameter verification on the fields in the value object (VO) in the form of annotations based on the application programming interface (API) provided by the Spring Validation validation framework. The Validation validation rule set covers common validation rules, such as @NotNull, @Size, @Pattern, @NotEmpty, @Max, @Min, and @Length, to implement legal verification at the request message body field level. In this way, parameter verification can be separated from business logic and the invasiveness of parameter verification on business logic can be reduced. However, the validation rule set provides limited validation rules, which is difficult to meet the needs of parameter verification in more abundant business functions.
[0066] The Validation API provides basic validation rules. Developers can add custom validation rules. When adding custom annotations, it is necessary to continuously add branch judgments in the ValidationUtil tool class, which leads to a sharp increase in code complexity.
[0067] Whenever a custom annotation is added, the checkParam method body needs to be modified and expanded, a judgment branch needs to be added, and the function of the custom annotation needs to be implemented. Adding new custom annotations requires many changes to the original core code. Adding multiple validation rules will cause the ValidationUtil tool class code to be bloated, increase the amount of code written in the core public component library and the subsequent maintenance cost. In addition, the validation rule sets are highly coupled, cannot be flexibly loaded and used, cannot meet the needs of adding various custom validation rules, and cannot meet the needs of rule validation for characteristic business scenarios.
[0068] Based on this, the embodiment of the present application provides a verification method, which defines a verification parameter method in a strategy class, and the verification parameter method includes method parameters, and the method parameters include an object to be verified, a field of the object to be verified, and a first group list of verification, the object to be verified is a request message body, and the first group list includes verification rules; the annotation of the target field is obtained by a reflection method, and the name of the annotation of the target field is compared with the annotation class name maintained by the first global variable, and the target field is any field in the field of the object to be verified; if the target annotation class name is hit, the second group list corresponding to the target annotation class name is obtained; if the first group list and the second group list have an intersection, and it is determined that the field value of the target field is not empty, according to the target annotation class name, the instance of the corresponding strategy class is obtained; the target field is verified by calling the verification method through the instance. In this way, the request message body field-level verification can be realized based on the custom annotation created by the framework constructed by reflection and strategy mode, which is conducive to realizing personalized verification and meeting the needs of flexible verification.
[0069] In order to facilitate understanding of the technical solution provided by the embodiment of the present application, the verification method provided by the embodiment of the present application is described below with reference to the accompanying drawings.
[0070] See also Figure 1 As shown, this figure is a schematic diagram of the flow of the verification method provided in the embodiment of the present application. The verification method includes S101-S105:
[0071] S101: define a verification parameter method in a policy class, the verification parameter method includes method parameters, the method parameters include an object to be verified, a field of the object to be verified, and a first group list for verification, the object to be verified is a request message body, and the first group list includes verification rules.
[0072] The verification method provided in the embodiment of the present application is to create custom annotations based on a framework constructed based on reflection and strategy patterns to implement verification of the fields of the request message body.
[0073] To facilitate understanding, the following first introduces the framework of reflection and strategy pattern construction.
[0074] See also Figure 2 As shown, the figure is a flow chart of a framework for building a reflection and strategy mode provided in an embodiment of the present application.
[0075] A1: Define a public interface IValidationChecker in the public component library. The IValidationChecker interface declares a method to obtain the annotation class name and a method to implement the specific function of the annotation. The IValidationChecker interface is used to provide each module microservice project with its specific method. Microservice projects refer to applications that are decomposed into small and autonomous service units. Each microservice can be developed and deployed independently, thereby achieving horizontal expansion of services.
[0076] The specific implementation code is:
[0077] public interface IValidationChecker{
[0078] String getCheckerName();
[0079] void check(Annotation annotation,Object value,String errorMsg);
[0080] }
[0081] A2: Define a ValidationStrategy strategy class and create an instance of the strategy class in the ValidationUtil tool class to ensure that the construction method of the strategy class instance is executed when the system is initialized.
[0082] The constructor is used to create an instance of the strategy class. Specifically, it includes the following steps:
[0083] A3: Use Reflections to scan the specified package path and obtain the implementation class of the IValidationChecker interface under the package path.
[0084] The details are as follows:
[0085] Reflections reflections=new Reflections("com.abchina.itseb.base.*","com.abchina.itseb.*");
[0086] Set <Class<?extends IValidationChecker> >monitorClasses=reflections.getSubTypesOf(IValidationChecker.class);
[0087] A4: Get an instance of the implementation class from the Spring container.
[0088] First, use getBean to obtain the instance managed in the Spring Ioc container. Since some specific annotations need to be introduced into the Service layer for verification, this approach is to support their inclusion in the Spring Ioc container using the @Autowired method.
[0089] A5: If you cannot obtain an instance of the implementation class from the Spring container, create an instance through the reflection mechanism.
[0090] The details are as follows:
[0091] try{
[0092] checker=SpringUtil.getBean(monitor);
[0093] }catch(Exception e){
[0094] }
[0095] if (checker == null) {
[0096] checker=monitor.newInstance();
[0097] }
[0098] A6: Encapsulate the instance of the implementation class into the second global variable, and encapsulate the annotation class name of the implementation class into the first global variable.
[0099] The obtained instance is encapsulated into a second global variable. The second global variable is, for example, a Map. The key value of the second global variable is the result returned by the instance acquisition annotation class name method. The value of the second global variable is the instance.
[0100] All annotation class names are encapsulated into the first global variable. The first global variable is, for example, List. When the system is initialized, all annotation implementation classes are maintained in the List.
[0101] The specific implementation method is as follows:
[0102] String checkerName=checker.getCheckerName();
[0103] checkerMap.put(checkerName,checker);
[0104] checkerNames.add(checkerName);
[0105] In the above way, when the system starts, the entity object with custom annotations will be managed in the Spring container so that it can be called during subsequent verification.
[0106] By using the strategy pattern to decouple the implementation of custom annotation functions, each additional custom annotation function will not affect the existing functions, and horizontal expansion can be achieved. The reflection method provided by Reflections is used to automatically obtain the function implementation class of each annotation. When expanding the functions of custom annotations, there is no need to change the core code. You only need to add a custom annotation class, add a corresponding function implementation class, and return the annotation class name in the function implementation class.
[0107] The framework constructed based on the above reflection and strategy patterns can realize the verification of the fields of the request message body.
[0108] Define the check parameter method in the strategy class. As an example, define the checkParam method in the strategy class.
[0109] The verification parameter method includes method parameters, and the method parameters include the object to be verified, the field of the object to be verified, and the first group list of verification. Among them, the object to be verified is a request message body. The request message body is, for example, a request message body of a front-end HTTP request access. The first group list includes verification rules.
[0110] S102: Obtain the annotation of the target field through a reflection method, and compare the name of the annotation of the target field with the annotation class name maintained by the first global variable.
[0111] The target field is any field in the object to be checked.
[0112] Specifically, the annotation of the target field of the object to be verified is obtained through the reflection method provided by the Feild class. Annotation: Annotation is used to declare in front of classes, methods, fields, etc. for runtime compilation and parsing. Annotations can be customized through @interface. The reflection method is, for example, getAnnotation.
[0113] Write the target field's annotations into the annotations array.
[0114] Traverse the annotation array and search for the target annotation class name that is the same as the annotation class name included in the first global variable. By traversing the annotation array and comparing it with the annotation class name maintained in the List, determine whether the custom annotation is hit.
[0115] The specific implementation code is as follows:
[0116] Annotation[]annotations=field.getAnnotations();
[0117] for(Annotation annotation:annotations){ / / Traverse all annotations on the fields of the request message body (OV entity)
[0118] String className = annotation.annotationType().getName(); / / Get the annotation name
[0119] if(checkerNames.contains(className)){ / / Whether the match hits the custom annotation
[0120] ...... / / Execute verification
[0121] }
[0122] }
[0123] S103: If the target annotation class name is hit, obtain a second group list corresponding to the target annotation class name.
[0124] The second grouping list corresponding to the target annotation class name is a predefined grouping list including verification rules.
[0125] S104: If the first grouping list and the second grouping list have an intersection, and it is determined that the field value of the target field is not empty, an instance of the corresponding policy class is obtained according to the target annotation class name.
[0126] The first grouping list and the second grouping list have an intersection, indicating that there is a validation rule that needs to be executed. Determine whether the field value of the target field is empty. If the field value of the target field is empty, it can be determined that there is a problem with the target field without using a validation method.
[0127] If the field value of the target field is not empty, it is determined that verification is required. According to the target annotation class name, an instance of the corresponding strategy class is obtained.
[0128] Taking the above constructed framework as an example, the instance of the strategy class corresponding to the target annotation name is queried from the second global variable (Map).
[0129] S105: Verify the target field by calling the verification method through the instance.
[0130] Call the check method to perform verification.
[0131] The specific implementation code is as follows:
[0132] IValidationChecker validationCheck=checkerMap.get(className);
[0133] validationCheck.check(annotation,value,errorMsg);
[0134] In addition, the strategy class that defines the validation parameter method is dependent on the ValidationUtil tool class for subsequent calls. Specifically, the strategy class can be dependent on the ValidationUtil tool class in a combined manner.
[0135] Based on the above verification method, it can be known that the framework based on reflection and strategy pattern provided by the embodiment of the present application can expand the system's own interface verification rule set, support the system to customize the rule set according to business characteristics, support the request entity class to flexibly load or unload the verification rule set, and combine different verification rule sets. Each verification rule is decoupled and has no mutual dependence. Adding each verification rule is to add a strategy class, following the open and closed principle.
[0136] Furthermore, after building an annotation framework that supports horizontal expansion in the Base public component library, each module microservice project introduces the dependency of the Base public component library and completes the creation of custom annotations by implementing the IValidationChecker interface and Override methods exposed by the Base public component library.
[0137] The following describes the process of building a custom annotation class. Figure 3 As shown, Figure 3 A schematic diagram of a process for constructing a custom annotation class provided in an embodiment of the present application;
[0138] The following steps are involved:
[0139] B1: Create a custom annotation class in the project.
[0140] As an example, create an Annotation custom annotation class in a microservice project and define fields such as grouping and error description.
[0141] The implementation code is as follows:
[0142] @Target({ElementType.FIELD})
[0143] @Retention(RetentionPolicy.RUNTIME)
[0144] public@interface Annotation1{ ......
[0146] }
[0147] B2: Create an implementation class in the project to implement the public interface.
[0148] B3: Rewrite the public interface's method for getting the annotation class name in the implementation class and return the custom annotation class name in the method for getting the annotation class name.
[0149] The annotation class name method is, for example, the getCheckName method.
[0150] B4: Override the verification method of the public interface in the implementation class.
[0151] By rewriting the verification method, personalized verification rules can be implemented, which facilitates the flexible expansion of verification rules based on business needs.
[0152] As an example, override the check method of the interface in the implementation class to implement specific feature verification rules.
[0153] The implementation code is as follows:
[0154] public class ValidatorChecker1 implements IValidationChecker{
[0155] @Override
[0156] public String getCheckerName(){
[0157] return Annotation1.class.getName();
[0158] }
[0159] @Override
[0160] public void check(Annotation annotation,Object value,String errorMsg){ ......
[0162] }
[0163] }
[0164] It should be noted that custom annotations can be used in combination with other annotations. As an example, the target field corresponds to multiple annotations. Multiple annotations correspond to a custom annotation class. During verification, the target field needs to satisfy the custom annotation class corresponding to multiple annotations.
[0165] As an example, the feild1 field in the VO entity must meet the validation rules of the custom rule sets of Annotation1 and Annotation2 at the same time. If the validation rules are not met, the corresponding message prompt is returned.
[0166] The implementation code is as follows:
[0167] @Annotation1(message = "Verification Tip 1", groups = {GroupA.class})
[0168] @Annotation2(message = "Verification Tip 2", groups = {GroupB.class})
[0169] private String feild1; / / Field 1
[0170] @Annotation3(regexp="",message="Verification Tip 3",groups="GroupA.class})
[0171] private String feild2; / / Field 2
[0172] Specifically, at the control layer, the validate() method in the ValidationUtil tool class is used to implement field-level custom validation of the message request body.
[0173] ValidationUtil.validate(request,GroupA.class); / / The control layer uses the validation rule set
[0174] See also Figure 4 As shown, this figure is a schematic diagram of a framework design provided in an embodiment of the present application.
[0175] Among them, ValidationUtil (tool class): contains a member variable strategy of ValidationStrategy type, which is used to store strategies.
[0176] ValidationStrategy (strategy class): The strategy class contains a global variable checkerMap of type Map, the key value is the result returned by the instance get annotation class name method, and the value is the specific instance object. The strategy class also contains a check parameter method checkParam, which is used to check parameters.
[0177] IValidationChecker (validator interface): a public interface that defines two methods: getCheckerName(): returns the name of the validator, the return type is String; check(): executes the validation logic.
[0178] ValidationChecker1, ValidationChecker2, ValidationChecker3 (concrete implementation class): implements the IValidationChecker interface, and each class provides specific getCheckerName() and check() method implementations. Each implementation class is associated with an annotation for specific validation logic.
[0179] Annotation1, Annotation2, Annotation3 (annotation): custom annotations, each annotation is associated with an implementation class and is used to mark the fields that need to be verified.
[0180] Based on the above content, we can know that the ValidationUtil tool class, ValidationStrategy strategy class, and IValidationChecker interface are all encapsulated in the Base public component library, hiding their internal details from external microservice projects, and only exposing the IValidationChecker interface for implementation and expansion. When an external microservice module needs to create a custom annotation class, there is no need to change the Base public component library. You only need to create a specific ValidationChecker implementation class and the corresponding Annotation annotation class. And each new custom annotation class is a new strategy. The new custom annotation is decoupled from the original annotation and has no intrusion on the original Base public component library, which meets the needs of horizontal expansion of custom annotations and can flexibly expand and scale custom annotations. In this way, it can adapt to personalized validation rule sets such as loading unauthorized and parameter legitimacy, thereby improving the security and stability of backend services.
[0181] Based on a verification method provided in the above method embodiment, the embodiment of the present application also provides a verification device, which will be described below in conjunction with the accompanying drawings.
[0182] See also Figure 5As shown in FIG. 1 , this figure is a schematic diagram of the structure of a verification device provided in an embodiment of the present application. Figure 5 As shown, the verification device comprises:
[0183] A definition unit 501 is used to define a verification parameter method in a policy class, wherein the verification parameter method includes method parameters, wherein the method parameters include an object to be verified, a field of the object to be verified, and a first group list for verification, wherein the object to be verified is a request message body, and the first group list includes verification rules;
[0184] A first acquisition unit 502 is used to acquire the annotation of the target field by a reflection method, and match the name of the annotation of the target field with the annotation class name maintained by the first global variable, wherein the target field is any field of the field of the object to be verified;
[0185] The second acquisition unit 503 is used to acquire a second group list corresponding to the target annotation class name if the target annotation class name is hit;
[0186] A third acquisition unit 504 is configured to acquire an instance of the corresponding policy class according to the target annotation class name if the first grouping list and the second grouping list have an intersection and it is determined that the field value of the target field is not empty;
[0187] The verification unit 505 is used to verify the target field by calling the verification method through the instance.
[0188] In a possible implementation, the first acquisition unit is used to match the name of the annotation of the target field with the annotation class name maintained by the first global variable, including:
[0189] The first acquisition unit is used to obtain the annotation of the target field of the object to be verified through the reflection method provided by the Feild class; write the annotation of the target field into the annotation array; traverse the annotation array to query the target annotation class name that is the same as the annotation class name included in the first global variable.
[0190] In a possible implementation, the third acquisition unit is used to acquire the corresponding instance of the strategy class according to the target annotation class name, including:
[0191] The third acquisition unit is used to query the instance of the strategy class corresponding to the target annotation name from the second global variable, the second global variable includes a key-value pair, the primary key is the result returned by the instance acquisition annotation class name method, and the value corresponding to the primary key is the instance of the strategy class.
[0192] In a possible implementation manner, the device further includes:
[0193] The integration unit is used to make the strategy class defining the verification parameter method dependent on the ValidationUtil tool class.
[0194] In a possible implementation, the instance of the strategy class is created in the ValidationUtil tool class, and the instance of the strategy class is created in the following way:
[0195] Use Reflections to scan the specified package path and find the implementation class that implements the public interface; the public interface is pre-defined in the public component library, and the public interface declares a method for obtaining the annotation name and a method for implementing the annotation function;
[0196] Get an instance of the implementation class from the Spring container;
[0197] If the instance of the implementation class cannot be obtained from the Spring container, an instance is created through the reflection mechanism; the instance of the implementation class is encapsulated into the second global variable, and the annotated class name of the implementation class is encapsulated into the first global variable.
[0198] In a possible implementation manner, the device further includes:
[0199] The first creation unit is used to create a custom annotation class in the project;
[0200] A second creation unit is used to create an implementation class in the project to implement the public interface;
[0201] A first rewriting unit is used to rewrite the method for obtaining the annotation class name of the public interface in the implementation class, and return the custom annotation class name in the method for obtaining the annotation class name;
[0202] The second rewriting unit is used to rewrite the verification method of the public interface in the implementation class.
[0203] In a possible implementation, the target field corresponds to multiple annotations, and the multiple annotations respectively correspond to a custom annotation class.
[0204] Based on a verification method provided by the above method embodiment, the present application provides a verification device, including: a processor, a memory, and a system bus;
[0205] The processor and the memory are connected via the system bus;
[0206] The memory is used to store one or more programs, and the one or more programs include instructions. When the instructions are executed by the processor, the processor executes the verification method described in any of the above embodiments.
[0207] Based on a verification method provided by the above method embodiments, the present application provides a computer-readable storage medium, in which instructions are stored. When the instructions are executed on a terminal device, the terminal device executes the verification method described in any of the above embodiments.
[0208] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the system or device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.
[0209] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.
[0210] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.
[0211] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
[0212] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A verification method, characterized in that: The method comprises: A verification parameter method is defined in the policy class, wherein the verification parameter method includes method parameters, wherein the method parameters include an object to be verified, a field of the object to be verified, and a first group list for verification, wherein the object to be verified is a request message body, and the first group list includes verification rules; Obtain the annotation of the target field through a reflection method, and compare the name of the annotation of the target field with the annotation class name maintained by the first global variable, wherein the target field is any field of the field of the object to be verified; If the target annotation class name is hit, obtain a second group list corresponding to the target annotation class name; If the first grouping list and the second grouping list have an intersection, and it is determined that the field value of the target field is not empty, obtaining the corresponding instance of the policy class according to the target annotation class name; The target field is verified by calling a verification method through the instance.
2. The method according to claim 1, characterized in that The comparing the name of the annotation of the target field with the annotation class name maintained by the first global variable includes: Obtain the annotation of the target field of the object to be verified through the reflection method provided by the Feild class; Write the annotation of the target field into the annotation array; The annotation array is traversed to search for a target annotation class name that is the same as the annotation class name included in the first global variable.
3. The method according to claim 1, characterized in that The step of obtaining an instance of a strategy class according to the target annotation class name includes: An instance of a policy class corresponding to the target annotation name is queried from a second global variable, wherein the second global variable includes a key-value pair, wherein the primary key is the result returned by the method for obtaining the annotation class name of the instance, and the value corresponding to the primary key is the instance of the policy class.
4. The method according to claim 1, characterized in that: The method further comprises: The strategy class that defines the verification parameter method is dependent on the ValidationUtil tool class.
5. The method according to claim 1, characterized in that The instance of the strategy class is created in the ValidationUtil tool class. The instance of the strategy class is created in the following way: Use Reflections to scan the specified package path and find the implementation class that implements the public interface; the public interface is pre-defined in the public component library, and the public interface declares a method for obtaining the annotation name and a method for implementing the annotation function; Get an instance of the implementation class from the Spring container; If the instance of the implementation class cannot be obtained from the Spring container, an instance is created through the reflection mechanism; the instance of the implementation class is encapsulated into the second global variable, and the annotated class name of the implementation class is encapsulated into the first global variable.
6. The method according to claim 5, characterized in that The method further comprises: Create a custom annotation class in the project; Creating an implementation class in the project to implement the public interface; Rewrite the method for obtaining the annotation class name of the public interface in the implementation class, and return the custom annotation class name in the method for obtaining the annotation class name; Rewrite the verification method of the public interface in the implementation class.
7. The method according to claim 6, characterized in that The target field corresponds to multiple annotations, and the multiple annotations respectively correspond to a custom annotation class.
8. A verification device, characterized in that: The device comprises: A definition unit, configured to define a verification parameter method in a policy class, wherein the verification parameter method includes method parameters, wherein the method parameters include an object to be verified, a field of the object to be verified, and a first group list for verification, wherein the object to be verified is a request message body, and the first group list includes verification rules; A first acquisition unit is used to acquire the annotation of the target field by a reflection method, and match the name of the annotation of the target field with the annotation class name maintained by the first global variable, wherein the target field is any field of the field of the object to be verified; A second acquisition unit is used to acquire a second group list corresponding to the target annotation class name if the target annotation class name is hit; A third acquisition unit is used to acquire the corresponding instance of the policy class according to the target annotation class name if the first grouping list and the second grouping list have an intersection and it is determined that the field value of the target field is not empty; A verification unit is used to verify the target field by calling a verification method through the instance.
9. A device, characterized in that: include: Processor, memory, system bus; The processor and the memory are connected via the system bus; The memory is used to store one or more programs, wherein the one or more programs include instructions, and when the instructions are executed by the processor, the processor executes the method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a terminal device, the terminal device executes the method according to any one of claims 1 to 7.