Interface parameter checking method and device, server and storage medium

Abstract

The application discloses a kind of interface parameter verification method, device, server and storage medium, wherein, method includes: obtaining the signing rule and the signature verification rule of engineering project;The first calling mark and / or second calling mark of each subproject in the multiple subprojects of engineering project is configured as a requestor and / or as a responder, wherein, the first calling mark is used to call the signing rule, and the second calling mark is used to call the signature verification rule;The verification of interface parameter between the subproject as a requestor and the subproject as a responder is realized using the first calling mark and / or second calling mark.Thereby, it is solved that each project in the related art independently writes verification code, cannot guarantee that the signing and un-signing mechanism in the same micro-service system is consistent, there is the problem such as verification code redundancy, high maintenance cost of project.

Description

Technical Field

[0001] This application relates to the field of parameter verification technology, and in particular to a method, apparatus, server and storage medium for verifying interface parameters. Background Technology

[0002] In vehicle networking systems, enterprise system architectures often use microservices. The characteristic of microservices is that each microservice can run independently in its own process, and each service is developed for independent business. A microservice that completes a specific function will create many sub-projects, and multiple sub-projects will provide interfaces to the outside world to ensure data transmission. In order to ensure the security of data during network transmission, it is necessary to sign the interface parameters.

[0003] The relevant technologies typically require each project to write its own signature mechanism to ensure that interface parameters received over the network are not corrupted. However, if each project writes its own signature mechanism, it is impossible to guarantee consistency of the signature mechanism within the same microservice architecture, nor can it guarantee the signature verification standards of the project. Furthermore, as the code for business functions iterates, it increases the maintenance cost of the project. Summary of the Invention

[0004] This application provides a method, apparatus, server, and storage medium for verifying interface parameters, in order to solve the problems of related technologies where each project has to write independent verification code, which cannot guarantee the consistency of the signature addition and designing mechanisms in the same microservice system, resulting in redundant verification code and high project maintenance costs.

[0005] The first aspect of this application provides a method for verifying interface parameters, comprising the following steps: obtaining the signature rules and verification rules of an engineering project; configuring a first call identifier and / or a second call identifier for each sub-project in multiple sub-projects of the engineering project when acting as a requester and / or a responder, wherein the first call identifier is used to call the signature rules, and the second call identifier is used to call the verification rules; and using the first call identifier and / or the second call identifier to verify the interface parameters between the sub-project acting as a requester and the sub-project acting as a responder.

[0006] Optionally, in one embodiment of this application, the step of using the first call identifier and / or the second call identifier to verify the interface parameters between the requesting sub-project and the responding sub-project includes: the requesting sub-project calling the signature rule to sign the request parameters of the target interface to be called, and sending them to the responding sub-project corresponding to the target interface; the responding sub-project using the second call identifier to verify the signature of the signed request parameters, generating response parameters after successful verification, and sending the response parameters to the requesting sub-project.

[0007] Optionally, in one embodiment of this application, the sub-project acting as the responder verifies the signed request parameters using the second call identifier, further comprising: identifying a flag bit of the second call identifier configured by the sub-project acting as the responder; if the flag bit is a first flag bit, the sub-project acting as the responder calls the verification rule to verify the signed request parameters; if the flag bit is a second flag bit, no verification is performed.

[0008] Optionally, in one embodiment of this application, sending the response parameters to the sub-project acting as the requester includes: identifying a flag bit of a first call identifier configured in the sub-project acting as the responder; if the flag bit is a first flag bit, the sub-project acting as the responder calls the signature rule to sign the response parameters and sends the signed response parameters to the sub-project acting as the requester; if the flag bit is a second flag bit, the response parameters are sent to the sub-project acting as the requester.

[0009] Optionally, in one embodiment of this application, after sending the response parameters to the sub-project acting as the requester, the method further includes: identifying a flag bit of the second call identifier configured by the sub-project acting as the requester; if the flag bit is a first flag bit, the sub-project acting as the requester calls the signature verification rule to verify the signed response parameters, and calls the target interface after the verification is successful; if the flag bit is a second flag bit, the target interface is called.

