Transaction data processing method, device and server

Abstract

This specification provides a method, device and server for processing transaction data, which can be used in the financial field. Based on this method, before specific implementation, a microservice gateway based on a microservice architecture associated with the target client application can be deployed between the server and the user terminal; and at least the authority authentication service can be integrated into the microservice gateway. During specific implementation, when the target user logs in to the target client application and triggers the target transaction business service therein to generate a corresponding target transaction business request, the microservice gateway can receive and respond to the target transaction business request instead of the server, and call the authority authentication service according to the preset business authority management rules to complete the authority verification for different transaction business services. In this way, the authority verification of related transaction business services under the microservice architecture can be realized efficiently and accurately, vertical overreach can be avoided, and the data security of related transaction businesses can be protected; at the same time, user operations can be simplified, so that users can have a better interactive experience.

Description

Technical Field

[0001] This specification belongs to the field of data security technology, and in particular to a method, device, and server for processing transaction data. Background Art

[0002] In financial transaction business scenarios, banks and other trading institutions usually use microservices architecture to develop and publish client applications that include multiple transaction business services in combination with the transaction business services they provide.

[0003] However, to prevent vertical privilege escalation, existing methods require developers to individually write and configure permission verification logic for each transaction service. This approach results in a relatively large amount of code development and high code management and maintenance costs. Furthermore, users must perform a separate permission verification each time a transaction service is triggered, which complicates operations and impacts the user experience.

[0004] To address the above issues, no effective solutions have been proposed so far. Summary of the Invention

[0005] This specification provides a transaction data processing method, device and server, which can efficiently and accurately implement permission verification of related transaction business services under the microservice architecture, avoid vertical overreach, and protect the data security of related transaction businesses; at the same time, it can also effectively reduce the overall data processing cost, simplify user operations, and enable users to obtain a better interactive experience.

[0006] This specification provides a transaction data processing method applied to a microservices gateway, wherein the microservices gateway is associated with a target client application; the target client application includes multiple transaction business services; the microservices gateway is deployed between a server and a user terminal, and the microservices gateway is integrated with at least an authorization authentication service. The method includes:

[0007] Receive a target transaction service request; wherein the target transaction service request is generated by the user terminal upon detecting that the target user has logged into the target client application and triggering the corresponding target transaction service; the target transaction service request carries at least a login token of the target user and a transaction identifier of the target transaction service;

[0008] Respond to the target transaction business request and verify the validity of the target user's login token by querying the Redis cache of the permission authentication service according to the preset business permission management rules;

[0009] If the target user's login token is verified to be valid, the system checks whether the target transaction service is a transaction service that prevents vertical overreach based on the preset business authority management rules and the transaction ID of the target transaction service.

[0010] If it is determined that the target transaction business service is a transaction business service that prevents vertical overreach, the permission parameters of the target transaction business service and the permission data group of the target user are obtained through the permission authentication service according to the preset business permission management rules;

[0011] According to the preset business authority management rules, authority matching is performed using the authority parameters of the target transaction business service and the authority data group of the target user;

[0012] When it is determined that the authority match is passed, the target transaction business request is forwarded to the corresponding target business server; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

[0013] In one embodiment, the microservice gateway is also associated with a login verification service of a target client application;

[0014] Accordingly, before receiving the target transaction service request, the method further includes:

[0015] Receive a target login request for a target client application; wherein the target login request carries at least an identity identifier and login credentials of a target user;

[0016] Call the login verification service to perform login verification on the target user according to the target login request;

[0017] If the target user passes the login verification, call the login verification service to generate a login token corresponding to the target user;

[0018] Call the permission authentication service to authenticate the target user according to the target user's identity and obtain the target user's permission data group;

[0019] After associating the target user's identity, the target user's permission data group with the target user's login token, they are stored in the redis cache of the permission authentication service.

[0020] In one embodiment, after calling the login verification service to generate a login token corresponding to the target user, the method further includes:

[0021] Determine the validity period and generation time of the target user's login token;

[0022] Generate a corresponding validity tag based on the validity period and generation time of the login token;

[0023] Add a validity tag to the target user's login token.

[0024] In one embodiment, according to the preset business authority management rules, the validity of the target user's login token is verified by querying the redis cache of the authority authentication service, including:

[0025] According to the preset business permission management rules, check whether the target user's login token exists in the Redis cache of the permission authentication service;

[0026] If the target user's login token is found in the Redis cache of the authentication service, obtain the validity tag and current time of the target user's login token;

[0027] Check whether the target user's login token is currently valid based on the target user's login token's valid tag and current time;

[0028] When it is determined that the login token of the target user is currently valid, it is determined that the validity verification of the login token of the target user is passed.

[0029] In one embodiment, in response to the target transaction service request, after verifying the validity of the target user's login token by querying the Redis cache of the authority authentication service according to the preset business authority management rules, the method further includes:

[0030] If it is determined that the target user's login token validity verification fails, a first error message is generated;

[0031] Send a first error notification to the target client application.

[0032] In one embodiment, the target user's permission data group includes: basic information of the target user, a role tag of the target user, and permission parameters of the target user.

[0033] In one embodiment, according to preset business authority management rules, authority matching is performed using the authority parameters of the target transaction business service and the authority data group of the target user, including:

[0034] According to the preset business authority management rules, check whether the authority parameters of the target transaction business service match the authority parameters of the target user;

[0035] If it is determined that the permission parameters of the target transaction business service match the permission parameters of the target user, detecting whether the role tag of the target user matches the target transaction business service;

[0036] When it is determined that the role tag of the target user matches the target transaction business service, it is determined that the permission matching is passed.

[0037] In one embodiment, after performing permission matching based on the preset business permission management rules using the permission parameters of the target transaction business service and the permission data set of the target user, the method further includes:

[0038] If it is determined that the permission match fails, a second error message is generated;

[0039] Send a second error message to the target client application.

[0040] In one embodiment, the method further comprises:

[0041] Get the gateway log of the microservice gateway in the current time period at every preset time period;

[0042] Based on key fields, the gateway logs for the current time period are split into a success data set for successful transaction service calls and a failure data set for failed transaction service calls.

[0043] Generating rule update data regarding preset business authority management rules based on the success data set and / or failure data set;

[0044] The rule update data is sent to a management terminal; wherein the management terminal updates a preset service authority management rule according to the rule update data.

[0045] In one embodiment, generating rule update data for preset business authority management rules based on the success data set and / or the failure data set includes:

[0046] Count the number of log records in the successful data set that lack login token validity verification; and count the frequency of successful calls to transaction business services in the current time period;

[0047] Determine whether the rule update conditions are met based on the number of log records in the successful data set that lack login token validity verification and the frequency of successful transaction business service calls in the current time period;

[0048] When it is determined that the rule update conditions are met, a first type of sub-rule for adding or supplementing token validity verification is generated as rule update data for the preset business authority management rules.

[0049] In one embodiment, generating rule update data for preset business authority management rules based on the success data set and / or the failure data set further includes:

[0050] Based on the successful data set, count the frequency of successful calls to each transaction business service based on each target client application within the current time period;

[0051] Based on the frequency of successful calls to each transaction service by each target client application in the current time period, detecting whether at least one transaction service has a frequency of successful calls greater than a preset reference threshold in the current time period;

[0052] When it is determined that there is at least one transaction business service whose frequency of successful calls in the current time period is greater than a preset reference threshold, it is determined that the rule update conditions are met; and a second type of sub-rule for adding or updating permission matching rules for the transaction business service is generated as rule update data for the preset business permission management rules.

[0053] This specification also provides a transaction data processing device, which is applied to a microservice gateway, wherein the microservice gateway is associated with a target client application; the target client application includes multiple transaction business services; the microservice gateway is deployed between a server and a user terminal, and the microservice gateway is integrated with at least an authorization authentication service. The device includes:

[0054] a receiving module configured to receive a target transaction service request; wherein the target transaction service request is generated by a user terminal upon detecting that a target user has logged into a target client application and triggering a corresponding target transaction service; the target transaction service request carries at least a login token of the target user and a transaction identifier of the target transaction service;

[0055] The validity verification module is used to respond to the target transaction business request and verify the validity of the target user's login token by querying the Redis cache of the permission authentication service according to the preset business permission management rules;

[0056] A detection module is used to detect whether the target transaction service is a transaction service that prevents vertical overreach based on preset business authority management rules and the transaction identifier of the target transaction service, if the target user's login token is verified to be valid.

[0057] An acquisition module is used to obtain the permission parameters of the target transaction business service and the permission data group of the target user through the permission authentication service according to the preset business permission management rules when determining that the target transaction business service is a transaction business service that prevents vertical overreach;

