Ticket verification method, device, terminal and storage medium

Abstract

This application relates to a ticket verification method, apparatus, terminal, and storage medium. The method includes: receiving a user request sent by a client; performing rule matching on the user request; forwarding the user request to a corresponding request interception unit based on the rule matching result; obtaining an interception processing result; extracting the ticket information contained therein and comparing it with a pre-stored ticket stub; when the information matches, reading the user's basic information corresponding to the ticket stub and sending it to a system service; receiving a user permission list returned by the system service; modifying the user request using the user permission list; and sending the modified processing result to the microservice corresponding to the current user permission list. This application improves the gateway's ability to handle complex permission logic, reduces the risk of attacks on microservices, and improves the flexibility of gateway configuration.

Description

Technical Field

[0001] The present invention relates to the field of microservice communication technology, and in particular to a method, device, terminal and storage medium for verifying tickets of different types of user identities based on a request address. Background Art

[0002] Microservices is a software architecture style that consists of multiple small independent services. Each service is independently developed and deployed. Various services communicate with each other through network interfaces. Its core idea is to split complex applications into smaller and more manageable parts to improve the flexibility, maintainability and scalability of the program. Thanks to the above advantages of microservices, many companies are gradually applying microservices to their own businesses. For example, companies that provide customers with invoice inspection, authentication and other functions split large applications into multiple small independent services according to different functions to provide customers with online invoice services.

[0003] The various service modules of the ticket system are set to require different user permissions for access, and different access requests can obtain different permissions. In existing technologies, the gateway is only responsible for the login logic, and the actual business permission function logic after login is handled by each microservice itself. This will cause different services to need to maintain a large amount of identical or similar code, and as the number of services increases, each service needs to interact with user requests, and the calls between services may appear slightly cumbersome. At the same time, the permission judgment logic in each microservice is also repeated and redundant, which invisibly reduces the performance of the service. It will also expose the microservice to various access requests, increasing its risk of being attacked.

[0004] Therefore, how to achieve unified authority verification of various access requests while ensuring system security has become a problem that people in the technical field need to solve. Summary of the invention

[0005] In order to reduce code redundancy on the microservice side, improve the security of the program, and meet its ease of use and scalability, the present application provides a ticket verification method, device, terminal and storage medium for different types of user identities based on the request address.

[0006] In the first aspect, the present application provides a bill verification method, which adopts the following technical solution:

[0007] A bill verification method comprises the following steps:

[0008] Receive a user request sent by a client, perform rule matching on the user request, and forward the user request to a request interception unit corresponding to the rule matching result according to the rule matching result;

[0009] Obtaining the interception processing results returned by each of the request interception units, extracting the ticket information contained in the interception processing results and comparing the information with the pre-stored ticket stub, and when the information comparison is consistent, reading the user basic information corresponding to the ticket stub, and sending the user basic information to the system service;

[0010] Receive the user permission list returned by the system service, use the user permission list to transform the user request, and send the transformation processing result to the microservice corresponding to the current user permission list.

[0011] By adopting the above technical solution, special business logic processing is added to the gateway layer, and some common processing logic is extracted from specific services, so as to achieve more modular and reusable code, reduce code duplication and redundancy, improve development efficiency, and at the same time improve the usability and scalability of the application.

[0012] Preferably, before receiving the user request sent by the client, it is also necessary to perform login verification on the client, which specifically includes the following steps:

[0013] In response to the login request sent by the client, the client is authenticated using the user login information contained in the login request.

[0014] When the login verification is successful, the basic user information is extracted from the login request and summarized into an information object, the information object is encrypted to obtain a ticket stub, and the matching basic user information and the ticket stub are saved in pairs.

[0015] By adopting the above technical solution, the user login information is sent to the gateway for a user identity verification operation, and after successful verification, a ticket stub is obtained as the identity credential for subsequent user requests, ensuring the legitimacy of the user identity and ensuring the safe operation of the application.

[0016] Preferably, the receiving of the user request sent by the client, performing rule matching on the user request, and forwarding the user request to a request interception unit corresponding to the rule matching result according to the rule matching result specifically includes the following steps:

[0017] Receive the user request, read the IP address information of the client as the sender of the current user request and the request address information and request header information contained in the user request;

[0018] The IP address matching rules, request address matching rules and request header matching rules are extracted from the pre-configured configuration files respectively, the IP address information is matched with the IP address matching rules, the request address information is matched with the request address matching rules, and the request header information is matched with the request header matching rules. The rule matching result is generated according to the items and the number of successful rule matching, and the user request is forwarded to the request interception unit corresponding to the rule matching result.

[0019] By adopting the above technical solution, the matching rules for forwarding user requests to each request interception unit are clarified. Since the request interception unit only performs specific operations, the request interception unit itself cannot identify whether the user request needs to be operated. Therefore, before interception, the user request needs to be forwarded to the corresponding request interception unit according to the set rules. Therefore, the above technical solution is a crucial part of identity authentication, which ensures that various types of user requests can be processed correctly, so that user requests can be matched with the corresponding permissions to perform actual business operations.

[0020] Preferably, the obtaining of the interception processing results returned by each of the request interception units, extracting the ticket information contained in the interception processing results and comparing the information with the pre-stored ticket stub, and when the information comparison is consistent, reading the user basic information corresponding to the ticket stub, and sending the user basic information to the system service specifically includes the following steps:

[0021] Respectively obtain the interception processing results returned by each of the request interception units, the interception processing results corresponding to at least one interception rule, and each of the interception processing results is the user request after passing through the corresponding request interception unit and being processed by the request interception unit;

[0022] The ticket information contained in the interception processing result is extracted, and the ticket information is compared with the ticket stub. When the information comparison is consistent, the pre-stored user basic information corresponding to the ticket stub is read and sent to the system service.

[0023] By adopting the above technical solution, the ticket information in the intercepted user request is compared with the pre-stored ticket information to ensure that the ticket is valid and the user request is legal. This step sets the verification procedure for the user request before entering the microservice, ensuring the simplicity of the microservice code.

[0024] Preferably, the interception rules at least include:

[0025] The first interception processing rule determines whether the IP address information satisfies the IP address matching rule and whether the request address information satisfies the request address matching rule. If any one of the two conditions is not satisfied, the current user request is intercepted.

[0026] The second interception processing rule reads the request header information, which includes any one or more of a ticket validity mark, an encryption mark, a one-time request mark, and a simulated identity mark, and determines whether each mark in the request header information satisfies the request header matching rule. When any one of the marks does not meet the rule, the current user request is intercepted.

[0027] By adopting the above technical solution, the specific interception rules for processing user requests are refined. Through these interception rules, the modification of user requests, illegal interception, encryption and decryption, and simulation of user IDs are realized. User requests that do not comply with the rules are intercepted outside the microservice application. At the same time, the user identity is confirmed by decrypting the user's encrypted request to prevent attacks and ensure the security of the microservice end.

[0028] Preferably, the receiving the user permission list returned by the system service, using the user permission list to transform the user request, and sending the transformation processing result to the microservice corresponding to the current user permission list specifically includes the following steps:

[0029] Receive the user permission list returned by the system service, wherein the user permission list is obtained by the system service based on the user basic information query, and each user permission list corresponds to one piece of the user basic information as the information source and at least one of the microservices as the information processor;

[0030] The user permission list is stored in the user request, a transformation processing result is obtained, and the transformation processing result is sent to the microservice corresponding to the current user permission list.

[0031] By adopting the above technical solution, a user request with authority is obtained, and the user request will access the microservice corresponding to the authority it has. The step of obtaining authority is set before entering the microservice end, making the code of the microservice end more streamlined, meeting the ease of use of the microservice end, making the request process more modular, and more conducive to the maintenance of application services.

[0032] In a second aspect, the present application provides a bill verification device, which adopts the following technical solution:

[0033] A bill verification device includes the following modules:

[0034] A user request receiving module, used for receiving a user request sent by a client, performing rule matching on the user request, and forwarding the user request to a request interception unit corresponding to the rule matching result according to the rule matching result;