[0010] Optionally, in one embodiment of this application, configuring the first invocation identifier and / or second invocation identifier when each sub-project in the plurality of sub-projects of the project acts as a requester and / or a responder includes: defining an interface class for the control layer in each sub-project; setting a flag bit of the first invocation identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature operation is performed, and the second flag bit indicates that a signature operation is not performed; setting a flag bit of the second invocation identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature verification operation is performed, and the second flag bit indicates that a signature verification operation is not performed.

[0011] Optionally, in one embodiment of this application, before configuring the first call identifier and / or second call identifier when each sub-project in the multiple sub-projects of the project acts as a requester and / or a responder, the method further includes: configuring the configuration file in each sub-project and the target location in the project; setting the key values ​​corresponding to the signing rules and verification rules in the configuration file; generating the dependency relationship between sub-projects based on the target location, wherein the key values ​​are used to sign and design the interface parameters respectively.

[0012] A second aspect of this application provides an interface parameter verification device, comprising: an acquisition module for acquiring signature rules and verification rules of an engineering project; a first configuration module for configuring a first call identifier and / or a second call identifier for each sub-project in a plurality of sub-projects of the engineering project when acting as a requester and / or a responder, wherein the first call identifier is used to call the signature rules, and the second call identifier is used to call the verification rules; and a verification module for using the first call identifier and / or the second call identifier to verify the interface parameters between the sub-project acting as a requester and the sub-project acting as a responder.

[0013] Optionally, in one embodiment of this application, the verification module is further configured to have the request parameters of the target interface to be called by the sub-project as the requesting party call the signature rule and send them to the sub-project as the responding party corresponding to the target interface; the sub-project as the responding party uses the second call identifier to verify the signature of the signed request parameters, and after the verification is successful, generates response parameters and sends the response parameters to the sub-project as the requesting party.

[0014] Optionally, in one embodiment of this application, the verification module is further configured to identify the flag bit of the second call identifier configured in the sub-project as the responder; if the flag bit is the first flag bit, the sub-project as the responder calls the signature verification rule to verify the signature of the signed request parameters; if the flag bit is the second flag bit, the signature verification is not performed.

[0015] Optionally, in one embodiment of this application, the verification module is further configured to identify the flag bit of the first call identifier configured in the sub-project acting as the responder; if the flag bit is the first flag bit, the sub-project acting as the responder calls the signing rule to sign the response parameters and sends the signed response parameters to the sub-project acting as the requester; if the flag bit is the first flag bit, the response parameters are sent to the sub-project acting as the requester.

[0016] Optionally, in one embodiment of this application, after sending the response parameters to the sub-project acting as the requester, the verification module is further used to identify the flag bit of the second call identifier configured by the sub-project acting as the requester; if the flag bit is the first flag bit, the sub-project acting as the requester calls the signature verification rule to verify the signed response parameters, and calls the target interface after the verification is successful; if the flag bit is the second flag bit, the target interface is called.

[0017] Optionally, in one embodiment of this application, the first configuration module is further configured to define an interface class for the control layer in each of the plurality of sub-projects; set the flag bit of the first call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature operation is performed, and the second flag bit indicates that a signature operation is not performed; set the flag bit of the second call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature verification operation is performed, and the second flag bit indicates that a signature verification operation is not performed.

[0018] Optionally, in one embodiment of this application, it further includes: a second configuration module, configured to configure a configuration file in each sub-project and a target location in the project before configuring each sub-project as a first call identifier of a requester and / or a second call identifier of a responder in the multiple sub-projects of the project; set key values ​​corresponding to the signature rules and verification rules in the configuration file; and generate a dependency relationship between sub-projects based on the target location, wherein the key values ​​are used to sign and design the interface parameters respectively.

[0019] A third aspect of this application provides a server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to perform an interface parameter verification method as described in the above embodiments.

[0020] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to perform the interface parameter verification method as described in the above embodiments.