[0058] The permission matching module is used to perform permission matching based on the preset business permission management rules, using the permission parameters of the target transaction business service and the permission data group of the target user;

[0059] The forwarding module is used to forward the target transaction business request to the corresponding target business server when it is determined that the authority match is passed; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

[0060] This specification also provides a server, including a processor and a memory for storing processor-executable instructions, wherein the processor implements relevant steps of the transaction data processing method when executing the instructions.

[0061] This specification also provides a computer-readable storage medium having computer instructions stored thereon, which implement the steps of the transaction data processing method when executed by a processor.

[0062] This specification also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the transaction data processing method are implemented.

[0063] Before implementation, a microservices gateway based on a microservices architecture and associated with a target client application can be deployed between the server and the user terminal based on the transaction data processing method, device, and server provided in this specification. At least the permission authentication service can be integrated into the microservices gateway. Furthermore, the login verification service of the target client application can be associated with the microservices gateway. In specific implementation, when the target user logs in to the target client application and triggers the target transaction business service therein to generate the corresponding target transaction business request, the microservice gateway can directly receive the target transaction business request instead of the server, and verify the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules; when it is determined that the validity verification is passed, the microservice gateway detects whether the target transaction business service belongs to the anti-vertical overreach transaction business service according to the preset business authority management rules and the transaction identifier of the target transaction business service; if it does, then according to the preset business authority management rules, through the authority authentication service, obtain the authority parameters of the target transaction business service and the authority data group of the target user; then according to the preset business authority management rules, use the authority parameters of the target transaction business service and the authority data group of the target user to perform authority matching; when it is determined that the authority matching is passed, the target transaction business request is forwarded to the corresponding target business server to call the corresponding target transaction business for corresponding transaction data processing. This enables efficient and accurate permission verification of related transaction business services under the microservice architecture, avoids vertical overreach, and protects the data security of related transaction businesses; at the same time, it can also effectively reduce overall data processing costs, simplify user operations, and enable users to obtain a better interactive experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the embodiments of this specification, the following is a brief introduction to the drawings required for use in the embodiments. The drawings described below are only some of the embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0065] Figure 1 is a flowchart of a method for processing transaction data provided by an embodiment of this specification;

[0066] Figure 2 This is a schematic diagram of an embodiment of a method for processing transaction data provided by an embodiment of this specification, in a scenario example;

[0067] Figure 3 This is a schematic diagram of an embodiment of a method for processing transaction data provided by an embodiment of this specification, in a scenario example;

[0068] Figure 4 This is a schematic diagram of an embodiment of a method for processing transaction data provided by an embodiment of this specification, in a scenario example;

[0069] Figure 5 This is a schematic diagram of an embodiment of a method for processing transaction data provided by an embodiment of this specification, in a scenario example;

[0070] Figure 6 This is a schematic diagram of an embodiment of a method for processing transaction data provided by an embodiment of this specification, in a scenario example;

[0071] Figure 7 This is a schematic diagram of the structure of a server provided by an embodiment of this specification;

[0072] Figure 8 This is a schematic diagram of the structure of a transaction data processing device provided by an embodiment of this specification;

[0073] Figure 9 This is a schematic diagram of an embodiment of a method for processing transaction data provided by an embodiment of this specification, in a scenario example. DETAILED DESCRIPTION

[0074] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0075] It should be noted that the user-related information and data involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by relevant parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users or relevant parties to choose to authorize or refuse.

[0076] It should also be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. They should be regarded as exemplary and their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0077] See Figure 1As shown, the embodiments of this specification provide a method for processing transaction data. The method is specifically applied to a microservice gateway. The microservice gateway is associated with a target client application; the target client application includes multiple transaction business services; the microservice gateway is deployed between a server and a user terminal, and the microservice gateway integrates at least an authorization authentication service. The specific implementation of the method may include the following:

[0078] S101: Receive a target transaction service request; wherein the target transaction service request is generated by a user terminal upon detecting that a target user has logged into a target client application and triggered a corresponding target transaction service; the target transaction service request carries at least a login token of the target user and a transaction identifier of the target transaction service;

[0079] S102: Respond to the target transaction business request and verify the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules;

[0080] S103: If the target user's login token is verified to be valid, detect whether the target transaction service is a transaction service that prevents vertical overreach based on the preset business authority management rules and the transaction identifier of the target transaction service;

[0081] S104: When it is determined that the target transaction business service is a transaction business service that prevents vertical overreach, obtaining permission parameters of the target transaction business service and a permission data set of the target user through a permission authentication service according to preset business permission management rules;

[0082] S105: Performing permission matching based on the preset business permission management rules using the permission parameters of the target transaction business service and the permission data group of the target user;

[0083] S106: When it is determined that the authority match is passed, the target transaction service request is forwarded to the corresponding target service server; wherein, the target service server receives and responds to the target transaction service request to perform corresponding transaction data processing.

[0084] The target client application may be specifically understood as a user-oriented front-end interface (API) application built and developed based on a microservice architecture.

[0085] The microservices architecture described above can be understood as a service architecture pattern that splits an application into multiple small business services. Each business service, as a microservice, runs in its own process and communicates with other services through corresponding business interfaces (APIs).

[0086] Specifically, the target client application may include multiple related transaction services, such as financial management services, savings services, loan services, etc. The target client application may be installed and deployed locally on the user terminal held by the target user.

[0087] Each transaction service can correspond to a service interface (API), which can be used to connect to the service server responsible for the transaction service. Accordingly, users can trigger the transaction service in the target client application, call the corresponding service interface, and interact with the corresponding service server to implement the specific transaction service.

[0088] The microservices gateway described above can be specifically understood as an API gateway based on a microservices architecture, providing a unified access point for each transactional service within the microservices architecture. Users can access and invoke corresponding transactional services through the microservices gateway using their user terminals. The microservices gateway can then perform operations such as routing and filtering requests from user terminals. Specifically, for example, the microservices gateway described above can be a Zuul gateway.

[0089] Specifically, the microservice gateway may be integrated with a permission authentication service based on the target client application; at the same time, it may also be associated with the login verification service of the target client.

[0090] Specifically, the microservice gateway may be configured with preset business authority management rules, wherein the preset business authority management rules may cover multiple transaction business services included in the target client application.

[0091] Correspondingly, during specific implementation, the microservice gateway can complete the corresponding permission verification by jointly calling the login verification service and the permission authentication service according to the preset business permission management rules.

[0092] The aforementioned permission authentication service can be specifically understood as a target client application-based authentication service for the identity and authority of the user and the transaction service. The aforementioned login verification service can be specifically understood as a target client application-based service for verifying the identity of the logged-in user.

[0093] The target user's login token can be specifically understood as a data identifier that can prove the target user's relevant identity information when the target user logs in to the target client application and is generated by the login verification service when the target user passes the login verification.

[0094] In specific implementation, when a target user wants to process transaction data based on the target transaction service, they can first log in to the target client application deployed on the user terminal. Then, they can operate in the target client application to trigger the target transaction service and generate and initiate the corresponding target transaction service request.

[0095] The above target transaction business request will not be sent directly to the corresponding server, but will be sent to the microservice gateway first.

[0096] After receiving the target transaction business request, the microservice gateway will use the permission authentication service according to the preset business permission management rules, combined with the data stored when the target user previously logged into the target client application, to verify the validity of the login token, detect the anti-vertical overreach of the target transaction business, and match the target user's permissions for the target transaction business to achieve corresponding permission verification.

[0097] Only when the final permission verification is passed will the microservice gateway forward the target transaction business request to the corresponding server for specific transaction data processing.

[0098] The server may specifically include a backend server applied to the trading platform that implements functions such as data transmission and data processing. Specifically, the server may be, for example, an electronic device with data computing, storage, and network interaction capabilities. Alternatively, the server may be a software program running on the electronic device that provides support for data processing, storage, and network interaction. In this embodiment, the number of servers is not specifically limited. The server may be a single server, several servers, or a server cluster consisting of several servers.

[0099] The user terminal may include a front end that is applied to the user side and can realize functions such as data collection and data transmission. Specifically, the user terminal may be, for example, an electronic device such as a desktop computer, a tablet computer, a laptop computer, or a smart phone.

[0100] Based on the above embodiments, there is no need to separately configure and run corresponding permission verification logic for different transaction business services, which avoids duplicate code and reduces the overall data processing cost; the microservice gateway performs permission verification instead of the server, which effectively reduces the workload on the server side on the one hand, and on the other hand, avoids direct connection of the server to requests whose security cannot be determined, so as to better protect the transaction business data security on the server side; in addition, by associating the login verification service and the permission authentication service with the microservice gateway, the microservice gateway can complete the permission verification by jointly calling the login verification service and the permission authentication service. In this way, when the user successfully logs in to the target client application, when any different transaction business service is triggered, the microservice gateway can efficiently implement the corresponding permission verification, and does not require the user to perform other additional verification operations, thereby simplifying user operations and allowing users to obtain a better interactive experience.

