Verification method and device and computer equipment

Abstract

The invention discloses a verification method and device and computer equipment, and the method comprises the steps: creating a verification class for a detection interface of a component, and creating a verification instance used for achieving the verification class; and then, assembling the verification instance to obtain a verification chain corresponding to the detection interface. And finally, when a verification request for the target detection interface is received, matching a target verification chain corresponding to the target interface from the verification chains, and performing security verification on the verification request through the target verification chain. According to the method and the device, the flexibility, expansibility and stability of checking the request can be improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a verification method, device and computer equipment. Background Art

[0002] Nowadays, Web applications usually use frameworks such as Spring Security for security verification, and implement authentication, authorization and other security checks on HTTP requests through custom filters. This method allows developers to perform necessary security verification on requests before executing business logic, such as IP verification, user permission verification, etc.

[0003] However, the above method requires more complex configuration, especially when the verification logic needs to be customized for different interfaces, a large number of filters need to be defined, which increases the difficulty of system maintenance. At the same time, the verification logic is tightly coupled with the code, and when business requirements change, the code often needs to be modified, which increases the risk and instability of the system. Summary of the invention

[0004] In order to solve the above technical problems, the embodiments of the present application provide a verification method, an apparatus and a computer device.

[0005] In a first aspect, an embodiment of the present application provides a verification method, the method comprising:

[0006] Create a verification class for the detection interface of the component, and create a verification instance for implementing the verification class;

[0007] Assembling the verification instances to obtain a verification chain corresponding to the detection interface;

[0008] Receiving a verification request for a target detection interface;

[0009] A target verification chain corresponding to the target interface is matched from the verification chain, and a security verification is performed on the verification request through the target verification chain.

[0010] In a second aspect, an embodiment of the present application provides a verification device, the device comprising:

[0011] An interface definition module, used to create a verification class for a detection interface of a component, and to create a verification instance for implementing the verification class;

[0012] A verification chain assembly module, used to assemble the verification instance to obtain a verification chain corresponding to the detection interface;

[0013] A request receiving module, used to receive a verification request for a target detection interface;

[0014] The request verification module is used to match the target verification chain corresponding to the target interface from the verification chain, and perform security verification on the verification request through the target verification chain.

[0015] In a third aspect, an embodiment of the present application further provides a computer device, including a memory storing a plurality of instructions; a processor loads instructions from the memory to execute the steps of any verification method provided in the embodiment of the present application.

[0016] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores a plurality of instructions, and the instructions are suitable for a processor to load to execute the steps of any verification method provided in the embodiment of the present application.

[0017] In a fifth aspect, an embodiment of the present application further provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the steps of any one of the verification methods provided in the embodiments of the present application.

[0018] By adopting the solution of the embodiment of the present application, a verification class is first created for the detection interface of the component, and a verification instance for implementing the verification class is created. The verification instance is then assembled to obtain a verification chain corresponding to the detection interface. Finally, when a verification request for the target detection interface is received, the target verification chain corresponding to the target interface is matched from the verification chain, and the verification request is security verified through the target verification chain.

[0019] In this way, since the check chain is assembled from the check instances that implement the check class, the security check rules and execution order of each interface can be dynamically defined based on the check instances contained in each check chain and the corresponding assembly order. There is no need to customize exclusive check logic and a large number of filters for each interface, thereby improving the flexibility and scalability of request verification. Accordingly, if the security check rules or execution order of the interface need to be changed later, there is no need to modify the code, only the check instances contained in the check chain or the assembly order of each check instance need to be adjusted, thereby reducing code coupling, reducing the risk of errors in check changes, and improving the stability of security verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 It is a schematic diagram of the application environment of the verification method provided in the embodiment of the present application;

[0022] Figure 2 It is a flowchart of the verification method provided in the embodiment of the present application;

[0023] Figure 3 It is a schematic diagram of the process of assembling a verification chain provided in an embodiment of the present application;

[0024] Figure 4 It is a flowchart of determining the execution order of the verification instance provided in the embodiment of the present application;

[0025] Figure 5 is a schematic diagram of a configuration file provided in an embodiment of the present application;

[0026] Figure 6 is a schematic diagram of a calibration factory provided in an embodiment of the present application;

[0027] Figure 7 is a schematic diagram of a verification chain provided in an embodiment of the present application;

[0028] Figure 8 It is a schematic diagram of adjusting the check chain after updating the check strategy provided in an embodiment of the present application;