[0021] This application embodiment can configure a first invocation identifier and / or a second invocation identifier for each sub-project when acting as a requester and / or a responder. By setting corresponding interface parameter validation rules, interface parameters can be validated, facilitating their maintenance and management, improving validation efficiency, and resulting in cleaner, more readable business code, thus reducing redundancy in interface parameter validation code. This solves the problems of related technologies where each project needs to write its own validation code, making it impossible to guarantee consistency in the signature addition and designing mechanisms within the same microservice architecture, leading to redundant validation code and high project maintenance costs.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0024] Figure 1 This is a flowchart of an interface parameter verification method provided according to an embodiment of this application;

[0025] Figure 2 This is a flowchart illustrating the signature rules for the requesting party according to an embodiment of this application.

[0026] Figure 3 This is a sequence diagram of request interface business processing and signature verification / addition provided according to the embodiments of this application;

[0027] Figure 4 This is a flowchart illustrating the signature verification rules for the respondent according to an embodiment of this application.

[0028] Figure 5 This is a flowchart illustrating the signature rules for the respondent according to the embodiments of this application.

[0029] Figure 6 This is a flowchart illustrating the signature verification rules for the requesting party according to an embodiment of this application.

[0030] Figure 7 This is an example diagram of an interface parameter verification device provided according to an embodiment of this application;

[0031] Figure 8 This is a schematic diagram of the structure of a server provided according to an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0033] The following description, with reference to the accompanying drawings, details an interface parameter verification method, apparatus, server, and storage medium according to embodiments of this application. Addressing the problems mentioned in the background section, this application provides an interface parameter verification method. This method allows configuration of a first invocation identifier and / or a second invocation identifier for each sub-project when acting as a requester and / or a responder. By setting corresponding interface parameter verification rules, interface parameter verification is achieved, facilitating interface parameter maintenance and management, improving verification efficiency, and resulting in clean, concise, and highly readable business code, thereby reducing redundancy in interface parameter verification code. This solves the problems of related technologies where each project requires independent verification code writing, making it impossible to guarantee consistency in the signature addition and designing mechanisms within the same microservice architecture, leading to redundant verification code and high project maintenance costs.

[0034] Specifically, Figure 1 This is a flowchart illustrating an interface parameter verification method provided in an embodiment of this application.

[0035] like Figure 1 As shown, the method for validating the interface parameters includes the following steps:

[0036] In step S101, the signing rules and verification rules for the project are obtained.

[0037] Understandably, in the field of connected vehicle data services, the interaction of important data and business scenarios relies heavily on mutual API calls, making data security paramount. Therefore, developers in Java projects must consider data security, ensuring that request parameters received over the network are not corrupted, and that API calls involve both requesters and responders.

[0038] In actual implementation, the requesting party in this embodiment needs to sign the parameters before requesting the interface, and the requesting party verifies the signature upon receiving the response parameters. Similarly, the responding party can also verify the signature of the requesting party's request parameters and sign the generated response parameters. The signing and verification rules are described in detail below.

[0039] In step S102, a first call identifier and / or a second call identifier are configured for each sub-project in the multiple sub-projects of the project when it acts as a requester and / or a responder, wherein the first call identifier is used to call the signature rule and the second call identifier is used to call the signature verification rule.

[0040] It is understood that the embodiments of this application can configure a first call identifier and / or a second call identifier for each sub-project when it acts as a requester and / or a responder. By setting corresponding interface parameter verification rules, the interface parameters can be verified, which facilitates the maintenance and management of interface parameters, improves the verification efficiency of interface parameters, and makes the business code clean and readable, thereby reducing the redundancy of the interface parameter verification code.

[0041] In one embodiment of this application, configuring a second call identifier for a first call identifier when each sub-project in multiple sub-projects of an engineering project acts as a requester and / or a responder includes: defining an interface class for the control layer in each sub-project; setting a flag bit of the first call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature operation is performed, and the second flag bit indicates that a signature operation is not performed; setting a flag bit of the second call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a verification operation is performed, and the second flag bit indicates that a signature verification operation is not performed.