[0101] In some embodiments, the transaction identifier is used to indicate the target transaction service triggered by the target user.

[0102] Specifically, the transaction identifier may be a transaction number corresponding to the target transaction business, or an interface number of a business interface corresponding to the target transaction business.

[0103] In some embodiments, the authorization authentication service is further configured with a preset transaction identification list. This preset transaction identification list includes transaction identifications for transaction services that require protection against vertical overreach. This preset transaction identification list can be generated by the trading platform based on relevant platform regulations and big data analysis results, and configured for the authorization authentication service.

[0104] The aforementioned vertical privilege escalation refers specifically to privilege escalation between users of different roles (or ranks), for example, a regular user exercising the privileges of an administrator. This type of privilege escalation can be categorized as upward privilege escalation, where a low-privileged user executes a high-privileged operation, or downward privilege escalation, where a high-privileged user executes a low-privileged operation.

[0105] During specific implementation, when it is determined that the target user's login token validity has been verified, the microservice gateway can call the authority authentication service according to the preset business authority management rules to match the transaction identifier of the target transaction business service with the preset transaction identifier list.

[0106] If the match is successful, it can be determined that the target transaction business service belongs to the transaction business service that prevents vertical overreach, which can trigger subsequent permission verification.

[0107] On the contrary, if the match fails, it can be determined that the target transaction business service does not belong to the transaction business service that prevents vertical overreach, and the target transaction business request can be directly forwarded to the corresponding target business server responsible for the target transaction business service for processing.

[0108] In some embodiments, the authorization authentication service is further configured with authorization parameters for each transaction service on the target client application. Each authorization parameter for a transaction service includes the corresponding user's role tag. The authorization parameters for these transaction services may be generated and assigned to the authorization authentication service by the trading platform based on its regulations and big data analysis results.

[0109] In some embodiments, the microservice gateway may further be associated with a login verification service of a target client application;

[0110] Accordingly, before receiving the target transaction business request, refer to Figure 2 As shown, when the method is implemented, it may also include the following contents:

[0111] S1: Receive a target login request for a target client application; wherein the target login request carries at least an identity identifier and login credentials of a target user;

[0112] S2: Call the login verification service to perform login verification on the target user according to the target login request;

[0113] S3: If the target user passes the login verification, call the login verification service to generate a login token corresponding to the target user;

[0114] S4: Call the permission authentication service to authenticate the target user according to the target user's identity and obtain the target user's permission data group;

[0115] S5: After associating the target user's identity identifier, the target user's permission data group and the target user's login token, the data is stored in the redis cache of the permission authentication service.

[0116] The target user's identity identifier may be specifically understood as identification information that can indicate the target user's identity, such as the target user's user name, user number, registered account name, etc.

[0117] The target user's login credentials may specifically include at least one of the following: the target user's login password, the target user's fingerprint pattern, the target user's voiceprint information, and the like.

[0118] During specific implementation, the target login request may also carry a terminal identifier of the user terminal (eg, MAC address, IP address, etc.).

[0119] Correspondingly, when it is determined that the target user has passed the login verification, the microservice gateway can obtain the current time, and then call the login verification service according to the encryption algorithm, using the target user's identity identifier, the terminal identifier of the user terminal, and the current time to generate a login token corresponding to the target user who has successfully logged in.

[0120] Furthermore, the microservice gateway can call the permission authentication service to query the system permission data according to the target user's identity and obtain the target user's permission data group; and authenticate the target user's permission data group; after completing the authentication, the target user's identity and the target user's authenticated and trusted permission data group can be associated with the target user's login token and stored in the redis cache of the permission authentication service, so that the subsequent microservice gateway can directly query and use the data stored in the redis cache of the permission authentication service to perform specific permission verification on the target user.

[0121] Based on the above embodiment, when the target user logs in to the target client application, the microservice gateway can first call the login verification service to perform login verification on the target user, and when it is determined that the login verification is passed, generate a login token authenticated by the login verification service; then call the permission authentication service to perform permission authentication on the target user, obtain and authenticate the permission data group of the target user in advance, and store the permission data in the redis cache of the permission authentication service, so that when the target user triggers the corresponding transaction business service in the future, the microservice gateway can directly call and use it efficiently and safely, without the need to repeatedly obtain the permission data group of the target user separately.

[0122] In some embodiments, after calling the login verification service to generate a login token corresponding to the target user, the method may further include the following when implemented:

[0123] S1: Determine the validity period and generation time of the target user's login token;

[0124] S2: Generate a corresponding validity tag based on the validity period and generation time of the login token;

[0125] S3: Add a validity tag to the target user's login token.

[0126] Based on the above embodiment, a login token can be generated that contains relatively rich information and is convenient for subsequent validity verification.

[0127] In practice, to better protect the security of relevant transaction data and prevent other users from stealing relevant information and unauthorized access to relevant transaction services after logging into the target client application, the login token can also be set as a time-sensitive data according to pre-set business permission management rules. That is, within the validity period, the user can use the login token to perform the corresponding transaction services within the scope of the corresponding permissions; after the validity period expires, the user can no longer use the login token to perform the corresponding transaction services.

[0128] Specifically, the microservice gateway can determine the validity period of the login token based on the basic information and role tags of the target user in the target user's permission data group.

[0129] For example, if the target user's basic information and role tags indicate that the target user has a high rank and is involved in more critical transaction services, the validity period of the target user's login token can be set to a shorter duration based on the preset business permission management rules. For another example, if the target user's basic information and role tags indicate that the target user has a low rank and is only involved in more routine transaction services, the validity period of the target user's login token can be set to a longer duration.

[0130] Furthermore, the microservice gateway can also determine the target user's age based on the target user's basic information; and adjust the target user's login token based on the preset business permission management rules and the target user's age. For example, it can detect whether the target user is over 60 years old. If the target user is over 60 years old, the target user is judged to be an elderly user. Considering that elderly users are generally slower than younger users in specific operations, the preset business permission management rules can be used to appropriately increase the corresponding remaining time based on the original validity period of the target user's login token to extend the validity period of the target user's login token.

[0131] In some embodiments, see Figure 3 As shown, according to the preset business permission management rules, the validity of the target user's login token is verified by querying the Redis cache of the permission authentication service. The specific implementation may include the following:

[0132] S1: Based on the preset business permission management rules, check whether the target user's login token exists in the Redis cache of the permission authentication service;

[0133] S2: If it is determined that the target user's login token exists in the Redis cache of the authentication service, obtain the validity tag and current time of the target user's login token;

[0134] S3: Check whether the target user's login token is currently valid based on the target user's login token's valid tag and current time;

[0135] S4: When it is determined that the login token of the target user is currently valid, it is determined that the validity verification of the login token of the target user has passed.

[0136] Based on the above embodiment, the microservice gateway can accurately and efficiently verify the validity of the target user's login token according to the preset business authority management rules.

[0137] In specific implementation, the validity period and generation time of the login token can be obtained according to the valid tag of the login token of the target user; then, based on the validity period, generation time, and current time of the login token, it is detected whether the login token is currently within the validity period.

[0138] If it is determined that the login token is still valid, the login token can be further verified for validity based on a corresponding encryption algorithm to determine whether the login token is authentic and legal. If it is determined that the login token is authentic and legal, the validity verification of the login token is finally determined to have passed.

[0139] In some embodiments, in response to the target transaction service request, after verifying the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules, the method may further include the following when implemented:

[0140] S1: If it is determined that the target user's login token validity verification fails, a first error message is generated;

[0141] S2: Send a first error notification to the target client application.

[0142] The first error prompt may be used to prompt the target user to log in to the target client application again.

[0143] Based on the above embodiment, when the microservice gateway determines that the target user's login token validity has not passed, it can promptly generate and send a first error prompt to prompt the target user to re-login to the target client application so that the specific operations of the corresponding transaction business service can be triggered subsequently.

[0144] In some embodiments, the target user's permission data group may include: basic information of the target user, role tags of the target user, and permission parameters of the target user.

[0145] The basic information of the target user may specifically include one or more of the following: age, name, gender, position, rank, department name, project number of the project in which the user is involved, etc.

[0146] The role label of the target user may specifically include at least one of the following: guest user, common user, query user, department administrator, system administrator, etc.

[0147] The target user's permission parameters may include transaction identifiers of transaction services that the target user has permission to operate. Specifically, the target user's permission parameters may be associated with the target user's basic information and / or role tags.