[0029] Fig. 9 is a schematic diagram of a verification device provided in an embodiment of the present application;

[0030] Fig.10 It is a schematic diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application. At the same time, in the description of the embodiments of the present application, the terms "first", "second", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more features. In the description of the embodiments of the present application, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.

[0032] In one embodiment of the present application, the verification method can be run on a local terminal device or a server. When the verification method is run on a server, the method can be implemented and executed based on a data analysis system, wherein the data analysis system includes a server and a client device.

[0033] In order to better understand a verification method, device, electronic device and storage medium provided in the embodiments of the present application, the application environment applicable to the embodiments of the present application is first described below.

[0034] See also Figure 1 , Figure 1 FIG. 1 is a schematic diagram showing an application environment of a verification method provided by an embodiment of the present application. As an implementation mode, the verification method provided by an embodiment of the present application can be applied to an electronic device. The electronic device can be Figure 1 The server 110 shown in the figure can communicate with the terminal device 120 through a network. The network is a medium for providing a communication link between the server 110 and the terminal device 120. The network can include various connection types, such as wired communication links, wireless communication links, etc., which are not limited in the embodiments of the present application. Optionally, in other embodiments, the electronic device can also be a smart phone, a laptop computer, etc.

[0035] It should be understood that Figure 1 The server 110, network and terminal device 120 are merely illustrative, and any number of servers, networks and terminal devices may be provided as required. For example, the server 110 may be a physical server or a server cluster composed of multiple servers, and the terminal device 120 may be a mobile phone, a tablet, a desktop computer, a laptop computer, and the like. It is understood that the embodiments of the present application may also allow multiple terminal devices 120 to access the server 110 at the same time.

[0036] In some embodiments, the terminal device 120 may obtain a verification request for the target detection interface. Further, the terminal device 120 may send a verification request for the target detection interface to the server 110 through the network. After the server 110 receives the above verification request, it may match the target verification chain corresponding to the target interface from the verification chain, and perform security verification on the verification request through the target verification chain.

[0037] The following is a detailed description in conjunction with the accompanying drawings. In this embodiment, the execution subject is a terminal device as an example. It should be noted that the description order of the following embodiments is not intended to limit the preferred order of the embodiments. Although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in an order different from that shown in the accompanying drawings.

[0038] The verification method of this embodiment can be applied to any scenario that needs to be executed, and the method can be applied to products in these scenarios, such as request verification systems, network security protection systems, etc.

[0039] In current Web application development, ensuring the security of requests is an important part of system design. Existing security frameworks (such as Spring Security) are widely used in Web applications, providing a range of security features, including authentication, authorization, and session management. Developers can customize filters in Spring Security to intercept and verify requests, thereby implementing some common security verification functions, such as IP verification and user permission verification. Through these filters, developers can perform a certain degree of security checks on HTTP requests before executing business logic to ensure the security of the system.

[0040] However, the existing security framework has certain limitations when facing complex and changing business needs. First, the configuration of Spring Security is relatively complex, especially when it is necessary to customize the security verification logic for different interfaces. Developers often need to define a large number of filters and manually specify their execution order and scope. As the scale of the system expands, this configuration method can easily become cumbersome and difficult to maintain. Secondly, when business needs change, modifying the security verification logic usually requires direct adjustment of the code, which not only increases the risk of the system, but may also cause instability in the online environment. In addition, the existing security verification mechanism is often highly coupled with the business code, which increases the complexity of the code and is not conducive to the expansion and maintenance of the system.

[0041] Based on this, in order to solve the problems of low efficiency and poor accuracy in existing business data analysis, the verification method, device and computer equipment of the present application are proposed.

[0042] Please refer to Figure 2 The specific process of the verification method provided in the embodiment of the present application may include the following steps 201 to 204, which are specifically introduced below.

[0043] Step 201: Create a verification class for the detection interface of the component, and create a verification instance for implementing the verification class.

[0044] The detection interface can be used to define the basic interface that the checker must implement, to standardize the core functions and behaviors of each checker, and to ensure that different checkers can be managed and called in a unified manner. The checker of this application can be represented by "checker", and checker can also represent the check strategy and rules corresponding to the checker.

[0045] As an example, the pseudo code of the detection interface can be expressed as:

[0046] public interface Checker {

[0047] CheckResult check(HttpServletRequest request,HttpServletResponseresponse);

[0048] }.