[0035] A ticket information comparison module, used to obtain the interception processing results returned by each of the request interception units, extract the ticket information contained in the interception processing results and compare the information with the pre-stored ticket stub, and when the information comparison is consistent, read the user basic information corresponding to the ticket stub, and send the user basic information to the system service;

[0036] The user request transformation module is used to receive the user permission list returned by the system service, transform the user request using the user permission list, and send the transformation processing result to the microservice corresponding to the current user permission list.

[0037] Preferably, the bill verification device further includes the following modules:

[0038] The user login verification module is used to respond to the login request sent by the client, and use the user login information contained in the login request to verify the client. When the login verification is successful, the user basic information is extracted from the login request and summarized into an information object, the information object is encrypted to obtain a ticket stub, and the matching user basic information and the ticket stub are saved in pairs.

[0039] By adopting the above technical solutions, a complete user ticket verification system has been built, which provides the necessary software technical support for ticket identity verification of different types of users and meets the requirements of technological progress.

[0040] In a third aspect, the present application provides a smart terminal, which adopts the following technical solution:

[0041] An intelligent terminal includes a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the bill verification method as described above.

[0042] In a fourth aspect, the present application provides a computer-readable storage medium, which adopts the following technical solution:

[0043] A computer-readable storage medium stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the bill verification method as described above.

[0044] In summary, this application has at least the following beneficial effects:

[0045] (1) This application uses the technical means of uniformly verifying user permissions at the gateway layer and then forwarding the requests to the back-end microservices to achieve the purpose of taking different functional permissions for processing according to different user identities, increasing the flexibility of the entire system configuration, improving the usability of the program, and making the program more powerful and comprehensive;

[0046] 1. This application ensures the security of the entire system by hiding the microservice behind the gateway, ensuring the security of the microservice end and avoiding unauthorized user access, thereby ensuring the security of user data;

[0047] (3) By adding various interception processing devices at the gateway layer, this application avoids the interaction between user requests and each microservice, reduces code redundancy in microservices, reduces development and maintenance costs, and improves system performance and scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 It is a flowchart of the bill verification method of an embodiment of the present application;

[0049] Figure 2 It is a structural diagram of a bill verification device according to an embodiment of the present application. DETAILED DESCRIPTION

[0050] The present application provides a ticket verification method, device, terminal and storage medium for different types of user identities based on a request address. In order to make the purpose, technical solution and advantages of the present application clearer, the implementation method of the present application will be further described in detail below.

[0051] The following is a further detailed description of an embodiment of a ticket verification method, device, terminal and storage medium for different types of user identities based on a request address of the present application in conjunction with the drawings of the specification.

[0052] A bill verification method of this application, the process is as follows Figure 1 As shown, the following steps are included:

[0053] S1. Respond to the login request sent by the client and use the user login information contained in the login request to verify the client login. The login request contains the user login information and user basic information. The user login information includes the account number, mobile phone number, email account, password and verification code entered by the user.

[0054] When the login verification succeeds, the user's basic information is extracted from the login request and summarized into an information object. The information object is encrypted to obtain a bill stub in the form of a string. The matching user basic information and bill stub are saved in pairs. In an practicable implementation, the user's basic information is stored in a JSON object, and this object is encrypted into a bill string using the RSA encryption algorithm. The bill string and the user's basic information are stored in Redis as a hash table key-value pair. The bill string is returned to the client, and each subsequent request sent by the client carries this bill string as an identity credential.

[0055] When the login verification fails, an error code indicating that the user has not logged in is returned, and the user is redirected to the login page.

[0056] S2. Receive the user request sent by the client, perform rule matching on the user request, and forward the user request to the request interception unit corresponding to the rule matching result according to the rule matching result. This step specifically includes the following process.

[0057] S21. Receive a user request, read the IP address information of the client that is the sender of the current user request, and the request address information and request header information contained in the user request.