[0148] Based on the above embodiment, a target user's permission data group with relatively rich and comprehensive data information can be obtained and utilized to complete corresponding permission verification.

[0149] In specific implementation, the target user will provide the platform server with basic information of the target user during the registration phase. The platform server can extract key fields (e.g., position field, rank field, department name field, etc.) based on the target user's basic information and splice them in order to generate a type parameter group for the target user; then, based on the target user's type parameter group, query the preset user permission parameter template set and determine a matching preset user permission parameter template to generate the initial permission parameters for the target user; then, the initial permission parameters of the target user and the basic information of the target user are sent to the management terminal of the trading platform, so that the management terminal can combine the basic information of the target user and, based on the initial permission parameters, finally determine the role label and permission parameters of the target user to obtain the permission data group for the target user.

[0150] The preset user authority parameter template set may include multiple preset user authority parameter templates, each preset user authority parameter template corresponds to at least one type of parameter group, and each preset user authority parameter template includes at least a role label and an authority parameter.

[0151] Before specific implementation, a preset user authority parameter template set can be constructed in the following manner: obtain the authority parameters, role labels, and basic information of a large number of determined sample users as sample data; cluster the sample data to obtain multiple data groups; wherein each data group contains common role labels and authority parameters, and corresponds to a combination of basic information; for each data group, according to the corresponding combination of basic information, determine the corresponding type parameter group, and at the same time, according to the role labels and authority parameters contained in the data group, combined with the expert experience of the management terminal, construct a corresponding preset user authority parameter template; then establish a mapping relationship between the preset user authority parameter template and the type parameter group to construct a preset user authority parameter template set.

[0152] In some embodiments, see Figure 4 As shown, the above-mentioned authorization matching is performed based on the preset business authorization management rules using the authorization parameters of the target transaction business service and the authorization data group of the target user. The specific implementation may include:

[0153] S1: According to the preset business authority management rules, check whether the authority parameters of the target transaction business service match the authority parameters of the target user;

[0154] S2: When it is determined that the permission parameters of the target transaction business service match the permission parameters of the target user, detecting whether the role tag of the target user matches the target transaction business service;

[0155] S3: When it is determined that the role tag of the target user matches the target transaction business service, it is determined that the permission matching is passed.

[0156] Specifically, the microservice gateway may be configured with an additional association table of role tags and transaction services. The association table of role tags and transaction services may be determined by the platform server through big data analysis of the transaction behaviors of a large number of users on the trading platform.

[0157] During specific implementation, when it is determined that the permission parameters of the target transaction business service match the permission parameters of the target user, the microservice gateway can also further detect whether the target transaction business service that the target user wants to trigger the operation matches the role tag of the target user based on the association table of the above-mentioned role tags and transaction services.

[0158] If it is determined that the role tag of the target user matches the target transaction business service, it can be determined that the target user's operation of the target transaction business is within the scope of authority and is normal behavior without abnormal risks.

[0159] Conversely, if the target user's role tag is determined to be mismatched with the target transaction service, it can be determined that while the target user's access to the target transaction service is within their authorized scope, their operational behavior presents an abnormal risk. In this case, while the authorization match is passed, a corresponding risk tag will be generated for this action, enabling ongoing risk monitoring based on this tag. Furthermore, this action will be recorded and aggregated to the management terminal for further analysis and screening.

[0160] Based on the above embodiment, the microservice gateway can achieve permission matching more accurately and better protect the data security of related transaction businesses by combining two different types of matching methods according to the preset business permission management rules.

[0161] In some embodiments, after performing permission matching based on the preset business permission management rules using the permission parameters of the target transaction business service and the permission data set of the target user, the method may further include the following when implemented:

[0162] S1: If it is determined that the permission match fails, a second error message is generated;

[0163] S2: Send a second error message to the target client application.

[0164] The second error message is specifically used to prompt that the target user currently does not have the authority to operate the target transaction service.

[0165] Furthermore, the microservice gateway can also combine the permission parameters of the target transaction business service of the permission authentication service to determine the target authorization terminal responsible for authorizing the target transaction business service; and generate authorization prompt information about applying for relevant permissions for the target transaction business service from the target authorization terminal; and then add the above authorization prompt information and the address link of the target authorization terminal to the second error prompt and send it to the target client.

[0166] Based on the above embodiment, when the microservice gateway determines that the target user's permission match fails, it can promptly generate and send a second error prompt to prompt the target user that he currently does not have permission to operate the target transaction business service.

[0167] In some embodiments, see Figure 5 As shown, when the method is implemented, it may also include the following contents:

[0168] S1: Get the gateway log of the microservice gateway in the current time period at every preset time period;

[0169] S2: Split the gateway logs for the current time period into a success dataset for successful transaction service calls and a failure dataset for failed transaction service calls based on key fields.

[0170] S3: generating rule update data regarding preset business authority management rules based on the success data set and / or failure data set;

[0171] S4: Sending the rule update data to the management terminal; wherein the management terminal updates the preset service authority management rules according to the rule update data.

[0172] During implementation, each time the microservice gateway performs permission verification, it will record the verification process in the gateway log. If the verification passes, the transaction service call is successfully recorded as a success; if the verification fails, the transaction service call fails as a failure.

[0173] During specific implementation, the microservice gateway can obtain the gateway log of the current time period at intervals of a preset time period (for example, every 1 month); and parse the gateway log of the current time period, and according to the key fields, split the successful data that has passed the verification from the gateway log of the current time period and combine them to obtain a successful data set; at the same time, split the failed data that has not passed the verification from the gateway log of the current time period and combine them to obtain a failed data set.

[0174] Then, based on the successful data set and / or the failed data set, the permission verification status of the current time period is analyzed, and whether there are any problems that need to be improved in the permission verification of the current time period is automatically detected.

[0175] If so, the system determines the issue and, based on it, intelligently generates rule update data for the preset business rights management rules. This rule update data is then sent to the management terminal. The management terminal can, based on this rule update data, promptly update the preset business rights management rules currently used by the microservice gateway.

[0176] On the contrary, if it does not exist, there is no need to update the preset business authority management rules currently used by the microservice gateway.

[0177] Based on the above embodiment, the microservice gateway can also regularly obtain and assist the management terminal in timely and accurately updating the preset business authority management rules based on the gateway logs of the current time period, so as to eliminate the problems existing in the actual permission verification, effectively improve the verification accuracy during the permission verification, and reduce verification errors.

[0178] Before specific implementation, it is also possible to split the sample success data set and the sample failure data set in advance according to the sample log records based on the sample business authority management rules; then, using the sample success data set and the sample failure data set through deep learning, train a model that can automatically determine whether there are any problems that need to be improved in the sample business authority management rules, and when it is determined that there are problems that need to be improved, automatically generate an update decision model for the sample business authority management rules.

[0179] Correspondingly, during specific implementation, the microservice gateway can also call the above-mentioned update decision model and process the successful data set and / or failed data set obtained by splitting the gateway log based on the current time period to efficiently and automatically generate rule update data about the preset business authority management rules.

[0180] In some embodiments, see Figure 6 As shown, the rule update data for the preset business authority management rules is generated based on the successful data set and / or failed data set. When implemented specifically, the following contents may be included:

[0181] S1: Count the number of log records in the successful data set that lack login token validity verification; and count the frequency of successful calls to transaction business services in the current time period;

[0182] S2: Determine whether the rule update conditions are met based on the number of log records in the success data set that lack login token validity verification and the frequency of successful transaction business service calls in the current time period;

[0183] S3: When it is determined that the rule update conditions are met, a first type of sub-rule for adding or supplementing token validity verification is generated as rule update data for the preset business authority management rule.

[0184] During specific implementation, when it is determined that the proportion of log records in the successful data set that lack login token validity verification in the successful data set is greater than the preset proportion threshold, and the frequency of successful calls to the transaction business service in the current time period is greater than the preset frequency threshold, it can be determined that there is a loophole in the login token validity verification link in the permission verification process of the microservice gateway, resulting in some users being able to successfully call the transaction business service without undergoing login token validity verification. Therefore, it is determined that the rule update conditions are met.

[0185] To address this situation, the microservices gateway can analyze the target client application's business interfaces and underlying code to obtain a summary. Based on this summary, it can automatically determine rule update data for the preset business permission management rules that are compatible with the current target client application. This rule update data can be based on the existing preset business permission management rules and incorporate the specific circumstances of the target client application to add or supplement the first-category token validity verification sub-rules to address gaps in permission verification.

[0186] Based on the above embodiment, the microservice gateway can intelligently generate matching rule update data based on the gateway log for loopholes in the login token validity verification process during the permission verification process to assist in the accurate update of the preset business permission management rules.