[0049] Taking the detection interface as an example, it is defined that the HTTP service request can be verified and the corresponding response information can be returned. For example, the response information can be the verification result of the HTTP service request.

[0050] It can be understood that the verifier of the detection interface can implement the check method, and a unified operation specification can be provided for each verifier, so that the system can call different types of verifiers in the same way. The specific verification class can implement different security verification logics according to needs, such as IP address verification, version number verification, etc., and its specific verification logic can be executed by creating a custom verification method for the verification class.

[0051] The verification class can also be called the verifier class, which refers to the specific class that implements the detection interface and is responsible for executing specific security verification logic. Each verification class represents an independent verifier that handles a certain aspect of security checks, such as IP verification, version verification, etc. Through these verification classes, the system can flexibly perform various forms of security verification on different HTTP requests.

[0052] The verification class is the implementation class of the detection interface, which defines various security verification operations through specific detection methods. Different verification classes can handle different types of verification tasks, such as verifying whether the requested IP address is legal, verifying the user's login status, or detecting whether the client version meets the requirements.

[0053] As an example only, the pseudo code of the IP verifier for implementing IP verification can be expressed as:

[0054]

[0055] Just as an example, the code of the version checker for implementing version checking can be expressed as:

[0056]

[0057]

[0058] In some embodiments, a validation class may be created by:

[0059] First, obtain the verification logic of the predefined detection interface;

[0060] Next, add the corresponding identifier to the verification logic to obtain the verification class.

[0061] In some embodiments, the verification logic of the predefined detection interface may be obtained first, and the verification logic may be added to the verification class as a verification method for subsequent implementation of the verification operation of the detection interface on the request.

[0062] In some embodiments, a verification logic may be added to the "custom verification logic" part of the pseudo code of the aforementioned IP verifier to implement the corresponding verification function. As an example only, a verification logic of "verifying whether the requested IP is in the allowed IP list" may be added. The exemplary pseudo code of the verifier after adding the verification logic may be expressed as:

[0063]

[0064]

[0065] After obtaining the requested IP address, the validator creates a list of allowed IP addresses through Arrays.asList(). For example, the allowed IPs are 192.168.0.1 and 10.0.0.1. The verification logic is: "If the requested IP address is in the allowed IP list, PASS is returned, indicating that the verification passed and the request is allowed to continue; if the requested IP address is not in the allowed list, REJECT is returned, indicating that the verification failed and the request is rejected."

[0066] In some embodiments, a corresponding identifier can be added to the verification logic to obtain a verification class, wherein the identifier can be a custom annotation of the verification class, used to mark and manage the specific verification class, and then the system dynamically loads the verification class with the identifier through the reflection mechanism when starting.

[0067] In some embodiments, the annotation can be represented by CheckerAnnotation, and each annotation can include a name attribute for assigning a unique name to the check class. For example, the annotation of the check class of the IP checker can be: @CheckerAnnotation(name="ipChecker"), and the annotation of the check class of the version checker can be: @CheckerAnnotation(name="versionChecker").

[0068] In some embodiments, a validation instance may be created by:

[0069] First, obtain and dynamically load the validation class with the identifier to obtain the validation instance corresponding to the validation class;

[0070] Next, the verification instance is registered to the verification factory, and the verification class and the verification instance are associated and stored in the verification factory.

[0071] In some embodiments, a reflection library (such as Reflections) can be used to scan a specified package path (basePackage) to obtain all check classes that inherit the abstract check class AbstractChecker under the path to implement the check logic of the detection interface. The exemplary related pseudo code is as follows:

[0072] / / Scan all classes under the specified package path

[0073] Reflections reflections=new Reflections(basePackage);

[0074] / / Get all classes that inherit AbstractChecker

[0075] Set <Class<?extends AbstractChecker> >classSet=reflections.getSubTypesOf(AbstractChecker.class).

[0076] Among them, the Reflections class of the reflection library is used to scan the specified package path at runtime to find all the validation classes that meet the conditions and inherit the sampling object class. classSet is a collection that contains all the validation classes found in the specified package path.

[0077] In some embodiments, when all qualified check classes are found, the above check classes can be traversed and instantiated through the reflection mechanism. The reflection mechanism allows objects to be created dynamically when the program is running without determining the class at compile time. The pseudo code of this process can be expressed as:

[0078]