[0042] For ease of understanding, this embodiment of the application can take the responder as an example. The `@SignProcessSha256` annotation is introduced on the class method of the defined Controller layer. This annotation has two configurable flags: a second invocation flag `verify` and a first invocation flag `sign`. `verify` indicates signature verification, and `sign` indicates signature addition. For the responder, `verify` indicates whether to verify the request parameters. The value of the `verify` parameter can be set to either the first flag `true` or the second flag `false`. The default value is `true`, indicating that the request parameters are verified; `false` indicates that they are not verified. After verification, the responder generates response parameters and sends them to the requester. That is, `sign` indicates that the response parameters are signed. The value of the `sign` parameter can be set to `true` or `false`. The default value is `true`, indicating that the response parameters are signed; `false` indicates that they are not signed.

[0043] Furthermore, the annotation @SignProcessSha256 in this application embodiment can be set in the following ways: 1. @SignProcessSha256 indicates that the request parameters are verified and the response parameters are signed by default; 2. @SignProcessSha256(verify=false) indicates that the request parameters are not verified and the response parameters are signed; 3. @SignProcessSha256(sign=false) indicates that the request parameters are verified and the response parameters are not signed; 4. @SignProcessSha256(verify=false,sign=false) indicates that the request parameters are not verified and the response parameters are not signed.

[0044] In one embodiment of this application, before configuring each sub-project in multiple sub-projects of the project as the first call identifier of the requester and / or the second call identifier when it is the responder, the method further includes: configuring the configuration file in each sub-project and the target location in the project; setting the key values ​​corresponding to the signing rules and verification rules in the configuration file; generating the dependency relationship between sub-projects based on the target location, wherein the key values ​​are used to sign and design the interface parameters respectively.

[0045] This application embodiment allows setting a key value for signing and verification. The key value can be defined according to requirements, and the standard format is English letters and numbers. This key needs to be set in a configuration file with the extension .yaml. The key definition in the configuration file is an array of sdkconfig.supplierinfo.list. The objects defined in the array contain the following attributes: businessId, encryptionKey, and supplierName. The definition objects in this application embodiment can be set according to the actual situation and are not specifically limited.

[0046] Furthermore, this application embodiment can also introduce the Maven coordinate system of the current project components, and use the coordinates to uniquely identify each sub-project, so that it can be referenced by other sub-projects.

[0047] In step S103, the interface parameters between the sub-item as the requester and the sub-item as the responder are verified using the first call identifier and / or the second call identifier.

[0048] The process involves the requesting sub-project calling the signature rules to sign the request parameters of the target interface to be called, and sending them to the corresponding responding sub-project. The responding sub-project then uses the second call identifier to call the signature verification rules to verify the signed request parameters. After successful verification, it generates response parameters and sends them to the requesting sub-project.

[0049] In this embodiment of the application, the requesting party may need to sign the request parameters before requesting the interface. The signing rules are as follows: Figure 2 As shown, it includes the following steps:

[0050] Step 1: Obtain the key value (this key value is the encryptionKey value set in the configuration file);

[0051] Step 2: Sign the request parameters to obtain a message digest;

[0052] Step 3: Return the message summary;

[0053] Step 4: End the signature process.

[0054] Furthermore, after the signing is completed, this embodiment of the application can send the signed request parameters to the sub-project corresponding to the target interface as the responder. The sub-project as the responder uses the second call identifier to verify the signed request parameters, which also includes: identifying the flag bit of the second call identifier configured by the sub-project as the responder; if the flag bit is the first flag bit, the sub-project as the responder calls the verification rules to verify the signed request parameters; if the flag bit is the second flag bit, the verification is not performed.

[0055] like Figure 3 As shown in the embodiment of this application, the flag bit of the second call identifier configured in the sub-project of the responder can be identified. If the verify parameter value is set to true, the signature of the signed request parameter is verified. If the signature verification is successful, the business logic is invoked to process the actual business logic. If it fails, the requester is returned a message "Signature verification failed". If the second flag bit is false, it means that no signature verification is performed and the actual business logic is processed directly.

[0056] Furthermore, combined Figure 4 As shown, taking the verification of signed request parameters by the responder as an example, the verification rules in this application embodiment include the following steps:

[0057] Step 1: Obtain the prerequisites, including request parameters, key value, and signature value. The request parameters are obtained by parsing the request body, the key value is obtained by setting static parameters when creating the sub-project (the key value is the encryptionKey value set in the configuration file), and the signature value is the result of the signature operation performed by the requester, which is also obtained by parsing the request body.

[0058] Step 2: Check if the signature value is empty. If it is empty, skip to step 6 and send a "signature verification failed" message to the requester.

[0059] Step 3: Perform signature verification on the request parameters to obtain the information digest;

[0060] Step 4: Compare the result digest obtained in Step 3 with the signature value passed in Step 1. If they match, proceed to Step 5; otherwise, proceed to Step 6.

[0061] Step 5: Indicates successful signature verification; continue executing business logic and proceed to Step 7.

[0062] Step 6: Indicate that the signature verification failed and simultaneously respond to the requester with the message "Signature verification failed," then proceed to Step 7;

[0063] Step 7: End the verification process.

[0064] In one embodiment of this application, sending response parameters to a sub-project that is the requester includes: identifying a flag bit of a first call identifier configured in the sub-project that is the responder; if the flag bit is the first flag bit, the sub-project that is the responder calls a signing rule to sign the response parameters and sends the signed response parameters to the sub-project that is the requester; if the flag bit is the second flag bit, the response parameters are sent to the sub-project that is the requester.

[0065] Understandably, after successful verification, the sub-project, as the responding party, will generate response parameters, such as... Figure 3 As shown, in this embodiment, the need to sign the response parameters can be determined based on the flag bit of the configured first call identifier. If the sign parameter value is set to true, it indicates that the response parameters should be signed, and in this embodiment, the signed response parameters are sent to the requester. If false, it indicates that the response parameters should not be signed, and the response parameters are sent directly to the requester. The process for signing the response parameters is as follows: Figure 5 As shown.

[0066] In one embodiment of this application, after sending the response parameters to the sub-project that is the requester, the method further includes: identifying the flag bit of the second call identifier configured by the sub-project that is the requester; if the flag bit is the first flag bit, the sub-project that is the requester calls the signature verification rule to verify the signature of the signed response parameters, and calls the target interface after the verification is successful; if the flag bit is the second flag bit, the target interface is called.

[0067] Similarly, after receiving the response parameters, the sub-project acting as the requester can also verify the response parameters according to the signature verification rules. In actual execution, if the flag of the second call identifier configured by the sub-project acting as the requester is true, it indicates that the response parameters are verified, and the target interface is called to realize the interaction of the business scenario after successful verification; if the flag is false, it indicates that no verification operation is performed on the response parameters, that is, the interface can be called successfully. The signature verification process is as follows: Figure 6 As shown.

[0068] According to the interface parameter verification method proposed in this application, each sub-project can be configured with a first call identifier and / or a second call identifier when acting as a requester and / or a responder. By setting corresponding interface parameter verification rules, interface parameters can be verified, facilitating the maintenance and management of interface parameters, improving the efficiency of interface parameter verification, and resulting in cleaner and more readable business code, thereby reducing the redundancy of interface parameter verification code. This solves the problems of related technologies where each project needs to write independent verification code, making it impossible to guarantee the consistency of the signature addition and decryption mechanisms within the same microservice system, and resulting in redundant verification code and high project maintenance costs.

[0069] Next, the interface parameter verification device proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0070] Figure 7 This is a block diagram of an interface parameter verification device according to an embodiment of this application.

[0071] like Figure 7 As shown, the interface parameter verification device 10 includes: an acquisition module 100, a first configuration module 200, and a verification module 300.

[0072] The acquisition module 100 is used to acquire the signature rules and verification rules of the project; the first configuration module 200 is used to configure the first call identifier and / or the second call identifier of each sub-project in the multiple sub-projects of the project when it is a requester and / or a responder, wherein the first call identifier is used to call the signature rules and the second call identifier is used to call the verification rules; the verification module 300 is used to verify the interface parameters between the sub-project as a requester and the sub-project as a responder using the first call identifier and / or the second call identifier.

