CN116204223A - Field verification framework and interface verification method for application request interface - Google Patents

Abstract

The invention discloses a field verification framework and an interface verification method for an application request interface, which relate to the field of computers, wherein the field verification framework comprises a dependency library layer, a verification framework component layer and an application request interface layer, and the dependency library layer provides an infrastructure of the field verification framework based on an open source technology; the verification framework component layer is used for receiving the configuration file and the annotation, supporting decoupling of the verification logic and the service code, configuring and analyzing, judging whether the interface needs to be verified according to the annotation, analyzing the configuration file, instantiating a verification rule, and verifying according to the verification rule; the application requests the interface layer to provide the interface service. Configuration files are set in the resource management of the application, verification rules are managed in a centralized mode, notes are added to an application service interface to indicate whether the service needs to be verified, and verification logic and service codes are decoupled, so that unified management of the verification rules is achieved, and verification flexibility and verification capability are improved.

Description

Field verification framework and interface verification method for application request interface

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a field verification framework and an interface verification method for an application request interface.

Background

For any one application system, a plurality of interfaces are always provided to the outside or the inside, and the interfaces are the service capabilities of the application system. In order to protect the normal operation of the application system, besides some technical-level security protection of the interfaces, the security protection comprises network firewall, IP black-and-white list detection, flow control, XSS filtration, SQL script injection protection and the like, and the request parameters of the interfaces need to be subjected to standard verification on the service level to judge whether the request parameters meet the service requirements, so that illegal traffic on the service is blocked before the interfaces really enter the transaction processing logic.

As shown in fig. 1, when traffic enters through the internet, the traffic first passes through a firewall, which is a network security device, and by configuring some traffic rules, only traffic meeting the conditions has an opportunity to enter a device behind the firewall, and the firewall generally has the capability of identifying some illegal attack traffic (such as DDOS attack). After the traffic passes through the firewall, there will typically be some load balancing device, for example, nignx, which is a soft load balancing function that can reverse proxy the target server and add an IP black-and-white list to the proxy configuration. Finally, traffic enters the application server, and modern programming languages often provide ready XSS filtering, SQL script injection prevention capabilities through some development frameworks, that is, applications themselves provide some technical level security. Meanwhile, the application needs to perform service verification on the request parameters, some illegitimate request parameters on the service are blocked, and the service verification is performed in the application system only possibly because only the application knows the specific service rule of the application layer data.

For service verification of request parameters, it is currently common practice to use open-source verification libraries, which are generally marked with verification rules of request parameter fields by annotation, and then provide APIs to verify them.

However, the above-mentioned prior art solutions have the disadvantages of insufficient flexibility, insufficient field verification support for the collection type, and unable unified management of the verification rules:

(1) The flexibility is not enough: for an object-oriented programming language, such as Java, if the request verification parameters of multiple interfaces refer to the same object, but the service verification rules of different interfaces on the object are different, for example, a new interface does not require a primary key ID, an update interface requires a primary key ID, and annotations provided by an open source verification library cannot be judged according to the conditions of different interfaces, so that two identical classes need to be verified manually or created.

(2) Insufficient field verification support for collection types: for some fields of collection type in the interface, such as List, map in Java, etc., the open source check library also often only provides some general check modes, such as whether the collection object is empty. However, the check set may have more complex rules in the actual service, such as whether the size of the check set exceeds a limit, whether each element in the set satisfies a specified service rule, whether the key of the Map satisfies a fixed rule, and the like.

(3) The verification rules cannot be uniformly managed: the check rule is scattered in each entity class, if we find the request parameter check rule of a certain interface, we need to find the request parameter class name of the interface first, and then find the specific entity class.

Therefore, unified management of verification is realized, and improvement of verification capability is a problem to be solved at present.

Disclosure of Invention

The invention aims to provide a field verification framework and an interface verification method for an application request interface, which provide an infrastructure based on an open source technology, set configuration files in resource management of an application, intensively manage verification rules, add notes on an application service interface to indicate whether a service needs verification, decouple verification logic from a service code, realize unified management of the verification rules and improve verification capability.

In a first aspect, the above object of the present invention is achieved by the following technical solutions:

a field verification framework for an application request interface comprises a dependency library layer, a verification framework component layer and an application request interface layer, wherein the dependency library layer provides an infrastructure of the field verification framework based on an open source technology; the verification framework component layer is used for receiving the configuration file and the annotation, supporting decoupling of the verification logic and the service code, configuring and analyzing, judging whether the interface needs to be verified according to the annotation, analyzing the configuration file, instantiating a verification rule, and verifying according to the verification rule; the application requests the interface layer to provide the interface service.