[0079] Among them, clazz.newInstance() is a method of the reflection mechanism, which can dynamically create an instance object of a class according to the definition of the verification class. Through this method, each verification class can be instantiated into a specific verification object, that is, a verification instance, and each verification instance is equivalent to a verifier. Through the reflection mechanism, the system can dynamically load the above qualified verification classes at runtime without having to obtain in advance which specific verification classes meet the verification requirements.

[0080] In some embodiments, after instantiation of the checker class is completed, the system can detect whether each checker class has the annotation @CheckerAnnotation. If a checker class is not annotated, an exception can be thrown to prompt the developer that the checker is incorrectly configured. The relevant pseudo code is as follows:

[0081]

[0082] Among them, clazz.getAnnotation(CheckerAnnotation.class) refers to obtaining the annotation @CheckerAnnotation marked on the class through reflection. If the checker class is not marked with an annotation, the class cannot be correctly identified and used, so an exception is thrown and an error log is recorded.

[0083] In some embodiments, the name of the checker can be extracted from the annotation @CheckerAnnotation, which is the unique identifier of the checker and will be used as the basis for finding the checker instance in the subsequent check chain assembly and execution. The relevant pseudo code can be expressed as:

[0084] String value = annotation.name(); / / Get the name in the annotation.

[0085] Among them, annotation.name() is the name attribute contained in the annotation @CheckerAnnotation. This method can be used to extract the name of the checker (such as ipChecker of the IP checker or versionChecker of the version checker) as the unique identifier of the checker.

[0086] Among them, the verification factory is a storage space used to centrally store all verification instances. When the system is running, it can quickly find and obtain the corresponding verifier. The corresponding pseudo code can be expressed as:

[0087] checkerFactory.addChecker(value,obj); / / Register to the checker factory.

[0088] The checkerFactory field is a global checker storage factory that stores all available checker instances. Each checker class is uniquely identified by the name defined by the annotation, which is convenient for quick search in actual use. The addChecker(value,obj) field is used to store the checker class name (value) and the checker instance (obj) in the checker factory.

[0089] In some embodiments, the verification factory can store the verification class and the corresponding verification instance in a key-value pair. Figure 6 Assume that the key in the verification factory is "verification class A", then the value corresponding to the key can be the verification instance name corresponding to the verification class, for example, the verification instance name can include verification instance 1, verification instance 2, ..., verification instance n, etc.

[0090] From the above description, we can see that the pseudo code of the entire process of creating and storing a verification instance is as follows:

[0091]

[0092]

[0093] It can be understood that when the application is running, the system can find the name of the validator to be used, then retrieve the corresponding validation instance from the validation factory, and call the stored validation instance as needed to perform security validation on the request. This mechanism enables the system to automatically load, manage and use different validation classes at startup, can flexibly respond to various security validation requirements, and is easy to expand and maintain.

[0094] Step 202: Assemble the verification instances to obtain a verification chain corresponding to the detection interface.

[0095] Among them, the check chain can be represented by CheckerChains, such as Figure 7 As shown, the check chain can be composed of multiple check instances in a specific order, and each check instance can execute specific check logic, such as IP check, version check, etc. The check chain can execute each check instance in the order specified in the configuration file. Whenever a request comes in, the check chain can call the included check instances in sequence until the check is completed or the check fails.

[0096] In some embodiments, Figure 3 As shown, step 202 may further include the following steps:

[0097] Step 301: Obtain and parse the configuration file of the detection interface to obtain the verification strategy of the detection interface;

[0098] Step 302: Determine the verification instance to be executed by the detection interface and the execution order of each verification instance according to the verification strategy of the detection interface;

[0099] Step 303: Assemble each verification instance in execution order to obtain a verification chain corresponding to the detection interface.

[0100] The configuration file is used to define the security verification logic of the detection interface, and specifies the verifiers and execution order required for different detection interfaces in a flexible and easy-to-maintain manner. Through the configuration file, the verification strategy of each detection interface can be easily adjusted without modifying the code, which can significantly improve the flexibility and scalability of the system.

[0101] In some embodiments, security verification rules for one or more interfaces may be predefined in YAML or XML format according to verification requirements to form a corresponding configuration file.

[0102] In some embodiments, Figure 4 As shown, the following steps can be used to determine the verification instances that need to be executed by the detection interface and the execution order of each verification instance:

[0103] Step 401: Determine the interface address of the configuration file and the verification instance list corresponding to the interface address according to the verification strategy;

[0104] Step 402: extract the verification instance to be executed by the detection interface from the verification instance list;