[0073] In one embodiment of this application, the verification module 300 is further configured to, as the requesting party, call the signature rule to sign the request parameters of the target interface to be called, and send them to the corresponding sub-project as the responding party of the target interface; the responding sub-project uses the second call identifier to verify the signature of the signed request parameters, and after the verification is successful, generates response parameters and sends the response parameters to the requesting sub-project.

[0074] In one embodiment of this application, the verification module 300 is further configured to identify the flag bit of the second call identifier configured as a sub-item of the responder; if the flag bit is the first flag bit, the sub-item of the responder calls the signature verification rule to verify the signature of the signed request parameters; if the flag bit is the second flag bit, the signature verification is not performed.

[0075] In one embodiment of this application, the verification module 300 is further configured to identify the flag bit of the first call identifier configured in the sub-project as the responder; if the flag bit is the first flag bit, the sub-project as the responder calls the signing rule to sign the response parameters and sends the signed response parameters to the sub-project as the requester; if the flag bit is the second flag bit, the response parameters are sent to the sub-project as the requester.

[0076] In one embodiment of this application, after sending the response parameters to the sub-project that is the requester, the verification module 300 is further used to identify the flag bit of the second call identifier configured by the sub-project that is the requester; if the flag bit is the first flag bit, the sub-project that is the requester calls the signature verification rule to verify the signature of the signed response parameters, and calls the target interface after the verification is successful; if the flag bit is the second flag bit, the target interface is called.

[0077] In one embodiment of this application, the first configuration module 200 is further configured to define an interface class for the control layer in each of the multiple sub-projects; set a flag bit of the first call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature operation is performed and the second flag bit indicates that a signature operation is not performed; set a flag bit of the second call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature verification operation is performed and the second flag bit indicates that a signature verification operation is not performed.

[0078] In one embodiment of this application, the interface parameter verification device 10 further includes a second configuration module.

[0079] The second configuration module is used to configure the configuration file and target location in the project before each sub-project acts as a requester and / or a responder when it acts as a first call identifier and / or second call identifier in the multiple sub-projects of the project; set the key values ​​corresponding to the signing rules and verification rules in the configuration file; and generate the dependency relationship between sub-projects based on the target location. The key values ​​are used to sign and design the interface parameters, respectively.

[0080] It should be noted that the explanation of the aforementioned method embodiment for verifying interface parameters also applies to the interface parameter verification device of this embodiment, and will not be repeated here.

[0081] The interface parameter verification device proposed in this application embodiment can configure a first call identifier and / or a second call identifier for each sub-project when acting as a requester and / or a responder. By setting corresponding interface parameter verification rules, interface parameters can be verified, facilitating the maintenance and management of interface parameters, improving the verification efficiency, and resulting in cleaner and more readable business code, thereby reducing the redundancy of interface parameter verification code. This solves the problems of related technologies where each project needs to write independent verification code, making it impossible to guarantee the consistency of the signature addition and decryption mechanisms within the same microservice system, leading to redundant verification code and high project maintenance costs.

[0082] Figure 8 A schematic diagram of the structure of a server provided in an embodiment of this application. The server may include:

[0083] The memory 801, the processor 802, and the computer program stored on the memory 801 and capable of running on the processor 802.

[0084] When the processor 802 executes the program, it implements the interface parameter verification method provided in the above embodiments.

[0085] Furthermore, the server also includes:

[0086] Communication interface 803 is used for communication between memory 801 and processor 802.

[0087] The memory 801 is used to store computer programs that can run on the processor 802.

[0088] The memory 801 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0089] If the memory 801, processor 802, and communication interface 803 are implemented independently, then the communication interface 803, memory 801, and processor 802 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0090] Optionally, in a specific implementation, if the memory 801, processor 802, and communication interface 803 are integrated on a single chip, then the memory 801, processor 802, and communication interface 803 can communicate with each other through an internal interface.

[0091] The processor 802 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0092] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for verifying interface parameters.

[0093] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0094] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0095] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0096] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0097] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

Claims