[0187] In some embodiments, the above-mentioned generation of rule update data for preset business authority management rules based on the success data set and / or failure data set may further include the following contents during specific implementation:

[0188] S1: Based on the successful data set, count the frequency of successful calls to each transaction business service based on each target client application within the current time period;

[0189] S2: Based on the frequency of successful calls to each transaction service by each target client application in the current time period, detecting whether at least one transaction service has a frequency of successful calls in the current time period greater than a preset reference threshold;

[0190] S3: When it is determined that there is at least one transaction business service whose frequency of successful calls in the current time period is greater than a preset reference threshold, it is determined that the rule update condition is met; and a second type of sub-rule for adding or updating the permission matching rule for the transaction business service is generated as rule update data for the preset business permission management rule.

[0191] During specific implementation, when it is detected that the frequency of successful calls to a certain transaction business service in the current time period is greater than a preset reference threshold, it can be preliminarily determined that the frequency of successful calls to the transaction business service is abnormally too high; at this time, a query can be called to verify whether the transaction business service belongs to a transaction business service that prevents vertical overreach; if the transaction business service belongs to a transaction business service that prevents vertical overreach, it can be determined that the current abnormally high frequency of successful calls is obviously an abnormal situation, and it can be determined that the rule update conditions are met.

[0192] In response to the above situation, the microservice gateway can automatically detect whether there are loopholes or gaps in the permission matching process of the transaction business service in the preset business permission management rules. If so, it can automatically generate a second type of sub-rule for adding or updating the permission matching rule for the transaction business service to eliminate the loophole or gap based on the preset business permission management rules, as the rule update data.

[0193] Based on the above embodiment, the microservice gateway can intelligently generate matching rule update data based on the gateway log for loopholes or gaps in the permission matching link during the permission verification process to assist in the accurate update of the preset business permission management rules.

[0194] In some embodiments, the above-mentioned generation of rule update data for preset business authority management rules based on the success data set and / or failure data set may further include the following contents during specific implementation:

[0195] S1: Based on the success data set and the failure data set, count the ratio of failed calls to successful calls of each transaction business service based on each target client application in the current time period;

[0196] S2: If the ratio of failed calls to successful calls for at least one transaction service in the current time period is greater than a preset ratio threshold, it can be determined that the interception rate of the transaction service is too high, and there may be an abnormal permission verification, resulting in some authorized users being unable to call operations normally. In this case, the transaction service can be marked as an abnormal transaction service.

[0197] S3: Generate a simulated transaction business request with operation authority for the abnormal transaction business service according to the authority parameter of the abnormal transaction business service;

[0198] S4: Based on the preset business authority management rules, simulate the authority verification according to the simulated transaction business request to obtain the corresponding simulation processing result;

[0199] S5: Based on the simulation processing result, if it is determined that the simulated transaction business request permission verification passes, it is determined that the current preset business permission management rules do not have issues that need to be improved; conversely, if it is determined that the simulated transaction business request permission verification fails, it is determined that the current preset business permission management rules do have issues that need to be improved, and further, it is determined that the rule update condition is met;

[0200] S6: When it is determined that the rule update conditions are met, the error cause and error location that caused the permission check to fail are determined based on the simulation processing results; and based on the error cause and save location, the current preset business permission management rules are sorted out and checked to automatically generate modification rules for the current preset business permission management rules as rule update data.

[0201] Based on the above embodiment, the microservice gateway can automatically make relatively richer and more diverse modifications and updates to the currently used preset business authority management rules to ensure that the preset business authority management rules used are accurate and effective.

[0202] In some embodiments, after splitting the successful data set about the successful call of the transaction business service and the failed data set about the failed call of the transaction business service from the gateway log of the current time period according to the key fields, in specific implementation, the successful data set and / or the failed data set can also be processed using a pre-trained preset permission management abnormal scenario classification model to obtain the corresponding abnormal scenario classification results; and based on the abnormal scenario classification results, the abnormal scenario of the preset business permission management rules reflected in the gateway log of the current time period is automatically determined. Then, the historical processing records of the abnormal scenario are queried and the currently used preset business permission management rules are checked in a targeted manner; based on the inspection results, the corresponding rule update data is determined.

[0203] In some embodiments, during specific implementation, if it is determined that the permission match is passed, the microservice gateway can sign the target transaction business request according to the corresponding cryptographic algorithm; and then forward the signed target transaction business request to the target business server.

[0204] After receiving the target transaction request forwarded by the microservice gateway, the target business server can first detect whether the target transaction request contains the microservice gateway's digital signature. If it is confirmed to be present, the target business server can further verify the authenticity of the digital signature using the corresponding cryptographic algorithm. If the digital signature is confirmed to be authentic, the target transaction request can be determined to be a genuine and legitimate target transaction request that has passed the microservice gateway's permission verification and is guaranteed by the microservice gateway. The target business server can then respond to the target transaction request and perform transaction data processing based on the target transaction service.

[0205] Furthermore, when the target business server determines that the digital signature is genuine, it can also determine whether the target transaction service targeted by the target transaction request is a sensitive transaction service based on the transaction identifier carried by the target transaction request. If it is determined to be a sensitive transaction service, it can perform further permission verification. Only if the target business server passes the further permission verification for the target transaction request will it normally respond to the target transaction request and perform the corresponding transaction data processing, thereby further improving the security of the data processing of the relevant transaction business.

[0206] As can be seen from the above, the transaction data processing method provided by the embodiment of this specification can be deployed between the server and the user terminal before implementation. A microservice gateway based on a microservice architecture associated with the target client application can be deployed; and at least the authority authentication service is integrated into the microservice gateway. In specific implementation, when the target user logs in to the target client application and triggers the target transaction business service therein to generate a corresponding target transaction business request, the microservice gateway can receive the target transaction business request instead of the server, and verify the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules; when the validity verification passes, the target transaction business service is detected according to the preset business authority management rules and the transaction identifier of the target transaction business service to determine whether it belongs to a transaction business service that prevents vertical overreach; if it does, then according to the preset business authority management rules, the authority parameters of the target transaction business service and the authority data group of the target user are obtained through the authority authentication service; then, according to the preset business authority management rules, the authority parameters of the target transaction business service and the authority data group of the target user are used to perform authority matching; when it is determined that the authority matching passes, the target transaction business request is forwarded to the corresponding target business server to call the corresponding target transaction business for corresponding transaction data processing. This enables efficient and accurate permission verification of related transaction services under the microservice architecture, avoids vertical overreach, and protects the data security of related transaction businesses. At the same time, it can also effectively reduce overall data processing costs, simplify user operations, and enable users to obtain a better interactive experience.

[0207] This specification embodiment provides a server, see Figure 7 The server includes a network communication port 701, a processor 702, and a memory 703, and the above structures are connected through internal cables so that each structure can perform specific data interaction.

[0208] Among them, the network communication port 701 can be specifically used to receive a target transaction business request; wherein, the target transaction business request is generated by the user terminal when it detects that the target user logs in to the target client application and triggers the corresponding target transaction business service; the target transaction business request carries at least the login token of the target user and the transaction identifier of the target transaction business service.

[0209] The processor 702 can be specifically used to respond to the target transaction business request, and verify the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules; when it is determined that the target user's login token validity verification is passed, according to the preset business authority management rules and the transaction identifier of the target transaction business service, detect whether the target transaction business service is a transaction business service that prevents vertical overreach; when it is determined that the target transaction business service is a transaction business service that prevents vertical overreach, according to the preset business authority management rules, obtain the authority parameters of the target transaction business service and the authority data group of the target user through the authority authentication service; according to the preset business authority management rules, perform authority matching using the authority parameters of the target transaction business service and the authority data group of the target user; when it is determined that the authority matching is passed, forward the target transaction business request to the corresponding target business server; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

[0210] The memory 703 may be specifically used to store corresponding instruction programs and other related data.

[0211] Based on the above method, the relevant structural performance of the server can be effectively utilized, the data processing speed of the electronic device can be improved, and the processing of transaction data based on the target client application can be efficiently realized.

[0212] In this embodiment, the network communication port 701 can be a virtual port that is bound to different communication protocols, thereby being capable of sending or receiving different data. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. Furthermore, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM or CDMA; it can also be a Wi-Fi chip; or it can be a Bluetooth chip.

[0213] In this embodiment, the processor 702 may be implemented in any suitable manner. For example, the processor may take the form of a microprocessor or a processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, an embedded microcontroller, etc. This specification is not intended to limit this.