[0105] Step 403: Determine the execution order of each verification instance according to the arrangement order of the verification instances to be executed by the detection interface in the verification instance list.

[0106] like Figure 5 As shown, the configuration file can associate and store the interface address with the verification instance list corresponding to the interface address in the form of a key-value pair. For example, the key of the configuration file is the interface address, such as the URL address of the interface, which supports wildcard matching and can uniformly define security policies for a group of interfaces. Correspondingly, the value of the configuration file can be a verification instance list composed of one or more verification instances, and the order of each verification instance in the verification instance list determines its subsequent execution order.

[0107] In some embodiments, the requested URL can be matched with the interface address (URL) defined in the configuration file, and the corresponding verifier can be loaded for the detection interface. For example, a unified verification logic can be defined for multiple detection interfaces with similar paths through URL fuzzy matching. For example, / ** / userInfo / ** / query can match all detection interfaces related to user information query.

[0108] In some embodiments, the list of verification instances in the value portion of the configuration file defines the execution order of each verification instance. When processing a request, the verification instances can be called in sequence in this order to ensure that each verification operation is executed in a predetermined order. Through the configuration file, specific security policies can be defined for different detection interfaces. For example, some detection interfaces may only require IP verification, while other detection interfaces may require a combination of multiple verifiers. The execution order of the verifiers can be changed by simply modifying the configuration file to adapt to different business needs and security requirements.

[0109] Just as an example, a configuration file in XML format can be expressed as:

[0110]

[0111] Among them, the configuration file can define the verification logic of two detection interfaces, one of which is / ** / userInfo / ** / query, and the corresponding verification instances are the IP verifier ipChecker and the version verifier versionChecker, so that the verification logic of the detection interface is "when the requested URL matches the detection interface named / userI nfo / query, the IP verifier ipChecker can be executed first, and then the version verifier versionChecker can be executed in sequence, first checking whether the requested IP is legal, and then checking whether the client version number of the request is correct."

[0112] Another interface of the configuration file is / ** / anotherEndpoint / **, and the corresponding verification instances are the version checker versionChecker and the IP checker ipChecker, so that the verification logic of the detection interface is "When the requested URL matches the detection interface named / ** / anotherEndpoint / **, the version checker versionChecker and the IP checker ipChecker can be executed in sequence, first checking whether the client version number of the request is correct, and then checking whether the requested IP is legal."

[0113] In summary, the embodiments of the present application can define the verification rules and verification order of the detection interface through an external configuration file, and can provide a flexible security policy management method. By simply modifying the configuration file, the verification process of different interfaces can be dynamically adjusted to achieve high flexibility and maintainability. This method is not only suitable for simple interface verification, but also can cope with complex multi-level security verification requirements.

[0114] Step 203: Receive a verification request for the target detection interface.

[0115] Wherein, as an example, the verification request can be an HTTP request initiated by a client (such as a browser, mobile application or other system) to a server. The embodiment of the present application can perform a security check on the received verification request to ensure the legitimacy and security of the verification request. When processing the verification request, the request can be checked layer by layer through the verifier chain configured in step 202 to ensure that the request passes the necessary security check before the business logic is executed.

[0116] In some embodiments, the client may send a request to the server via the HTTP protocol. The request may include a variety of information, such as a request header, URL path, request parameters, and request body. After receiving the client request, the server may process the request through a security verification module, and execute the business logic corresponding to the request after the verification passes.

[0117] Step 204: Match the target verification chain corresponding to the target interface from the verification chain, and perform security verification on the verification request through the target verification chain.

[0118] In some embodiments, the verification request may be security verified in the following manner:

[0119] First, call the target interface, execute the target verification instances of the target verification chain in sequence, and determine whether the verification request passes the verification of each target verification instance;

[0120] Then, if the verification request passes the verification operations of all target verification instances, the verification result of the verification request is verification passed.

[0121] Finally, if the verification request fails the verification operation of any target verification instance, the verification result of the verification request is verification failure.

[0122] In the specific implementation, when the client initiates an HTTP request, the system can find the corresponding target interface and the target validation chain corresponding to the target interface according to the requested URL. The target validation chain can be composed of one or more validation instances, and these validation instances can perform validation operations in sequence. The list of validators required for this interface can be read from the configuration file, and the instances of these validators can be obtained from the validator factory.

[0123] In some embodiments, each verifier in the verification chain can be executed in the order defined in the configuration file. Each verifier can perform security verification on a certain aspect of the request, such as IP verification, user version verification, role permission verification, etc.