[0058] S22. Extract IP address matching rules, request address matching rules and request header matching rules from the pre-configured configuration files respectively, match the IP address information with the IP address matching rules, match the request address information with the request address matching rules, match the request header information with the request header matching rules, generate rule matching results based on the items and quantity of successful rule matching, and forward the user request to the request interception unit corresponding to the rule matching result.

[0059] This step mainly accepts user requests, parses the IP address, request address and request header in the user request, matches the parsed content with the rules in the configuration file, and determines the request interception unit to which the user request needs to be forwarded.

[0060] S3. Obtain the interception processing results returned by each request interception unit, extract the ticket information contained in the interception processing results and compare the information with the pre-stored ticket stub. When the information comparison is consistent, read the user basic information corresponding to the ticket stub, and send the user basic information to the system service. This step specifically includes the following process.

[0061] S31. Obtain the interception processing results returned by each request interception unit respectively. The interception processing results correspond to at least one interception rule. Each interception processing result is a user request that has passed through and been processed by the corresponding request interception unit.

[0062] The interception rules in this embodiment include at least:

[0063] The first interception processing rule determines whether the IP address information satisfies the IP address matching rule and whether the request address information satisfies the request address matching rule. If any one of the items is not satisfied, the current user request is intercepted.

[0064] The specific interception process is as follows: when the IP address of the user request does not meet the IP address matching rules, or the request address does not meet the request address matching rules, the current user request is intercepted, the user request is not allowed to access the specific service, and an error code of access denial is directly returned. When the IP address of the user request meets the IP address matching rules and the request address meets the request address matching rules, the current user request passes the interception, a header tag is added to the current user request, and the current user request is released to the next interception processing rule for judgment.

[0065] The second interception processing rule reads the request header information, which contains any one or more of the ticket validity mark, encryption mark, one-time request mark and simulation identity mark, and determines whether each mark in the request header information meets the request header matching rules. When any one of them does not meet the rules, the user request is intercepted.

[0066] The specific interception process is as follows: When the request header of the user request contains a ticket validity mark and matches the matching rules in the request header, the current user request is intercepted, and the ticket information of the current user request is destroyed when the agreed time limit is reached. When the request header of the user request contains an encryption mark and matches the matching rules in the request header, the current user request is intercepted, and the current user request is decrypted according to the agreed secret key. When the decryption is successful, the decryption result is put back into the user request. When the request header of the user request contains a one-time request mark and matches the matching rules in the request header, the current user request is intercepted, and a mark is added to the current user request. After the user request is completed, the ticket information of the current user request is destroyed. When the request header of the user request contains an impersonation identity mark and matches the matching rules in the request header, the current user request is intercepted, and the basic information of the impersonated user is obtained and put into the user request.

[0067] It should be noted that when any of the tags in the above request header information is empty or any of the matching rules matching it is empty, the user request is intercepted by default.

[0068] S32, extract the ticket information contained in the interception processing result, compare the ticket information with the ticket stub, and when the information is consistent, read the pre-stored user basic information corresponding to the ticket stub and send it to the system service. If the information is inconsistent, the gateway will determine that the current ticket is illegal, and will not allow the user to request access to the actual service, and directly return an error code for access denial.

[0069] It should be noted that when the request header of the user request carries a ticket validity mark or a one-time request mark, the validity of the ticket information must be confirmed before the information is compared. If the ticket is expired, there is no need to compare the information. The gateway directly rejects the current user request and returns an error code denying access.

[0070] S4. Receive the user permission list returned by the system service, use the user permission list to transform the user request, and send the transformation processing result to the microservice corresponding to the current user permission list. This step specifically includes the following process.

[0071] S41. Receive a user permission list returned by the system service. The user permission list is obtained by the system service based on a query of the user's basic information. Each user permission list corresponds to a piece of basic information of the user as the information source and at least one microservice as the information processor.

[0072] S42, storing the user permission list in the form of a string in the request header part of the user request and the reserved blank field, obtaining the transformation processing result, and sending the transformation processing result to the microservice corresponding to the current user permission list.