[0214] In this embodiment, the memory 703 may include multiple levels. In a digital system, anything that can store binary data can be a memory. In an integrated circuit, a circuit with a storage function that does not have a physical form is also called a memory, such as RAM, FIFO, etc. In a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0215] The embodiment of this specification also provides a computer-readable storage medium based on the above-mentioned transaction data processing method, wherein the computer-readable storage medium stores computer program instructions, which, when executed, realize: receiving a target transaction business request; wherein the target transaction business request is generated by the user terminal when detecting that the target user logs into the target client application and triggers the corresponding target transaction business service; the target transaction business request carries at least the login token of the target user and the transaction identifier of the target transaction business service; responding to the target transaction business request, according to the preset business authority management rules, verifying the validity of the login token of the target user by querying the redis cache of the authority authentication service; after determining the validity of the login token of the target user, If the verification is passed, it is detected whether the target transaction business service is a transaction business service that prevents vertical overreaching according to the preset business authority management rules and the transaction identifier of the target transaction business service; if it is determined that the target transaction business service is a transaction business service that prevents vertical overreaching, the authority parameters of the target transaction business service and the authority data group of the target user are obtained through the authority authentication service according to the preset business authority management rules; according to the preset business authority management rules, the authority parameters of the target transaction business service and the authority data group of the target user are used to perform authority matching; if it is determined that the authority matching is passed, the target transaction business request is forwarded to the corresponding target business server; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

[0216] In this embodiment, the storage medium includes, but is not limited to, random access memory (RAM), read-only memory (ROM), cache, hard disk drive (HDD), or memory card. The memory can be used to store computer program instructions. The network communication unit can be an interface configured in accordance with the standards specified by the communication protocol for network connection communication.

[0217] In this embodiment, the functions and effects specifically implemented by the program instructions stored in the computer-readable storage medium can be explained in comparison with other implementations and will not be repeated here.

[0218] The embodiment of the present specification also provides a computer program product, which at least includes a computer program, and when the computer program is executed by a processor, implements the following method steps: receiving a target transaction business request; wherein the target transaction business request is generated by a user terminal when detecting that a target user logs into a target client application and triggers a corresponding target transaction business service; the target transaction business request carries at least a login token of the target user and a transaction identifier of the target transaction business service; responding to the target transaction business request, according to a preset business authority management rule, verifying the validity of the login token of the target user by querying the redis cache of the authority authentication service; when it is determined that the validity of the login token of the target user passes the verification, verifying the validity of the login token of the target user according to the preset business authority management rule; Based on the business authority management rules and the transaction identification of the target transaction business service, it is detected whether the target transaction business service belongs to the transaction business service that prevents vertical overreach; when it is determined that the target transaction business service belongs to the transaction business service that prevents vertical overreach, according to the preset business authority management rules, the authority parameters of the target transaction business service and the authority data group of the target user are obtained through the authority authentication service; according to the preset business authority management rules, the authority parameters of the target transaction business service and the authority data group of the target user are used to perform authority matching; when it is determined that the authority matching is passed, the target transaction business request is forwarded to the corresponding target business server; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

[0219] See Figure 8 As shown, the embodiment of this specification also provides a transaction data processing device, which is applied to a microservice gateway, wherein the microservice gateway is associated with a target client application; the target client application includes multiple transaction business services; the microservice gateway is deployed between a server and a user terminal, and the microservice gateway is integrated with at least an authority authentication service. The device may specifically include the following structural modules:

[0220] The receiving module 801 may be specifically configured to receive a target transaction service request; wherein the target transaction service request is generated by the user terminal upon detecting that a target user has logged into a target client application and triggered a corresponding target transaction service; the target transaction service request carries at least a login token of the target user and a transaction identifier of the target transaction service;

[0221] The validity verification module 802 can be used to respond to the target transaction business request and verify the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules;

[0222] The detection module 803 may be specifically configured to detect whether the target transaction service is a transaction service that is protected against vertical overreach based on preset business authority management rules and the transaction identifier of the target transaction service, if the target user's login token has been verified to be valid.

[0223] The acquisition module 804 may be specifically configured to, upon determining that the target transaction service is a transaction service subject to vertical overreach, acquire permission parameters of the target transaction service and a target user's permission data set through a permission authentication service according to preset business permission management rules;

[0224] The permission matching module 805 may be used to perform permission matching based on preset business permission management rules using the permission parameters of the target transaction business service and the permission data group of the target user;

[0225] The forwarding module 806 may be specifically configured to forward the target transaction service request to the corresponding target service server when it is determined that the authority match is passed; wherein the target service server receives and responds to the target transaction service request and performs corresponding transaction data processing.

[0226] In some embodiments, the microservices gateway is further associated with a login verification service of a target client application;

[0227] Accordingly, before receiving the target transaction business request, when the device is specifically implemented, it can also be used to: receive a target login request for a target client application; wherein, the target login request carries at least the identity identifier and login credentials of the target user; call the login verification service to perform login verification on the target user according to the target login request; when it is determined that the target user login verification has passed, call the login verification service to generate a login token corresponding to the target user; call the permission authentication service to perform permission authentication on the target user according to the identity identifier of the target user, and obtain the permission data group of the target user; after associating the identity identifier of the target user, the permission data group of the target user with the login token of the target user, and store them in the redis cache of the permission authentication service.

[0228] In some embodiments, after calling the login verification service to generate a login token corresponding to the target user, the device, when implemented, can also be used to: determine the validity period and generation time of the target user's login token; generate a corresponding validity tag based on the validity period and generation time of the login token; and add a validity tag to the target user's login token.

[0229] In some embodiments, when the above-mentioned validity verification module 802 is implemented, the validity of the target user's login token can be verified by querying the redis cache of the authority authentication service according to the preset business authority management rules in the following manner: according to the preset business authority management rules, query whether there is a login token of the target user in the redis cache of the authority authentication service; when it is determined that the login token of the target user exists in the redis cache of the authority authentication service, obtain the validity tag and current time of the target user's login token; based on the valid tag and current time of the target user's login token, detect whether the target user's login token is currently valid; when it is determined that the target user's login token is currently valid, determine that the validity verification of the target user's login token has passed.

[0230] In some embodiments, in response to the target transaction business request, after verifying the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules, the device can also be used, when implemented, to: generate a first error prompt when it is determined that the target user's login token validity verification has failed; and send the first error prompt to the target client application.

[0231] In some embodiments, the target user's permission data group may specifically include: basic information of the target user, role tags of the target user, and permission parameters of the target user.

[0232] In some embodiments, when the above-mentioned permission matching module 805 is specifically implemented, permission matching can be performed in the following manner according to the preset business permission management rules, using the permission parameters of the target transaction business service and the permission data group of the target user: according to the preset business permission management rules, whether the permission parameters of the target transaction business service match the permission parameters of the target user is detected; when it is determined that the permission parameters of the target transaction business service match the permission parameters of the target user, whether the role label of the target user matches the target transaction business service is detected; when it is determined that the role label of the target user matches the target transaction business service, it is determined that the permission matching is successful.

[0233] In some embodiments, after performing permission matching according to preset business permission management rules using the permission parameters of the target transaction business service and the permission data group of the target user, the device, when implemented, can also be used to: generate a second error prompt when it is determined that the permission match has not passed; and send the second error prompt to the target client application.

[0234] In some embodiments, when the device is implemented, it can also be used to: obtain the gateway log of the current time period of the microservice gateway at every preset time period; split the gateway log of the current time period into a successful data set about the successful call of the transaction business service and a failed data set about the failed call of the transaction business service based on the key fields; generate rule update data about the preset business authority management rules based on the successful data set and / or failed data set; send the rule update data to the management terminal; wherein, the management terminal updates the preset business authority management rules according to the rule update data.

[0235] In some embodiments, when the device is implemented, it can generate rule update data about the preset business authority management rules based on the success data set and / or failure data set in the following manner: count the number of log records in the success data set that lack login token validity verification; and count the frequency of successful calls to transaction business services in the current time period; determine whether the rule update conditions are met based on the number of log records in the success data set that lack login token validity verification and the frequency of successful calls to transaction business services in the current time period; if it is determined that the rule update conditions are met, generate a first type of sub-rule about adding or supplementing token validity verification as the rule update data about the preset business authority management rules.

[0236] In some embodiments, when the device is implemented, rule update data for preset business authority management rules can be generated based on the success data set and / or failure data set in the following manner: based on the success data set, the frequency of successful calls to each transaction business service based on each target client application in the current time period is counted; based on the frequency of successful calls to each transaction business service based on each target client application in the current time period, it is detected whether there is at least one transaction business service whose frequency of successful calls in the current time period is greater than a preset reference threshold; if it is determined that there is at least one transaction business service whose frequency of successful calls in the current time period is greater than the preset reference threshold, it is determined that the rule update condition is met; and a second type of sub-rule for adding or updating the permission matching rule for the transaction business service is generated as the rule update data for the preset business authority management rule.