1. A method for checking interface parameters, characterized in that, Includes the following steps: Obtain the signing and verification rules for engineering projects; Configure a first call identifier and / or a second call identifier for each sub-project in the multiple sub-projects of the project when it acts as a requester and / or a responder, wherein the first call identifier is used to call the signature rule and the second call identifier is used to call the signature verification rule; The first call identifier and / or the second call identifier are used to verify the interface parameters between the sub-item as the requester and the sub-item as the responder. The configuration of the first and / or second invocation identifiers when each sub-project in the multiple sub-projects of the project acts as a requester and / or a responder includes: defining an interface class for the control layer in each sub-project; setting a flag bit of the first invocation identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature operation is performed, and the second flag bit indicates that a signature operation is not performed; setting a flag bit of the second invocation identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature verification operation is performed, and the second flag bit indicates that a signature verification operation is not performed.

2. The method for verifying interface parameters according to claim 1, characterized in that, The method of using the first call identifier and / or the second call identifier to verify the interface parameters between the sub-item as the requester and the sub-item as the responder includes: The sub-project acting as the requester calls the signature rule to sign the request parameters of the target interface to be called, and sends them to the sub-project acting as the responder corresponding to the target interface. The sub-project acting as the responder uses the second call identifier to verify the signed request parameters. After successful verification, it generates response parameters and sends the response parameters to the sub-project acting as the requester.

3. The method for verifying interface parameters according to claim 2, characterized in that, The sub-item acting as the responder verifies the signed request parameters using the second invocation identifier, including: Identify the flag bit of the second call identifier configured in the sub-project that is acting as the responder; If the flag bit is the first flag bit, the sub-item acting as the responder calls the signature verification rule to verify the signature of the signed request parameters; if the flag bit is the second flag bit, the signature verification is not performed.

4. The method for verifying interface parameters according to claim 2, characterized in that, Sending the response parameters to the sub-project that is the requester includes: Identify the flag bit of the first call identifier configured in the sub-project that is acting as the responder; If the flag bit is the first flag bit, the sub-project acting as the responder calls the signature rule to sign the response parameters and sends the signed response parameters to the sub-project acting as the requester; if the flag bit is the second flag bit, the response parameters are sent to the sub-project acting as the requester.

5. The method for verifying interface parameters according to claim 2, characterized in that, After sending the response parameters to the sub-item that is the requester, the process also includes: Identify the flag bit of the second call identifier configured as the requesting party in the sub-project configuration; If the flag is the first flag, the sub-project acting as the requester calls the signature verification rule to verify the signed response parameters, and calls the target interface after the verification is successful. If the flag is the second flag, the target interface is called.

6. The method for verifying interface parameters according to claim 1, characterized in that, Before configuring the first invocation identifier and / or second invocation identifier when each sub-project in the multiple sub-projects of the project acts as a requester and / or a responder, the following is also included: Configure the configuration file for each sub-project and its target location within the project; The key values ​​corresponding to the signing and verification rules are set in the configuration file, and the dependency relationship between sub-projects is generated based on the target location. The key values ​​are used to sign and design the interface parameters, respectively.

7. A device for verifying interface parameters, characterized in that, include: The acquisition module is used to acquire the signing and verification rules for engineering projects; The first configuration module is used to configure a first call identifier and / or a second call identifier when each sub-project in the multiple sub-projects of the project acts as a requester and / or a responder, wherein the first call identifier is used to call the signature rule, and the second call identifier is used to call the signature verification rule; The verification module is used to verify the interface parameters between the sub-item as the requester and the sub-item as the responder by using the first call identifier and / or the second call identifier. The first configuration module is further configured to: define an interface class for the control layer in each of the plurality of sub-projects; set the flag bit of the first call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature operation is performed and the second flag bit indicates that a signature operation is not performed; and set the flag bit of the second call identifier to a first flag bit or a second flag bit on the method body corresponding to the interface class, wherein the first flag bit indicates that a signature verification operation is performed and the second flag bit indicates that a signature verification operation is not performed.

8. A server, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the interface parameter verification method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the method for verifying the interface parameters as described in any one of claims 1-6.

Images