[0073] This step obtains the corresponding permissions of the user based on the user's basic information, stores the user's permissions in the user request, and obtains the authorized user request. The user request will access the microservice corresponding to the permissions it has.

[0074] Based on the same inventive concept as above, the present application also discloses a bill verification device, the structure of which is as follows: Figure 2 As shown, the device includes the following modules:

[0075] The user login verification module is used to respond to the login request sent by the client, and use the user login information contained in the login request to verify the client. When the login verification is successful, the user's basic information is extracted from the login request and summarized into an information object, the information object is encrypted, and a ticket stub is obtained. The matching user basic information and ticket stub are saved in pairs.

[0076] The user request receiving module is used to receive the user request sent by the client, perform rule matching on the user request, and forward the user request to the request interception unit corresponding to the rule matching result according to the rule matching result.

[0077] The ticket information comparison module is used to obtain the interception processing results returned by each request interception unit, extract the ticket information contained in the interception processing results and compare the information with the pre-stored ticket stub. When the information comparison is consistent, read the user basic information corresponding to the ticket stub and send the user basic information to the system service.

[0078] The user request transformation module is used to receive the user permission list returned by the system service, use the user permission list to transform the user request, and send the transformation processing result to the microservice corresponding to the current user permission list.

[0079] In a specific implementation scheme, the user login verification module includes the following units:

[0080] The user login verification first unit is used to respond to the login request sent by the client and use the user login information included in the login request to perform login verification on the client.

[0081] The second user login verification unit is used to encrypt the user's basic information and save the encrypted ticket information and the user's basic information in pairs.

[0082] In a specific implementation scheme, the user request receiving module includes the following units:

[0083] The first user request receiving unit is used to receive the user request, read the IP address information of the client as the sender of the current user request and the request address information and request header information contained in the user request.

[0084] The user request receiving second unit is used to extract IP address matching rules, request address matching rules and request header matching rules from the pre-configured configuration files respectively, match the IP address information with the IP address matching rules, match the request address information with the request address matching rules, match the request header information with the request header matching rules, generate rule matching results based on the items and quantity of successful rule matching, and forward the user request to the request interception unit corresponding to the rule matching results.

[0085] In a specific implementation scheme, the bill information comparison module includes the following units:

[0086] The first ticket information comparison unit is used to intercept and process each obtained user request according to the interception rule.

[0087] The second ticket information comparison unit is used to obtain the interception processing results returned by each request interception unit. The interception processing result corresponds to at least one interception rule. Each interception processing result is a user request that passes through the corresponding request interception unit and is processed by the request interception unit.

[0088] The third ticket information comparison unit is used to extract the ticket information contained in the interception processing result, compare the ticket information with the ticket stub, and when the information comparison is consistent, read the pre-stored user basic information corresponding to the ticket stub and send it to the system service.

[0089] In a specific implementation scheme, the first unit of bill information comparison includes the following subunits:

[0090] The first sub-unit of the ticket information comparison is used to determine whether the IP address information meets the IP address matching rules and whether the request address information meets the request address matching rules. When any one of them is not met, the current user request is intercepted.

[0091] The first subunit of the ticket information comparison includes an IP address filter device and a request address filter device. When the IP address requested by the user does not meet the IP address matching rules, or the request address does not meet the request address matching rules, the IP address filter intercepts the current user request, does not allow the user to request access to a specific service, and directly returns an error code denying access.

[0092] When the IP address of the user request meets the IP address matching rules and the request address meets the request address matching rules, the IP address filter adds a header tag to the current user request, and forwards the current user request to match the request header information based on the premise of meeting the request address matching rules.

[0093] The second sub-unit of the ticket information comparison is used to read the request header information, which contains any one or more of the ticket validity mark, encryption mark, one-time request mark and simulation identity mark, and judge whether each mark in the request header information meets the request header matching rules. When any one does not meet the rules, the current user request is intercepted.