[0237] It should be noted that the units, devices or modules described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. For the convenience of description, the above devices are described in terms of functions and are divided into various modules and described separately. Of course, when implementing this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0238] As can be seen from the above, the transaction data processing device provided in the embodiments of this specification can efficiently and accurately implement the permission verification of related transaction business services under the microservice architecture, avoid vertical overreach, and protect the data security of related transaction businesses; at the same time, it can also effectively reduce the overall data processing cost, simplify user operations, and enable users to obtain a better interactive experience.

[0239] In a specific scenario example, the transaction data processing method provided in this specification can be applied to implement authentication for a microservice gateway based on permission groups to prevent vertical unauthorized access. For the specific implementation process, please refer to the following content.

[0240] In this scenario, consider the following issues with existing methods for authenticating microservice permissions within a microservices framework: 1. Code duplication: Each service must implement the same permission verification logic, leading to code duplication and maintenance difficulties. 2. Poor scalability: Adding new permission rules requires modifying the code of each service, resulting in poor scalability. 3. Difficulty in management: Centralized management of permission rules for all services is difficult.

[0241] In response to the above problems, a unified permission verification scheme based on permission groups is proposed in this scenario example. Based on the gateway (for example, microservice gateway), unified auth authentication (for example, permission authentication service), and combined with log analysis, the permission verification logic is centralized on the API gateway, so that all microservice APIs need to be requested through the gateway. The following effects can be achieved: 1. Eliminate code duplication: Each service does not need to implement its own permission verification logic separately to prevent vertical overreach, thereby eliminating code duplication. 2. Improve scalability: If new permission rules need to be added, you only need to modify the configuration of the API gateway without modifying the code of each service. This improves scalability. 3. Simplify management: The permission rules of all services can be managed by centrally managing the configuration of the API gateway. This simplifies permission management. 4. Simplify configuration: Based on automatic analysis of success and failure logs in the gateway log, new policies to be confirmed are automatically added, and take effect after approval by the security administrator. For specific implementation, please refer to Figure 9 As shown, the following steps may be included.

[0242] S1: Build a microservice gateway: Use the microservice gateway framework, specifically the Zuul gateway.

[0243] S2: Integrate authentication services (for example, permission authentication services): Integrate authentication services into the microservice gateway. Specifically, you can use self-developed auth authentication services for identity authentication and authorization (for example, integrate permission authentication services into the microservice gateway).

[0244] S3: Configure permission groups (e.g., permission parameters) and permission group transaction numbers (e.g., transaction identifiers): Configuring permission groups and transaction numbers in the gateway requires preventing vertical overreach; the permission group represents the user's permission type, and the transaction number represents the transaction registered in the configuration center.

[0245] S4: User permission group management: Maintain user permission groups in the permission management service, configure the association between users and permission groups, and write the user permission group (for example, permission data group) into auth after user authentication.

[0246] S5: Write the user's permission group after the user logs in: After the user logs in successfully, the user's basic information and user permission group information are written to redis.

[0247] S6: When a user calls an interface, the first step is to determine whether the user token (for example, login token) is valid, that is, whether the user is a normal logged-in user. If the token is invalid, the request is rejected; the second step is to determine whether the interface belongs to a specific permission group transaction.

[0248] S7: Compare the user's permission group with the permission group for the transaction in the gateway (e.g., permission match): If the interface belongs to a transaction with a specific permission group, the microservice gateway compares the user's permission group with the permission group for the transaction in the gateway. If the user's permission group has the permission for the transaction, the user is allowed to access the interface; otherwise, the user's access request is denied.

[0249] S8: Log Analysis: The log analysis service collects gateway success and failure logs and analyzes them according to specific rules. For transactions that meet the rules, appropriate policies are added and take effect after approval by the security administrator.

[0250] The API gateway configuration maintains the permission groups and transaction numbers for all services and is responsible for receiving all external requests. It also implements the following validation logic: upon receiving a request, it reads the token information in the request header and first determines whether the token is authentic and valid. If not, the request is rejected.

[0251] Then, the permission group of the requesting user is queried in the auth-authenticated redis and compared with the permission group to which the transaction belongs. If the user is in the corresponding permission group, the request is forwarded to the application service. If not, it returns that the call permission is not granted.

[0252] The above Auth authentication serves as a unified authentication service, providing an interface for the login service to call after the user login verification is completed, and writes the user's basic information and user permission group information into redis.

[0253] The above login service (for example, login verification service) provides login authentication service for users. After the user logs in through account password / mobile phone verification code / certificate, the login service will verify the user's login information. If it passes, it will generate a user token and write the token, user basic information, and permission group information into the redis of Auth authentication.

[0254] The above permission management service assigns permission groups to users and establishes a relationship between users and permission groups for subsequent write authentication.

[0255] The log analysis service above is used to collect gateway success and failure logs and analyze them according to specific rules. For transactions that meet the rules, appropriate policies are added and take effect after approval by the security administrator.

[0256] During the specific implementation, the authentication service is integrated through the microservice gateway: based on the API gateway, auth authentication, login service, and permission management service, a unified authentication scheme to prevent vertical unauthorized access is established. Through the permission group and transaction number configuration: the permission group and permission group transaction number are configured in the microservice gateway to define and manage user permissions. Through the dynamic permission checking mechanism: when the user logs in, his permission group is written to the gateway; when the user calls the interface, the gateway compares the permission group to which the interface belongs with the permission group of the user corresponding to the token in the request header to determine whether there is call permission to prevent unauthorized calls. Through the log analysis service, the gateway's transaction success and failure logs can be dynamically monitored according to rules, configuration problems can be analyzed, and new configuration strategies can be actively added.

[0257] In this scenario example, during specific implementation, the development language can be Java, and the basic components can be Tomcat, MySQL, Redis, etc.

[0258] Specifically, in order to solve the problem of vertical unauthorized access, the following services can be deployed in advance: API gateway (Zuul), auth authentication, user authentication service (for example, login verification service), permission management service, and log analysis service.

[0259] When implementing the above service, you can first organize user permissions into groups within the business project, such as system administrator, department administrator, approval user, and query user. Then, based on the business organization, assign relevant users to permission groups in the permission management during system initialization. For example, User A represents the system administrator, User B represents the department administrator and query user, and User C represents the query user. Then, based on the permission groups defined by the business organization, R&D associates transaction numbers with permission groups and configures the permission groups and transaction numbers for these groups on the gateway. For example, the system administrator group includes interfaces A, B, C, and so on; the department administrator group includes interfaces B, C, and so on; the query user group includes interfaces C and so on. Next, when a user logs in, the user authentication service verifies the login credentials provided by the user. Upon successful verification, a token is generated and an auth transaction is invoked, writing the user's basic information and permission groups to the auth Redis database. After the user logs in, any request to call an interface using a front-end service will include the token in the request header (if the token is missing, the gateway will reject the request). Upon receiving the request, the gateway determines the permission group to which the transaction belongs. Finally, the gateway uses the token to query the user's permission group in the auth Redis database and compares the user's permission group with the permission group to which the transaction belongs. If the permission groups match, the request is approved and forwarded to the corresponding application service. If not, the request is rejected.

[0260] In addition, the log analysis service will dynamically monitor the gateway's success and failure logs based on the rules and analyze any configuration flaws. For example, the gateway will automatically update the rules (e.g., pre-set business permission management rules) in the following situations:

[0261] ① If the interface is frequently successfully called when the user is not logged in, it is suspected that token verification is not enabled on the interface. A token verification policy will be added to the permission management service and is pending review by the security administrator.

[0262] ② If a logged-in user from the same source successfully calls the same interface multiple times, it is suspected that the interface is not correctly configured with permissions. The role permissions to be configured will be added to the permissions management service, pending review by the security administrator.

[0263] ③ If multiple users are blocked multiple times on the same interface, this is suspected to be a misconfiguration. The permission to block the user's role from accessing the interface will be added to the permissions management service, pending review by the security administrator.

[0264] Through the above scenario examples, it is verified that the transaction data processing method provided in this manual can indeed achieve the following effects: Improve security: By centrally managing authentication and authorization, the risk of security vulnerabilities is reduced. Simplify development and maintenance: Unified authentication and authorization logic reduces code duplication and simplifies development and maintenance. Improve performance: Permission checks are completed at the microservice gateway layer, which reduces the processing burden of microservices and improves system performance. Improve user experience: Users only need to log in once to access all authorized services, which improves user experience. Enhance the scalability of the system, and permissions can be dynamically configured and managed. Make permission management more refined: Based on permission groups, permission group transaction numbers, and user permission groups, user access rights to microservices can be controlled in a fine-grained manner to prevent vertical overreach. Support dynamic monitoring: The lack of dynamic permission monitoring makes it impossible to detect missing permission configuration problems in a timely manner.