The invention is further provided with: the dependency library layer includes: open source techniques for providing tangent plane logic enhancements and annotation techniques to code, open source techniques for parsing configurations.

The invention is further provided with: the open source technology comprises a spring open source library, a dom4j open source library and a jaxen open source library, wherein the spring open source library is used for providing section logic enhancement and section-oriented programming annotation technology for codes, decoupling check logic and service codes, and the dom4j open source library and the jaxen open source library are used for analyzing configuration files.

The invention is further provided with: the check framework component layer comprises a check annotation, a configuration file, a check rule, a section checker and a configuration analyzer, wherein the check annotation is matched with the configuration file and used for prompting whether the current interface of the section needs to be checked, the configuration analyzer is used for instantiating the check rule for analyzing the configuration file, and the section checker is used for checking the check parameters of the interface request according to the check rule.

The invention is further provided with: and configuring by adopting an xml file, defining an interface field check rule, and supporting the check of the set, wherein the check of the set comprises the check of the checksum of the set element and the check of the size of the set.

In a second aspect, the above object of the present invention is achieved by the following technical solutions:

an interface design method based on a field check frame comprises the steps of configuring at least one check rule file in an applied resource management file, and adding at least one annotation on a business interface to be checked for indicating that the business interface needs to be checked.

The invention is further provided with: and configuring a check rule file under a validator directory of the resource file, and binding the annotation with the corresponding check rule when the number of the check parameters requested by a certain interface is greater than 1, so as to realize the binding of the check rule and the service interface.

In a third aspect, the above object of the present invention is achieved by the following technical solutions:

an interface verification method based on a field verification framework comprises the following steps: when the application is started, the field verification framework reads the verification rule file in the resource management file of the application, analyzes and instantiates the verification rule, stores the verification rule, and performs verification when the interface receives a request.

The invention is further provided with: when the interface receives the request, the interface enters a section-oriented programming section of the field verification framework, whether an instantiated verification rule exists is searched according to the current interface name, if so, verification is carried out, corresponding operation is carried out according to a verification result, and if not, the verification is not carried out.

The invention is further provided with: if the verification is passed, interface transaction logic is called for the programming section of the section, and if the verification is not passed, corresponding processing is carried out according to the setting.

In a fourth aspect, the above object of the present invention is achieved by the following technical solutions:

a field verification framework terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the method described herein when executing the computer program.

Compared with the prior art, the beneficial technical effects of this application are:

1. according to the method and the device, the verification rule is configured in the resource management of the application, the annotation is added to the service interface, whether the application needs verification or not is determined, and decoupling of the verification logic and the service code is achieved;

2. furthermore, the application realizes the binding of the rule and the interface by configuring the check rule in the resource management of the application, avoids the configuration of the check rule in each application, improves the check flexibility and ensures the unified management of the check rule;

3. further, the present application simplifies the business process by adding annotations to the business interface.

Drawings

FIG. 1 is a schematic diagram of a prior art flow operation verification;

FIG. 2 is a schematic diagram of a field verification framework in accordance with one embodiment of the present application;

FIG. 3 is a flow chart of an interface design method according to one embodiment of the present application;

FIG. 4 is an exemplary diagram of a configuration file for one embodiment of the present application;

fig. 5 is a flowchart of an interface verification method according to an embodiment of the present application.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings.

The field verification framework for the application request interface comprises a dependency library layer, a verification framework component layer and an application request interface layer, wherein the dependency library layer is the lowest layer of the framework, an open source technology library is arranged on the dependency library layer, an infrastructure of the field verification framework is provided, and a solution for binding an interface and a verification rule is packaged on the basis of the open source technology. And at the verification framework component layer, the verification annotation and the configuration are managed separately, the decoupling of the verification logic and the service codes is supported, the configuration file is analyzed, the verification rule is instantiated, and the interface request parameters are verified according to the verification rule. The application requests the interface layer to provide the interface service.

The dependency library layer includes: the open source library is used for enhancing the section logic of the code and annotating the technology, and the decoupling of the check logic and the service code is realized; an open source library for providing an expression engine supporting declaration and execution of part of the lightweight logic in the form of expressions; and the open source library is used for analyzing the configuration file.