[0124] In some embodiments, for the execution result of each verification instance, if the execution result of the verification instance is PASS, the next verification instance can be executed. If the execution result of the verification instance is REJECT, the subsequent verification is terminated immediately and the verification failure result is returned.

[0125] It can be understood that the request is verified one by one until all verification instances are executed or a verification instance fails. Only when all verification instances return a verification result of passing the verification, it means that the request has passed the verification. If the execution result of a verification instance is verification failure, the subsequent verification instance execution is stopped immediately. At this time, the final result of the verification request is verification failure, and the request can be rejected and the processing can be terminated.

[0126] In some embodiments, the target verification instances of the target verification chain may be executed sequentially in the following manner:

[0127] First, according to the execution order of each target verification instance in the target verification chain, each target verification instance is executed in turn to verify the verification request and obtain the verification result;

[0128] Then, if the verification result is passed, the next target verification instance is executed to verify the verification request, until all target verification instances are executed to verify the verification request or the verification is terminated when the verification result corresponding to any target verification instance is failed.

[0129] In some embodiments, when a request is received, the corresponding verification chain can be found according to the URL of the request. Each target verification instance in the verification chain can be executed in sequence according to a pre-configured order to verify the request. Each verification instance can be executed in the order specified in the configuration file. For example, if there are three verification instances a, b, and c in the verification chain, verification instance a will be executed first, then verification instance b, and finally verification instance c.

[0130] In some embodiments, each verification instance can perform corresponding verification operations according to relevant information in the request (such as IP address, request header, parameters, etc.), and return a verification result. If the current verification instance passes the verification of the request, the result of passing the verification can be returned, which can be represented by the PASS field. Correspondingly, if the verification fails, the result of failing the verification is returned, which can be represented by the REJECT field.

[0131] In some embodiments, if the verification result of the current verification instance is that the verification has passed, the next verifier can be executed and the same verification process can be repeated. Each verification instance in the verification chain is executed in sequence until all verification instances are executed or a verification failure is encountered. If the result of a verification instance is that the verification has not passed, the verification process will be terminated immediately and the system will no longer execute the remaining verification instances. At this time, the verification chain can return an overall verification failure result, indicating that the request has not passed the security verification.

[0132] It can be understood that there are two situations in which verification is terminated. First, if all verification instances in the verification chain return a verification pass result, it can be considered that the request has passed the security verification of the detection interface, and the request is allowed to continue to execute the business logic. Second, if during the execution of the verification chain, any verification instance returns a verification failure result, the system can immediately terminate the verification, no longer execute the remaining verification instances, and directly return a verification failure result, rejecting the subsequent execution of the request.

[0133] In some embodiments, the method of the present application may further include:

[0134] First, the verification strategy is updated to obtain an updated verification strategy;

[0135] Next, according to the updated verification strategy, the verification instances to be executed by the detection interface and / or the execution order of each verification instance are adjusted to update the verification chain of the detection interface.

[0136] It can be understood that as the business changes, the assembly order of each verification instance in the verification chain can be flexibly adjusted, or verification instances can be added or deleted. The above changes only need to be modified in the configuration file without changing the code.

[0137] As an example, assume that the initial verification strategy is that the detection interface executes verification instance 1, verification instance 2, and verification instance 3 in sequence, and the updated verification strategy adjusts the detection interface to execute verification instance 2, verification instance 1, and verification instance 4 in sequence, such as Figure 8 As shown, the structure of the verification chain of the detection interface can be adjusted to assemble verification instance 2, verification instance 1 and verification instance 4 in sequence.

[0138] It should be noted that after reading the new verification strategy, the verification instances corresponding to the updated verification strategy can be obtained from the verification factory according to the new execution order of each verification instance, and a new verification chain can be reassembled so that the detection interface can verify the verification request according to the latest rules.

[0139] It should be understood that, although each step in the flowcharts involved in the above embodiments is displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0140] Based on the same inventive concept, the embodiment of the present application also provides a verification device for implementing the verification method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiments of one or more verification devices provided below can refer to the limitations of the verification method above, and the specific limitations will not be repeated here.

[0141] The verification device provided in this embodiment can be integrated into a terminal device. Fig. 9 As shown, the verification device may include: an interface definition module 501 , a verification chain assembly module 502 , a request receiving module 503 and a request verification module 504 .