[0094] The second sub-unit of the ticket information comparison includes a request header filter device. When the request header of the user request contains a ticket validity mark and matches the request header matching rule, the ticket information requested by the current user is destroyed after the agreed time limit is reached. When the request header of the user request contains an encryption mark and matches the request header matching rule, the request header filter decrypts the current user request according to the agreed secret key. When the decryption is successful, the decryption result is put back into the user request. When the request header of the user request contains a one-time request mark and matches the request header matching rule, the request header filter adds a mark to the current user request and destroys the ticket information requested by the current user after the user request is completed. When the request header of the user request contains a simulated identity mark and matches the request header matching rule, the request header filter obtains the basic information of the simulated user through the simulated user id and puts it into the user request.

[0095] In a specific implementation scheme, the user request transformation module includes the following units:

[0096] The user requests to modify the first unit, which is used to receive the user permission list returned by the system service. The user permission list is obtained by the system service based on the user's basic information query. Each user permission list corresponds to a user's basic information as the information source and at least one microservice as the information processor.

[0097] The user request transforms the second unit, which is used to store the user permission list in the user request, obtain the transformation processing result, and send the transformation processing result to the microservice corresponding to the current user permission list.

[0098] It can be seen from the above embodiments that the ticket verification device of the present application for different types of user identities based on the request address has built a complete user ticket verification system, provided the necessary software technical support for ticket identity verification of different types of users, and met the requirements of technological progress.

[0099] Based on the same inventive concept mentioned above, an embodiment of the present application also discloses an intelligent terminal, including a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the ticket verification method as described above.

[0100] Also based on the same inventive concept mentioned above, an embodiment of the present application also discloses a computer-readable storage medium, which stores at least one instruction, at least one program, code set or instruction set. The at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the bill verification method as described above.

[0101] A person skilled in the art can understand that all or part of the steps of implementing the above embodiments can be completed by hardware, or can be completed by a program to instruct related hardware. The program can be stored in a computer-readable storage medium, and the computer-readable storage medium includes, for example: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0102] The above description is only an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A bill verification method, characterized in that: The steps include: Receiving a user request sent by a client, performing rule matching on the user request, and forwarding the user request to a request interception unit corresponding to the rule matching result according to the rule matching result, specifically includes the following steps: Receive the user request, read the IP address information of the client as the sender of the current user request and the request address information and request header information contained in the user request; Extracting IP address matching rules, request address matching rules and request header matching rules from pre-configured configuration files respectively, matching the IP address information with the IP address matching rules, matching the request address information with the request address matching rules, matching the request header information with the request header matching rules, generating the rule matching results according to the items and the number of successful rule matching, and forwarding the user request to the request interception unit corresponding to the rule matching results; Obtaining the interception processing results returned by each of the request interception units, extracting the ticket information contained in the interception processing results and comparing the information with the pre-stored ticket stub, when the information comparison is consistent, reading the user basic information corresponding to the ticket stub, and sending the user basic information to the system service, specifically includes the following steps: Respectively obtain the interception processing results returned by each of the request interception units, the interception processing results corresponding to at least one interception rule, each of the interception processing results is the user request after passing through the corresponding request interception unit and being processed by the request interception unit, and the interception rules at least include a first interception processing rule, which determines whether the IP address information satisfies the IP address matching rule and whether the request address information satisfies the request address matching rule. When any one of the items is not satisfied, the current user request is intercepted; The second interception processing rule is to read the request header information, which contains any one or more of the ticket validity mark, encryption mark, one-time request mark and simulation identity mark, and respectively determine whether each mark in the request header information satisfies the request header matching rule. When any one of the marks in the request header information is empty or any one of the matching rules is empty, the user request is intercepted by default. Extract the ticket information contained in the interception processing result, compare the ticket information with the ticket stub, and when the information is consistent, read the pre-stored user basic information corresponding to the ticket stub and send it to the system service; when the request header of the user request carries a ticket validity mark or a one-time request mark, the validity of the ticket information needs to be confirmed before the information comparison, and if the ticket is expired, no information comparison is required; Receive the user permission list returned by the system service, use the user permission list to transform the user request, and send the transformation processing result to the microservice corresponding to the current user permission list.