The check frame assembly layer includes: checking notes, configuration files, checking rules, a section checker and a configuration analyzer, wherein the checking notes are used for acquiring notes of service interface fields so as to determine whether the interface needs to be checked; the configuration file is used for a developer to configure a check rule so as to realize decoupling with the service codes; the section checker adopts an interface to check section logic, invokes a check rule and checks the request check parameter; the configuration analyzer is used for a rule configuration file of a user and instantiates a verification rule; the check rule is a data structure of a rule model, and each instance object is a check rule of a specific request check parameter.

The checking rule, the section checker and the configuration analyzer are internal components of a field checking framework, and form a core of a checking mechanism; the detection annotation and the configuration file are provided for a developer and are used for marking the annotation of the interface request verification parameters to be verified, and the configuration file is used for setting the verification rule.

And setting a verification annotation and a configuration file, managing the verification annotation and the configuration separately, configuring a verification rule, and decoupling from the service code.

In a specific embodiment of the application, a spring-AOP library, a spring-spring library and a dom4j and jaxen library for xml parsing of a spring family are arranged in a dependency library, and the spring-AOP library is used for providing tangent plane logic enhancement and AOP annotation technology for codes so that check logic is decoupled from service codes; the spring-spring library provides a JAVA expression engine that supports declaration and execution of some lightweight logic in the form of expressions, and the verification framework uses the expressions to retrieve interface fields; the dom4j library and the jaxen library are excellent xml parsing libraries, can provide parsing of xml in a streaming manner, and support XPATH to quickly locate xml nodes.

Based on the xml format file, the complex data structure can be processed, the configuration file adopts the xml format, a developer uniformly configures the verification rules in the xml format file, the configuration analyzer analyzes the rule configuration file by using an xml analysis library, the configuration file defines the interface field verification rules and supports the verification of the set, and the verification of the set comprises the verification of the self size of the checksum set of the set elements.

The application requests the interface layer for the application to provide the interface service outwards, while the check notes thus enter the field check framework.

An interface design method based on field verification framework, as shown in fig. 3, includes adding comments on a service interface to be verified, which means that the interface needs to request verification parameters, setting configuration files in applied resource management files, and configuring verification rules for the interface.

If the service interface has a plurality of request checking parameters, binding each request checking parameter with the corresponding checking rule; when there is only one request verification parameter, no binding is required, and the framework defaults to binding the single request verification parameter.

Only the annotation is set on the service interface, the service logic does not relate to any request check parameter logic, a developer does not need to explicitly write interface field check logic in the service code, and the decoupling of the check logic and the service logic is realized.

And setting an xml configuration file under a verification (validation) directory in an applied resource management (resources) file, and configuring a verification rule for the interface.

As shown in fig. 4, it can be seen from the exemplary diagram that the verification rules of each interface are uniformly managed in the configuration file, the information is concentrated and clear, specific verification rules do not need to be checked in each scattered entity class, and a plurality of verification rules can be configured for the same entity class even if the same entity class is multiplexed in different interfaces based on the rule binding interface, so that the problem of insufficient flexibility of the traditional verification framework is solved.

Based on spring-spring expressions and strong expression capacity of XML, a set of set verification rules are defined by a verification framework, and set elements, set sizes and the like can be deeply verified.

In one specific embodiment of the present application, annotations are added using @ CjyValid, and verification rules and request verification parameters are bound using @ CjyBind.

And setting configuration files in resource management through annotation of the service interface to enable the interface to have verification rules.

When the application is started, the field verification framework analyzes the configuration file and instantiates the verification rule by reading all xml verification configuration files under a resource management file verification directory (resources/value), and stores the configuration file in a memory, meanwhile, the spring library performs surrounding enhancement on the interface added with @ CjyValid annotation, and the spring-spring library expression is used for acquiring interface fields so as to verify the interface to be verified.

According to the interface verification method based on the field verification framework, as shown in fig. 5, after the interface receives a request, the flow of the interface is firstly processed in the section-oriented programming (AOP, aspect Oriented Programming) of the field verification framework, the field verification framework searches the instantiation verification rule in the memory according to the current interface name, if the corresponding verification rule is found, the verification rule is called for verification, and if the corresponding verification rule is not found, the verification is not performed, and the method is directly released.

If the verification is passed, the AOP section calls interface transaction logic, and if the verification is not passed, the AOP section carries out corresponding processing according to the configured verification result processor.

The field verification framework terminal device comprises: a processor, a memory, and a computer program, such as a field check program, stored in the memory and executable on the processor, which when executed implements the field check method of the present application.

The computer program may be divided into one or more modules/units, which are stored in the memory and executed by the processor to accomplish the present invention, for example. The one or more modules/units may be a series of computer program instruction segments capable of performing a specific function for describing the execution of the computer program in the field check frame terminal device. For example, the computer program may be divided into a plurality of modules, each module having the following specific functions:

1. the annotation module is used for extracting interface annotations;

2. and the field verification module is used for verifying the field.

The field verification framework terminal equipment can be computing equipment such as a desktop computer, a notebook computer, a palm computer, a cloud server and the like. The field checking framework terminal device may include, but is not limited to, a processor, a memory. It will be appreciated by those skilled in the art that the above examples are merely examples of the one field check framework terminal device, and are not limiting of the one field check framework terminal device, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., the one field check framework terminal device may further include an input output device, a network access device, a bus, etc.

The processor may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, data signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. The general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, which is a control center of the one field check frame terminal device, and connects the respective parts of the entire one field check frame terminal device using various interfaces and lines.

The memory may be used to store the computer program and/or module, and the processor may implement various functions of the field verification framework terminal device by running or executing the computer program and/or module stored in the memory and invoking data stored in the memory. The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required for at least one function, and the like; the storage data area may store data (such as audio data, phonebook, etc.) created according to the use of the handset, etc. In addition, the memory may include high speed random access memory, and may also include non-volatile memory, such as a hard disk, memory, plug-in hard disk, smart Media Card (SMC), secure digital (SecureDigital, SD) Card, flash Card (Flash Card), at least one disk storage device, flash memory device, or other volatile solid state memory device.

The above embodiments are not intended to limit the scope of the present invention, so: all equivalent changes in structure, shape and principle of the invention should be covered in the scope of protection of the invention.

Claims (10)

1. A field check framework for an application request interface, characterized by: the system comprises a dependency library layer, a verification framework component layer and an application request interface layer, wherein the dependency library layer provides an infrastructure of a field verification framework based on an open source technology; the verification framework component layer is used for receiving the configuration file and the annotation, supporting decoupling of the verification logic and the service code, configuring and analyzing, judging whether the interface needs to be verified according to the annotation, analyzing the configuration file, instantiating a verification rule, and verifying according to the verification rule; the application requests the interface layer to provide the interface service.

2. The field check framework for an application request interface of claim 1, wherein: the dependency library layer includes: open source techniques for providing tangent plane logic enhancement and annotation techniques to code, open source techniques for parsing configuration; and configuring by adopting an xml file, defining an interface field check rule, and supporting the check of the set, wherein the check of the set comprises the check of the checksum of the set element and the check of the size of the set.

3. A field check framework for an application request interface according to claim 1 or 2, characterized in that: the open source technology comprises a spring open source library, a dom4j open source library and a jaxen open source library, wherein the spring open source library is used for providing section logic enhancement and section-oriented programming annotation technology for codes, decoupling check logic and service codes, and the dom4j open source library and the jaxen open source library are used for analyzing configuration files.

4. The field check framework for an application request interface of claim 1, wherein: the check framework component layer comprises a check annotation, a configuration file, a check rule, a section checker and a configuration analyzer, wherein the check annotation is matched with the configuration file and used for prompting whether the current interface of the section needs to be checked, the configuration analyzer is used for instantiating the check rule for analyzing the configuration file, and the section checker is used for checking the check parameters of the interface request according to the check rule.

5. An interface design method based on a field verification framework is characterized in that: the method comprises the steps of configuring at least one check rule file in an applied resource management file, and adding at least one annotation on a service interface to be checked for indicating that the service interface needs to be checked.

6. The interface design method based on the field verification framework according to claim 5, wherein: and configuring a check rule file under a validator directory of the resource file, and binding the annotation with the corresponding check rule when the number of the check parameters requested by a certain interface is greater than 1, so as to realize the binding of the check rule and the service interface.

7. An interface verification method based on a field verification framework is characterized by comprising the following steps of: comprising the following steps: when the application is started, the field verification framework reads the verification rule file in the resource management file of the application, analyzes and instantiates the verification rule, stores the verification rule, and performs verification when the interface receives a request.

8. The field verification framework-based interface verification method according to claim 7, wherein: when the interface receives the request, the interface enters a section-oriented programming section of the field verification framework, whether an instantiated verification rule exists is searched according to the current interface name, if so, verification is carried out, corresponding operation is carried out according to a verification result, and if not, the verification is not carried out.

9. The field verification framework-based interface verification method according to claim 8, wherein: if the verification is passed, interface transaction logic is called for the programming section of the section, and if the verification is not passed, corresponding processing is carried out according to the setting.

10. A field check frame terminal, characterized in that: comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the method according to any of claims 1-9 when the computer program is executed.

Images