[0142] The above-mentioned verification device first creates a verification class for the detection interface of the component through the interface definition module 501, and creates a verification instance for implementing the verification class, and then assembles the verification instance through the verification chain assembly module 502 to obtain the verification chain corresponding to the detection interface, and then receives the verification request for the target detection interface through the request receiving module 503, and finally matches the target verification chain corresponding to the target interface from the verification chain through the request verification module 504, and performs security verification on the verification request through the target verification chain.

[0143] In some embodiments, the verification chain assembly module 502 is further configured to:

[0144] Obtain and parse the configuration file of the detection interface to obtain the verification strategy of the detection interface;

[0145] According to the verification strategy of the detection interface, determine the verification instances that the detection interface needs to execute and the execution order of each verification instance;

[0146] Assemble each verification instance in execution order to obtain the verification chain corresponding to the detection interface.

[0147] In some embodiments, the verification chain assembly module 502 is further configured to:

[0148] According to the verification strategy, determine the interface address of the configuration file and the verification instance list corresponding to the interface address;

[0149] Extract the verification instance to be executed by the detection interface from the verification instance list;

[0150] The execution order of each verification instance is determined according to the arrangement order of the verification instances to be executed by the detection interface in the verification instance list.

[0151] In some embodiments, the request verification module 504 is further configured to:

[0152] Call the target interface, execute the target verification instances of the target verification chain in sequence, and determine whether the verification request passes the verification of each target verification instance;

[0153] If the verification request passes the verification operations of all target verification instances, the verification result of the verification request is verification passed.

[0154] If the verification request fails the verification operation of any target verification instance, the verification result of the verification request is verification failed.

[0155] In some embodiments, the request verification module 504 is further configured to:

[0156] According to the execution order of each target verification instance in the target verification chain, each target verification instance is executed in turn to verify the verification request and obtain the verification result;

[0157] If the verification result is that the verification passes, the next target verification instance is executed to verify the verification request until all target verification instances are executed to verify the verification request or the verification is terminated when the verification result corresponding to any target verification instance is that the verification fails.

[0158] In some embodiments, the verification device may further include:

[0159] A strategy update module, used to update the verification strategy to obtain an updated verification strategy;

[0160] The verification chain update module is used to adjust the verification instances to be executed by the detection interface and / or the execution order of each verification instance according to the updated verification strategy, so as to update the verification chain of the detection interface.

[0161] In some embodiments, the interface definition module 501 may also be used to:

[0162] Get the verification logic of the predefined detection interface;

[0163] Add corresponding identifiers to the verification logic to obtain the verification class.

[0164] In some embodiments, the interface definition module 501 may also be used to:

[0165] Get and dynamically load the validation class with the identifier, and get the validation instance corresponding to the validation class;

[0166] Register the validation instance to the validation factory, and associate the validation class with the validation instance in the validation factory for storage.

[0167] By adopting the solution of the embodiment of the present application, a verification class is first created for the detection interface of the component, and a verification instance for implementing the verification class is created. The verification instance is then assembled to obtain a verification chain corresponding to the detection interface. Finally, when a verification request for the target detection interface is received, the target verification chain corresponding to the target interface is matched from the verification chain, and the verification request is security verified through the target verification chain.

[0168] Since each check chain is assembled from the check instances that implement the check class, the security check rules and execution order of each interface can be dynamically defined based on the check instances contained in each check chain and the corresponding assembly order. There is no need to customize exclusive check logic and a large number of filters for each interface, thereby improving the flexibility and scalability of request verification. Accordingly, if the security check rules or execution order of the interface need to be changed later, there is no need to modify the code, only the check instances contained in the check chain or the assembly order of each check instance need to be adjusted, thereby reducing code coupling, reducing the risk of errors in check changes, and improving the stability of security verification.

[0169] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0170] In one embodiment, the computer device is a terminal device, for example, its internal structure diagram can be as follows: Fig.10As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a verification method is implemented. The display unit of the computer device is used to form a visually visible image, and can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covered on the display screen, or a button, trackball or touchpad set on the computer device casing, or an external keyboard, touchpad or mouse, etc.

[0171] Those skilled in the art will understand that Fig.10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0172] Based on the same inventive concept, an embodiment of the present application also provides a computer-readable storage medium, which may include: a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0173] Since the computer program stored in the computer-readable storage medium can execute any one of the verification methods provided in the embodiments of the present application, the beneficial effects that can be achieved by any one of the verification methods provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0174] Based on the same inventive concept, the embodiment of the present application further provides a computer program product or a computer program, which includes a computer instruction, and the computer instruction is stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the method provided in various optional implementations in the above embodiments.