2. The bill verification method according to claim 1, characterized in that: Before receiving the user request sent by the client, the method further includes the following steps: In response to the login request sent by the client, the client is authenticated using the user login information contained in the login request. When the login verification is successful, the basic user information is extracted from the login request and summarized into an information object, the information object is encrypted to obtain a ticket stub, and the matching basic user information and the ticket stub are saved in pairs.

3. The bill verification method according to claim 1, characterized in that: The receiving the user permission list returned by the system service, transforming the user request by using the user permission list, and sending the transformation result to the microservice corresponding to the current user permission list specifically includes the following steps: Receive the user permission list returned by the system service, wherein the user permission list is obtained by the system service based on the user basic information query, and each user permission list corresponds to one piece of the user basic information as the information source and at least one of the microservices as the information processor; The user permission list is stored in the user request, a transformation processing result is obtained, and the transformation processing result is sent to the microservice corresponding to the current user permission list.

4. A bill verification device, characterized in that: Includes the following modules: A user request receiving module, used for receiving a user request sent by a client, performing rule matching on the user request, and forwarding the user request to a request interception unit corresponding to the rule matching result according to the rule matching result; The user request receiving module includes the following units: A first user request receiving unit is used to receive a user request, read the IP address information of the client as the sender of the current user request and the request address information and request header information contained in the user request; The second user request receiving unit is used to extract IP address matching rules, request address matching rules and request header matching rules from the pre-configured configuration files, match the IP address information with the IP address matching rules, match the request address information with the request address matching rules, match the request header information with the request header matching rules, generate a rule matching result according to the items and quantity of successful rule matching, and forward the user request to the request interception unit corresponding to the rule matching result; A ticket information comparison module, used to obtain the interception processing results returned by each of the request interception units, extract the ticket information contained in the interception processing results and compare the information with the pre-stored ticket stub, and when the information comparison is consistent, read the user basic information corresponding to the ticket stub, and send the user basic information to the system service; The bill information comparison module includes the following units: The first ticket information comparison unit is used to intercept and process each user request obtained according to the interception rule; The first unit of bill information comparison includes the following subunits: The first subunit of ticket information comparison is used to determine whether the IP address information meets the IP address matching rules and whether the request address information meets the request address matching rules. If any one of them is not met, the current user request is intercepted; The second subunit of ticket information comparison is used to read the request header information, which contains any one or more of the ticket validity mark, encryption mark, one-time request mark and simulation identity mark, and respectively judge whether each mark in the request header information meets the request header matching rule. When any one of them is not satisfied, the current user request is intercepted. When any one of the marks in the request header information is empty or any one of the matching rules matching it is empty, the user request is intercepted by default; The second ticket information comparison unit is used to obtain the interception processing results returned by each request interception unit, the interception processing results correspond to at least one interception rule, and each interception processing result is a user request that has passed through the corresponding request interception unit and has been processed by the request interception unit; The third ticket information comparison unit is used to extract the ticket information contained in the interception processing result, compare the ticket information with the ticket stub, and when the information is consistent, read the pre-stored user basic information corresponding to the ticket stub and send it to the system service; when the request header of the user request carries a ticket validity mark or a one-time request mark, the validity of the ticket information needs to be confirmed before the information comparison. If the ticket is expired, no information comparison is required; The user request transformation module is used to receive the user permission list returned by the system service, transform the user request using the user permission list, and send the transformation processing result to the microservice corresponding to the current user permission list.

5. The bill verification device according to claim 4, characterized in that: Also includes the following modules: A user login verification module is used to respond to a login request sent by a client and perform login verification on the client using the user login information contained in the login request. When the login verification is successful, the basic user information is extracted from the login request and summarized into an information object, the information object is encrypted to obtain a ticket stub, and the matching basic user information and the ticket stub are saved in pairs.

6. An intelligent terminal, characterized in that: It comprises a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the bill verification method as described in any one of claims 1 to 3.

7. A computer-readable storage medium, characterized in that: The readable storage medium stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the bill verification method as described in any one of claims 1 to 3.

Images