[0265] Although this specification provides the method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or client product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or device including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such process, method, product or device. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. Words such as first and second are used to represent names and do not represent any particular order.

[0266] Those skilled in the art will also appreciate that, in addition to implementing the controller in pure computer-readable program code, it is entirely possible to implement the same functionality by logically programming the method steps in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, and the like. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered structures within the hardware component. Alternatively, the devices for implementing various functions can be considered both software modules implementing the method and structures within the hardware component.

[0267] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in local and remote computer-readable storage media, including storage devices.

[0268] Through the description of the above embodiments, it can be seen that those skilled in the art can clearly understand that this specification can be implemented by means of software plus the necessary general hardware platform. Based on this understanding, the technical solution of this specification can essentially be embodied in the form of a software product. This computer software product can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a mobile terminal, a server, or a network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments of this specification.

[0269] The various embodiments in this specification are described in a progressive manner. References to the common or similar parts of the various embodiments are sufficient. Each embodiment focuses on the differences from the other embodiments. This specification can be used in a variety of general-purpose or specialized computer system environments or configurations. For example, personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices.

[0270] Although the present specification has been described through embodiments, those skilled in the art will appreciate that there are many modifications and variations to the present specification without departing from the spirit of the present specification. It is intended that the appended claims include these modifications and variations without departing from the spirit of the present specification.

Claims

1. A method for processing transaction data, characterized in that: Applied to a microservices gateway, wherein the microservices gateway is associated with a target client application; the target client application includes multiple transaction business services; the microservices gateway is deployed between a server and a user terminal, and the microservices gateway is integrated with at least an authorization authentication service. The method includes: Receive a target transaction service request; wherein the target transaction service request is generated by the user terminal upon detecting that the target user has logged into the target client application and triggering the corresponding target transaction service; the target transaction service request carries at least a login token of the target user and a transaction identifier of the target transaction service; Respond to the target transaction business request and verify the validity of the target user's login token by querying the Redis cache of the permission authentication service according to the preset business permission management rules; If the target user's login token is verified to be valid, the system checks whether the target transaction service is a transaction service that prevents vertical overreach based on the preset business authority management rules and the transaction ID of the target transaction service. If it is determined that the target transaction business service is a transaction business service that prevents vertical overreach, the permission parameters of the target transaction business service and the permission data group of the target user are obtained through the permission authentication service according to the preset business permission management rules; According to the preset business authority management rules, authority matching is performed using the authority parameters of the target transaction business service and the authority data group of the target user; When it is determined that the authority match is passed, the target transaction business request is forwarded to the corresponding target business server; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

2. The method according to claim 1, characterized in that The microservice gateway is also associated with the login verification service of the target client application; Accordingly, before receiving the target transaction service request, the method further includes: Receive a target login request for a target client application; wherein the target login request carries at least an identity identifier and login credentials of a target user; Call the login verification service to perform login verification on the target user according to the target login request; If the target user passes the login verification, call the login verification service to generate a login token corresponding to the target user; Call the permission authentication service to authenticate the target user according to the target user's identity and obtain the target user's permission data group; After associating the target user's identity, the target user's permission data group with the target user's login token, they are stored in the redis cache of the permission authentication service.

3. The method according to claim 2, characterized in that After calling the login verification service to generate a login token corresponding to the target user, the method further includes: Determine the validity period and generation time of the target user's login token; Generate a corresponding validity tag based on the validity period and generation time of the login token; Add a validity tag to the target user's login token.

4. The method according to claim 3, characterized in that According to the preset business permission management rules, the validity of the target user's login token is verified by querying the Redis cache of the permission authentication service, including: According to the preset business permission management rules, check whether the target user's login token exists in the Redis cache of the permission authentication service; If the target user's login token is found in the Redis cache of the authentication service, obtain the validity tag and current time of the target user's login token; Check whether the target user's login token is currently valid based on the target user's login token's valid tag and current time; When it is determined that the login token of the target user is currently valid, it is determined that the validity verification of the login token of the target user is passed.

5. The method according to claim 1, wherein In response to the target transaction business request, after verifying the validity of the target user's login token by querying the redis cache of the authority authentication service according to the preset business authority management rules, the method further includes: If it is determined that the target user's login token validity verification fails, a first error message is generated; Send a first error notification to the target client application.

6. The method according to claim 1, wherein The target user's permission data group includes: basic information of the target user, role tags of the target user, and permission parameters of the target user.

7. The method according to claim 6, characterized in that According to the preset business authority management rules, authority matching is performed using the authority parameters of the target transaction business service and the authority data group of the target user, including: According to the preset business authority management rules, check whether the authority parameters of the target transaction business service match the authority parameters of the target user; If it is determined that the permission parameters of the target transaction business service match the permission parameters of the target user, detecting whether the role tag of the target user matches the target transaction business service; When it is determined that the role tag of the target user matches the target transaction business service, it is determined that the permission matching is passed.

8. The method according to claim 1, characterized in that After performing permission matching based on the preset business permission management rules using the permission parameters of the target transaction business service and the permission data group of the target user, the method further includes: If it is determined that the permission match fails, a second error message is generated; Send a second error message to the target client application.

9. The method according to claim 1, characterized in that The method further comprises: Get the gateway log of the microservice gateway in the current time period at every preset time period; Based on key fields, the gateway logs for the current time period are split into a success data set for successful transaction service calls and a failure data set for failed transaction service calls. Generating rule update data regarding preset business authority management rules based on the success data set and / or failure data set; The rule update data is sent to a management terminal; wherein the management terminal updates a preset service authority management rule according to the rule update data.

10. The method according to claim 9, characterized in that Generating rule update data for preset business authority management rules based on the success data set and / or failure data set, including: Count the number of log records in the successful data set that lack login token validity verification; and count the frequency of successful calls to transaction business services in the current time period; Determine whether the rule update conditions are met based on the number of log records in the successful data set that lack login token validity verification and the frequency of successful transaction business service calls in the current time period; When it is determined that the rule update conditions are met, a first type of sub-rule for adding or supplementing token validity verification is generated as rule update data for the preset business authority management rules.

11. The method according to claim 9, characterized in that Generating rule update data regarding preset business authority management rules based on the success data set and / or failure data set, further comprising: Based on the successful data set, count the frequency of successful calls to each transaction business service based on each target client application within the current time period; Based on the frequency of successful calls to each transaction service by each target client application in the current time period, detecting whether at least one transaction service has a frequency of successful calls greater than a preset reference threshold in the current time period; When it is determined that there is at least one transaction business service whose frequency of successful calls in the current time period is greater than a preset reference threshold, it is determined that the rule update conditions are met; and a second type of sub-rule for adding or updating permission matching rules for the transaction business service is generated as rule update data for the preset business permission management rules.

12. A transaction data processing device, characterized in that: Applied to a microservices gateway, wherein the microservices gateway is associated with a target client application; the target client application includes multiple transaction business services; the microservices gateway is deployed between a server and a user terminal, and the microservices gateway is integrated with at least an authorization authentication service. The device includes: a receiving module configured to receive a target transaction service request; wherein the target transaction service request is generated by a user terminal upon detecting that a target user has logged into a target client application and triggering a corresponding target transaction service; the target transaction service request carries at least a login token of the target user and a transaction identifier of the target transaction service; The validity verification module is used to respond to the target transaction business request and verify the validity of the target user's login token by querying the Redis cache of the permission authentication service according to the preset business permission management rules; A detection module is used to detect whether the target transaction service is a transaction service that prevents vertical overreach based on preset business authority management rules and the transaction identifier of the target transaction service, if the target user's login token is verified to be valid. An acquisition module is used to obtain the permission parameters of the target transaction business service and the permission data group of the target user through the permission authentication service according to the preset business permission management rules when determining that the target transaction business service is a transaction business service that prevents vertical overreach; The permission matching module is used to perform permission matching based on the preset business permission management rules, using the permission parameters of the target transaction business service and the permission data group of the target user; The forwarding module is used to forward the target transaction business request to the corresponding target business server when it is determined that the authority match is passed; wherein, the target business server receives and responds to the target transaction business request to perform corresponding transaction data processing.

13. A server, characterized in that: The method comprises a processor and a memory for storing processor-executable instructions, wherein the processor implements the steps of the method according to any one of claims 1 to 11 when executing the instructions.

14. A computer-readable storage medium, characterized in that Computer instructions are stored thereon, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the steps of the method according to any one of claims 1 to 11 when the computer program is executed by a processor.

Images