[0175] It should be noted that the resource consumption data, cost unit price data, blood relationship data and other data involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions. A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods.

[0176] Any reference to the memory, database or other media used in the embodiments provided in the present application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (Re RAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0177] The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. The non-relational database may include a distributed database based on blockchain, etc., but is not limited thereto. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but is not limited thereto.

[0178] In the above-mentioned verification device, computer-readable storage medium, computer equipment, and computer program product embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process and beneficial effects of the verification device, computer-readable storage medium, computer program product, computer equipment and its corresponding units described above can refer to the description of the verification method in the above embodiment, and will not be repeated here.

[0179] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0180] The above is a detailed introduction to a verification method, device and computer equipment provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A verification method, characterized in that: The method comprises: Create a verification class for the detection interface of the component, and create a verification instance for implementing the verification class; Assembling the verification instances to obtain a verification chain corresponding to the detection interface; Receiving a verification request for a target detection interface; A target verification chain corresponding to the target interface is matched from the verification chain, and a security verification is performed on the verification request through the target verification chain.

2. The method according to claim 1, characterized in that The assembling of the verification instances to obtain a verification chain corresponding to the detection interface includes: Obtain and parse the configuration file of the detection interface to obtain the verification strategy of the detection interface; Determine the verification instance to be executed by the detection interface and the execution order of each verification instance according to the verification strategy of the detection interface; The verification instances are assembled according to the execution order to obtain a verification chain corresponding to the detection interface.

3. The method according to claim 2, characterized in that Determining the verification instance to be executed by the detection interface and the execution order of each verification instance according to the verification strategy of the detection interface includes: According to the verification strategy, determine the interface address of the configuration file and the verification instance list corresponding to the interface address; Extracting the verification instance to be executed by the detection interface from the verification instance list; The execution order of each of the verification instances is determined according to the arrangement order of the verification instances to be executed by the detection interface in the verification instance list.

4. The method according to claim 3, characterized in that The matching of the target verification chain corresponding to the target interface from the verification chain, and performing security verification on the verification request through the target verification chain, includes: Calling the target interface, executing the target verification instances of the target verification chain in sequence, and determining whether the verification request passes the verification of each target verification instance; If the verification request passes the verification operations of all target verification instances, the verification result of the verification request is verification passed. If the verification request fails the verification operation of any target verification instance, the verification result of the verification request is verification failure.

5. The method according to claim 4, characterized in that The target verification instances of the target verification chain are sequentially executed, including: According to the execution order of each target verification instance in the target verification chain, each target verification instance is executed in turn to verify the verification request, and a verification result is obtained; If the verification result is that the verification passes, the next target verification instance is executed to verify the verification request until all target verification instances are executed to verify the verification request or the verification is terminated when the verification result corresponding to any target verification instance is that the verification fails.

6. The method according to any one of claims 2 to 5, characterized in that: Also includes: Updating the verification strategy to obtain an updated verification strategy; According to the updated verification strategy, the verification instances to be executed by the detection interface and / or the execution order of each verification instance are adjusted to update the verification chain of the detection interface.

7. The method according to claim 1, characterized in that The verification class is created for the detection interface of the component, including: Obtaining a predefined verification logic of the detection interface; Add a corresponding identifier to the verification logic to obtain the verification class.

8. The method according to claim 7, characterized in that The creating of a verification instance for implementing the verification class includes: Obtain and dynamically load the verification class with the identifier, and obtain the verification instance corresponding to the verification class; The verification instance is registered with a verification factory, and the verification class and the verification instance are associated and stored in the verification factory.

9. A verification device, characterized in that: The device comprises: An interface definition module, used to create a verification class for a detection interface of a component, and to create a verification instance for implementing the verification class; A verification chain assembly module, used to assemble the verification instance to obtain a verification chain corresponding to the detection interface; A request receiving module, used to receive a verification request for a target detection interface; The request verification module is used to match the target verification chain corresponding to the target interface from the verification chain, and perform security verification on the verification request through the target verification chain.

10. A computer device, characterized in that: It comprises a processor and a memory, wherein the memory stores a plurality of instructions; the processor loads instructions from the memory to execute the steps of the verification method according to any one of claims 1 to 8.

Images