Transaction data processing method and device and server

Abstract

The invention provides a transaction data processing method, a transaction data processing device and a server, which can be used in the financial field. Based on the method, before specific implementation, a micro-service gateway based on a micro-service architecture and associated with a target client application can be deployed between a server and a user terminal; and at least integrating the authority authentication service to the micro-service gateway. In specific implementation, after a target user logs in a target client application and triggers a target transaction business service in the target client application to generate a corresponding target transaction business request, the micro-service gateway can replace a server to receive and respond to the target transaction business request, and the target transaction business request is managed according to a preset business authority management rule. And calling the authority authentication service to complete authority verification for different transaction business services. Therefore, the authority verification of the related transaction business service under the micro-service architecture can be efficiently and accurately realized, the vertical unauthorized situation is avoided, and the data security of the related transaction business is protected; meanwhile, user operation is simplified, and the user can obtain good interaction experience.

Description

Technical Field

[0001] This specification belongs to the field of data security technology, and in particular, relates 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 microservice architecture to develop and publish client applications that include multiple transaction business services in combination with the transaction business services they provide.

[0003] However, based on the existing methods, in order to prevent vertical overreach, developers need to write and set up corresponding permission verification logic for each transaction service separately. When the above method is implemented, the amount of code development is relatively large, and the cost of code management and maintenance is relatively high; and for users, each time a transaction service is triggered, a separate permission verification needs to be performed again, which makes user operations cumbersome and affects the user's interactive experience.

[0004] To address the above problems, no effective solution has been proposed yet. Summary of the invention

[0005] This specification provides a transaction data processing method, device and server, which can efficiently and accurately implement the permission verification of related transaction business services under the microservice architecture, avoid vertical overreaching, 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, 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, and the method includes:

[0007] Receive a target transaction service request; wherein the target transaction service 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 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 authority authentication service according to the preset business authority management rules;

[0009] When the target user's login token validity verification is confirmed to have passed, the target transaction service is detected to determine whether it is a transaction service that prevents vertical overreaching according to the preset business authority management rules and the transaction identifier of the target transaction service;

[0010] When it is determined that the target transaction business service belongs to the transaction business service that prevents vertical overreach, 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;

[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] Receiving 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] When it is determined that the target user has passed the login verification, the login verification service is called 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 and 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] When it is determined that the login token of the target user exists in the redis cache of the authentication service, obtain the validity tag and current time of the login token of the target user;

[0027] According to the valid tag and current time of the target user's login token, check whether the target user's login token is currently valid;

[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 has 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] When it is determined that the target user's login token validity verification fails, a first error message is generated;

[0031] A first error notification is sent 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 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:

[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] 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 label 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 match is passed.

[0037] In one embodiment, after performing authority matching according to preset business authority management rules using the authority parameters of the target transaction business service and the authority data group of the target user, the method further includes:

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

[0039] A second error notification is sent 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] According to the key fields, the gateway logs in the current time period are split into a successful data set about successful calls to the transaction business service and a failed data set about failed calls to the transaction business service;

[0043] Generate rule update data about preset business authority management rules according to 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 business authority management rule according to the rule update data.

[0045] In one embodiment, generating rule update data about preset business authority management rules according to 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 calls to transaction business services 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 about preset business authority management rules according to 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] According to the frequency of successful calls to each transaction business service by each target client application in the current time period, detecting whether at least one transaction business service has a frequency of successful calls in the current time period greater than a preset reference threshold;

[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 regarding adding or updating permission matching rules for the transaction business service is generated as rule update data regarding 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 authority authentication service, and the device includes:

[0054] A receiving module, configured to receive a target transaction service request; wherein the target transaction service 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 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 authority authentication service according to the preset business authority management rules;

[0056] A detection module is used to detect whether the target transaction business service belongs to the transaction business service for preventing vertical overreaching according to the preset business authority management rules and the transaction identifier of the target transaction business service when it is determined that the validity verification of the login token of the target user has passed;

[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 belongs to the transaction business service for preventing 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] The present specification also provides a server, comprising 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] The present specification also provides a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the transaction data processing method are implemented.

[0062] The present specification also provides a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the steps of the transaction data processing method are implemented.

[0063] Based on the transaction data processing method, device and server provided in this specification, 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 permission authentication service can be integrated into the microservice gateway. In addition, the login verification service of the target client application can also be associated with 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 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 overreaching 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, forward the target transaction business request 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 unauthorized access, and protects the data security of related transaction services. At the same time, it can also effectively reduce the overall data processing cost, simplify user operations, and enable users to have a better interactive experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the embodiments of this specification, the drawings required for use in the embodiments will be briefly introduced below. The drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying 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 It 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 It 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 It 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 It 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 It 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 It is a schematic diagram of the structure of a server provided by an embodiment of this specification;

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

[0073] Fig. 9 It 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] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should 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. 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 also Figure 1As shown, the embodiment of this specification provides a method for processing transaction data. Among them, the method is specifically applied to the microservice gateway side. The microservice gateway is associated with the target client application; the target client application contains multiple transaction business services; the microservice gateway is deployed between the server and the user terminal, and the microservice gateway is integrated with at least an authority authentication service. When the method is specifically implemented, it may include the following contents:

[0078] S101: receiving a target transaction service request; wherein the target transaction service request is generated by a user terminal after detecting that a target user logs into a target client application and triggers 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: When it is determined that the target user's login token validity verification has passed, detect whether the target transaction service belongs to a transaction service that prevents vertical overreaching according to 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 belongs to a transaction business service for preventing vertical overreach, obtaining 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;

[0082] S105: Performing authority matching using the authority parameters of the target transaction business service and the authority data group of the target user according to the preset business authority management rules;

[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] Among them, the above-mentioned target client application can be specifically understood as a user-oriented front-end interface (API) application built and developed based on a microservice architecture.

[0085] The above microservice architecture can be specifically understood as a service architecture model that splits an application into multiple small business services. Among them, each business service runs in its own process as a microservice and communicates with other services through the corresponding business interface (API).

[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 a user terminal held by the target user.

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

[0088] The microservice gateway can be specifically understood as an API gateway based on the microservice architecture, which can provide a unified access entry for each transaction business service in the microservice architecture. Users can use user terminals to access and call corresponding transaction business services through the microservice gateway, and the microservice gateway can perform operations such as routing and filtering on access from user terminals. Specifically, for example, the microservice gateway can be a Zuul gateway.

[0089] Specifically, the microservice gateway may be integrated with a permission authentication service based on a target client application; at the same time, it may also be associated with a 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 the 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 above-mentioned permission authentication service can be specifically understood as an authentication service for the identity and authority of the user and the transaction service based on the target client application. The above-mentioned login verification service can be specifically understood as a business service for the identity verification of the logged-in user based on the target client application.

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

[0094] In specific implementation, when the target user wants to process transaction data based on the target transaction service, he can first log in to the target client application deployed on the user terminal. Then, he 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 logged into the target client application, to verify the validity of the login token, detect vertical unauthorized access to the target transaction business, and match the target user's permissions for the target transaction business, to achieve the corresponding permission verification.

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

[0098] The server may include a background server applied to a trading platform side that can realize data transmission, data processing and other functions. Specifically, the server may be, for example, an electronic device with data calculation, storage and network interaction functions. Alternatively, the server may also be a software program running in the electronic device to provide support for data processing, storage and network interaction. In this embodiment, the number of servers is not specifically limited. The server may be one server, several servers, or a server cluster formed by several servers.

[0099] The user terminal may specifically include a front end applied to the user side and capable of realizing 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, a smart phone, etc.

[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 with 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, so that 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 the user does not need to perform other additional verification operations, thereby simplifying the user operation and allowing the user to have 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, etc.

[0103] In some embodiments, the authority authentication service is further configured with a preset transaction identification list. The preset transaction identification list includes transaction identifications of transaction business services that need to be protected from vertical overreach. The preset transaction identification list can be generated by the transaction platform according to the relevant regulations of the platform and the results of big data analysis and configured to the authority authentication service.

[0104] The vertical overreaching can specifically refer to overreaching between users of different role types (or different job levels), for example, a common user executes the permissions of an administrator user. This overreaching can be divided into upward overreaching and downward overreaching. Upward overreaching refers to a low-privilege user executing a high-privilege operation, and downward overreaching refers to a high-privilege user executing a low-privilege operation.

[0105] In 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 overreaching, 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 for preventing 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 authority authentication service is also configured with the authority parameters of each transaction service on the target client application. Among them, the authority parameters of each transaction service include the role label of the corresponding user. The authority parameters of the transaction service can be generated by the trading platform according to the relevant regulations of the platform and the results of big data analysis and configured to the authority authentication service.

[0109] In some embodiments, the microservice gateway may also be specifically 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 specifically, it may also include the following contents:

[0111] S1: receiving 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: When it is determined that the target user has passed the login verification, the login verification service is called to generate a login token corresponding to the target user;

[0114] S4: calling the authority authentication service to authenticate the target user according to the target user's identity, and obtaining the target user's authority data group;

[0115] S5: After associating the identity identifier of the target user, the permission data group of the target user and the login token of the target user, 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 (eg, MAC address, IP address, etc.) of the user terminal.

[0119] Correspondingly, when it is determined that the target user's login verification has passed, 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 retrieve 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 embodiments, a login token with richer information and convenient for subsequent validity verification can be generated.

[0127] In specific implementation, in order to better protect the security of relevant transaction business data and prevent other users from stealing relevant information and using relevant transaction business services without authorization after the user logs in to the target client application, the login token can also be set as a time-sensitive data according to the preset business authority management rules. That is, within the valid period, the user can use the login token to perform the corresponding transaction business service within the corresponding authority scope; when the valid period exceeds the valid period, the user can no longer use the login token to perform the corresponding transaction business service.

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

[0129] For example, when the target user's basic information and role tags determine that the target user has a high rank and is involved in more critical transaction business service operations, the valid duration of the target user's login token can be set to a shorter duration according to the preset business authority management rules. For another example, when the target user's basic information and role tags determine that the target user has a low rank and is only involved in more routine transaction business service operations, the valid duration of the target user's login token can be set to a longer duration.

[0130] Furthermore, the microservice gateway can also determine the age of the target user based on the basic information of the target user, and adjust the login token of the target user according to the preset business authority management rules and the age of the target user. For example, it detects whether the target user is older than 60 years old. When it is determined that the target user is older than 60 years old, the target user is judged to be an elderly user; considering that the operation speed of elderly users is usually slower than that of young users in specific operations, therefore, according to the preset business authority management rules, the corresponding remaining time can be appropriately increased based on the original effective time of the login token of the target user to extend the effective time of the login token of the target user.

[0131] In some embodiments, see Figure 3 As shown, 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. The specific implementation may include the following contents:

[0132] S1: According to the preset business permission management rules, check whether the login token of the target user exists in the redis cache of the permission authentication service;

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

[0134] S3: Detect 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, according to 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] When it is determined that the login token is still valid, the login token can be further tested for legitimacy based on the 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, it is finally determined that the login token has passed the validity verification.

[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: When 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 prompt 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 login token validity of the target user 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 permission data group of the target user may include: basic information of the target user, role label of the target user, and permission parameters of the target user.

[0145] The basic information of the target user may include one or more of the following: age, name, gender, position, rank, department name, project number of the project 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 embodiments, a permission data group of a target user with relatively rich and comprehensive data information can be obtained and used 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, determine the matching preset user permission parameter template to generate the initial permission parameters for the target user; then send the initial permission parameters of the target user and the basic information of the target user to the management terminal of the trading platform, so that the management terminal can combine the basic information of the target user, and finally determine the role label and permission parameters of the target user on the basis of the initial permission parameters, and 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 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 according to 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. When implemented specifically, it 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 match is passed.

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

[0157] In 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 label 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] On the contrary, if it is determined that the role tag of the target user does not match the target transaction business service, it can be determined that although the target user's operation of the target transaction business is within the scope of authority, there is an abnormal risk in the operation behavior. At this time, although the authority match is passed, a corresponding risk tag will be generated for the operation behavior, so that continuous risk monitoring can be carried out based on the risk tag in the future. At the same time, the operation behavior will also be recorded and summarized 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 authority matching according to preset business authority management rules using the authority parameters of the target transaction business service and the authority data group of the target user, the method may further include the following when implemented:

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

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

[0164] The second error prompt is specifically used to prompt that the target user currently has no authority to operate the target transaction business service.

[0165] Furthermore, the microservice gateway can also determine the target authorization terminal responsible for authorizing the target transaction business service in combination with the authority parameters of the target transaction business service of the authority authentication service; and generate authorization prompt information about applying to the target authorization terminal for relevant permissions for the target transaction business service; and then add the above-mentioned 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 has no permission to operate the target transaction business service.

[0167] In some embodiments, see Figure 5 As shown, when the method is implemented specifically, 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 in the current time period into a successful data set about successful calls to transaction business services and a failed data set about failed calls to transaction business services based on the key fields;

[0170] S3: generating rule update data about preset business authority management rules according to 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 business authority management rules according to the rule update data.

[0172] In specific implementation, each time the microservice gateway performs permission verification, the verification process will be recorded in the gateway log. Among them, if the verification passes, the log record of successfully calling the transaction business service can be recorded as success data; if the verification fails, the log record of failing to call the transaction business service can be recorded as failure data.

[0173] In 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, according to the successful data set and / or the failed data set, the permission verification situation of the current time period is analyzed, and whether there are any problems to be improved in the permission verification of the current time period is automatically detected.

[0175] If there is, then determine and intelligently generate rule update data about the preset business authority management rules based on the problem to be improved; and send the rule update data to the management terminal. Correspondingly, the management terminal can timely update the preset business authority management rules currently used by the microservice gateway based on the rule update data.

[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 to timely and accurately update 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 the verification error.

[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 use the sample success data set and the sample failure data set through deep learning to train a system 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 about the preset business authority management rules is generated according to 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 successful data set that lack login token validity verification and the frequency of successful calls to transaction business services 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] In 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] In view of the above situation, the microservice gateway can comb the business interface and underlying code of the target client application to obtain the combing results; based on the combing results, it can automatically determine the rule update data for the preset business permission management rules that are compatible with the current target client application. Among them, the above rule update data can be based on the existing preset business permission management rules and combined with the specific situation of the target client application to add or supplement the first category of token validity verification sub-rules to make up for the loopholes 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, so as to assist in the accurate update of the preset business permission management rules.

[0187] In some embodiments, the above-mentioned generating rule update data about the preset business authority management rule according to the success data set and / or the 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 in the current time period;

[0189] S2: According to the frequency of successful calls of 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 conditions are met; and a second type of sub-rule regarding the addition or update of permission matching rules for the transaction business service is generated as rule update data regarding the preset business permission management rules.

[0191] In 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 overreaching; if the transaction business service belongs to a transaction business service that prevents vertical overreaching, it can be determined that the current abnormally high frequency of successful calls is obviously an abnormal situation, and then it can be determined that the rule update conditions are met.

[0192] In view of 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, the second type of sub-rule for adding or updating the permission matching rule for the transaction business service to eliminate the loophole or gap can be automatically generated for the preset business permission management rules with loopholes or gaps as 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 in the permission verification process to assist in the accurate update of the preset business permission management rules.

[0194] In some embodiments, the above-mentioned generating rule update data about the preset business authority management rule according to the success data set and / or the 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 the number of failed calls to the number of successful calls of each transaction business service based on each target client application in the current time period;

[0196] S2: When detecting whether there is at least one transaction service whose ratio of failed calls to successful calls 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 abnormality in the permission verification, resulting in some users with permission to operate being unable to call the operation normally. In this case, the transaction service can be marked as an abnormal transaction service;

[0197] S3: generating 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: According to the simulation processing result, if it is determined that the simulated transaction business request permission check passes, it is determined that there is no problem to be improved in the current preset business permission management rules; on the contrary, if it is determined that the simulated transaction business request permission check fails, it is determined that there is a problem to be improved in the current preset business permission management rules, and then 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 the 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 used preset business authority management rules 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 the specific implementation, the successful data set and / or the failed data set can also be processed by the pre-trained preset permission management abnormal scenario classification model to obtain the corresponding abnormal scenario classification result; and according to the abnormal scenario classification result, the abnormal scenario about the preset business permission management rule reflected by the gateway log of the current time period is automatically determined. Then query and check the currently used preset business permission management rules in a targeted manner according to the historical processing records of the abnormal scenario; according to the inspection results, the corresponding rule update data is determined.

[0203] In some embodiments, during specific implementation, when 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 business request forwarded by the microservice gateway, the target business server can first detect whether the target transaction business request has the digital signature of the microservice gateway; if it is determined to exist, the authenticity of the digital signature is further verified according to the corresponding cryptographic algorithm; when the digital signature is determined to be true, it can be determined that the target transaction business request is a real and legal target transaction business request that has passed the permission verification of the microservice gateway and is guaranteed by the microservice gateway. Then, the target business server can respond to the target transaction business request and process transaction data based on the target transaction business service.

[0205] In addition, when the target business server determines that the digital signature is true, the target business server can also determine whether the target transaction business service targeted by the target transaction business request is a sensitive transaction business service based on the transaction identifier carried by the target transaction business request; when it is determined to be a sensitive transaction business service, further permission verification can be performed. Only when the target business server passes the further permission verification for the target transaction business request, the target business server will normally respond to the target transaction business request to perform corresponding transaction data processing, thereby further improving the security of data processing of related transaction businesses.

[0206] As can be seen from the above, the method for processing transaction data 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 the 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 replace the server to receive the target transaction business request, and 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; when the validity verification passes, 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 belongs to the transaction business service that prevents vertical overreach; 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 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 unauthorized access, and protects the data security of related transaction services. At the same time, it can also effectively reduce the overall data processing cost, simplify user operations, and enable users to have a better interactive experience.

[0207] This specification embodiment provides a server, referring to 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 validity of the target user's login token has been verified, 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 belongs to the transaction business service that prevents vertical overreaching; when it is determined that the target transaction business service belongs to the transaction business service that prevents vertical overreaching, 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 has 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 so that different data can be sent or received. 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. In addition, 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, CDMA, etc.; it can also be a Wifi chip; it can also be a Bluetooth chip.

[0213] In this embodiment, the processor 702 may be implemented in any appropriate manner. For example, the processor may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. This specification does not 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 has no 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 the present 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, and when the computer program instructions are executed, the following are achieved: receiving a target transaction business request; wherein the target transaction business request is generated by a user terminal when it detects that a target user logs in to 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; after determining the validity of the login token of the target user, If the verification is passed, detect whether the target transaction business service belongs to the 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 belongs to the transaction business service that prevents vertical overreaching, 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 according to the preset business authority management rules; if 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.

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

[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 described in detail 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, the following method steps are implemented: 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 in to 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 has passed the verification, verifying the validity of the login token of the target user according to the preset business authority management rule; According to the business authority management rules and the transaction identification of the target transaction business service, detect whether the target transaction business service belongs to the transaction business service that prevents vertical overreaching; when it is determined that the target transaction business service belongs to the transaction business service that prevents vertical overreaching, 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; 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, 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.

[0219] See also 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 when detecting that the target user logs into the target client application and triggers the corresponding target transaction service; the target transaction service request at least carries the login token of the target user and the transaction identifier of the target transaction service;

[0221] The validity verification module 802 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;

[0222] The detection module 803 may be specifically used to detect whether the target transaction service belongs to the transaction service for preventing vertical overreaching according to the preset business authority management rules and the transaction identifier of the target transaction service when it is determined that the target user's login token validity verification has passed;

[0223] The acquisition module 804 may be specifically used to acquire 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 when it is determined that the target transaction business service belongs to the transaction business service for preventing vertical overreach;

[0224] The authority matching module 805 may be specifically used to perform authority matching according to preset business authority management rules, using the authority parameters of the target transaction business service and the authority 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 to perform corresponding transaction data processing.

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

[0227] Correspondingly, before receiving the target transaction business request, the device can also be used when it is implemented 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 authority authentication service to perform authority authentication on the target user according to the identity identifier of the target user, and obtain the authority data group of the target user; after associating the identity identifier of the target user, the authority data group of the target user with the login token of the target user, and store them in the redis cache of the authority 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 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 login token of the target user; based on the valid tag and current time of the login token of the target user, detect whether the login token of the target user is currently valid; when it is determined that the login token of the target user is currently valid, determine that the validity verification of the login token of the target user has passed.

[0230] In some embodiments, in response to the target transaction business request, according to the preset business authority management rules, after verifying the validity of the target user's login token by querying the redis cache of the authority authentication service, the device, when implemented specifically, can also be used to: generate a first error prompt when it is determined that the target user's login token validity verification has failed; 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, a role tag of the target user, and permission parameters of the target user, etc.

[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 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, detect whether the permission parameters of the target transaction business service match the permission parameters of the target user; when it is determined that the permission parameters of the target transaction business service match the permission parameters of the target user, detect whether the role label of the target user matches the target transaction business service; when it is determined that the role label of the target user matches the target transaction business service, determine that the permission match is passed.

[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 a 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 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 field; generate rule update data about the preset business authority management rules according to 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, it can generate rule update data about the preset business authority management rules according to the success data set and / or failure data set in the following manner: according to the success data set, count the frequency of successful calls to each transaction business service based on each target client application in the current time period; according to the frequency of successful calls to each transaction business service based on each target client application in the current time period, detect 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; 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 the preset reference threshold, determine that the rule update condition is met; and generate a second type of sub-rule for adding or updating the permission matching rule for the transaction business service as the rule update data about the preset business authority management rules.

[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 separately by functions divided into various modules. Of course, when implementing this specification, the functions of each module can be implemented in the same or more software and / or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, 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] It can be seen from the above that the transaction data processing device provided in the embodiment of this specification can efficiently and accurately implement the permission verification of related transaction business services under the microservice architecture, avoid vertical overreaching, 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 the authentication of the microservice gateway based on the permission group to prevent vertical overreach. For the specific implementation process, please refer to the following content.

[0240] In this scenario example, the existing methods often have the following problems when authenticating microservice permissions under the microservice framework: 1. Code duplication: Each service needs to implement the same permission verification logic, which will lead to code duplication and maintenance difficulties. 2. Poor scalability: If you need to add new permission rules, you need to modify the code of each service. This will lead to poor scalability. 3. Difficult to manage: It is difficult to centrally manage the permission rules of all services.

[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 concentrated 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 you need to add new permission rules, 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 the success and failure logs in the gateway log, new policies to be confirmed are automatically added, and they will take effect after approval by the security administrator. For specific implementation, please refer to Fig. 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 permission groups in the gateway requires preventing vertical overreaching of transaction numbers; wherein the permission group represents the user's permission type, and the transaction number represents the transaction registered by 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, first, it determines 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; second, it determines whether the interface belongs to a specific permission group transaction.

[0248] S7: Compare the user permission group with the permission group of the transaction in the gateway (e.g., permission matching): If the interface belongs to a transaction of a specific permission group, the microservice gateway will compare the user permission group with the permission group of the transaction in the gateway. If the user 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 will collect the gateway success and failure logs and analyze them according to certain rules. For transactions that meet the rules, add appropriate policies and wait for the security administrator to review and approve them before they take effect.

[0250] The above API gateway configuration maintains the permission groups of all services and the transaction numbers under the permission groups, and is responsible for receiving all external requests. It also implements the following verification logic: when a request is received, it reads the token information in the request header, first determines whether the token is a real and valid token, and rejects the request if it is not a valid token.

[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 there is no call permission.

[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 to users. After the user logs in through account password / mobile phone verification code / certificate, the login service will verify the user's login information, generate a user token after passing, and write the token and 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 the relationship between users and permission groups for subsequent write authentication.

[0255] The above log analysis service is used to collect the success and failure logs of the gateway and analyze them according to certain rules. For transactions that meet the rules, add appropriate policies and wait for the security administrator to review and approve them before they take effect.

[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 solution is established to prevent vertical unauthorized access. 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 transaction success and failure logs of the gateway can be dynamically monitored according to the rules, the configuration missing problems can be analyzed, and new configuration strategies can be actively added.

[0257] In this scenario example, during the 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 services, you can first organize the user rights in the business combing project into groups, such as system administrator, department administrator, approval user, query user, etc. Then, according to the business combing, configure the relevant users to the permission group in the permission management when the system is initially deployed. For example, user A---system administrator, user B---department administrator, query user, user C---query user, etc. Then, according to the permission group combed by the business, the research and development will bind the transaction number with the permission group, and configure the permission group and the permission group transaction number to the gateway. For example, the system administrator group----interface a, interface b, interface c..., the department administrator group----interface b, interface c..., the query user group----interface c.... Then, when the user logs in, the user authentication service verifies the login basis provided by the user. After the verification is passed, a token is generated and the auth transaction is called, and the user's basic information and user permission group are written to the redis of auth. Then, after the user logs in, when the front-end service is used to call the interface, the request header will carry a token (if there is no token, the gateway will reject the relevant request). After receiving the request, the gateway determines the permission group to which the transaction belongs. Finally, the gateway queries the user's permission group in the redis of auth based on the token, and compares the user's permission group with the permission group to which the transaction belongs. If the permission groups match successfully, 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 success and failure logs according to the rules and analyze the existing configuration defects. For example, in the following situations, the gateway will automatically dynamically update the rules (for example, the preset business permission management rules):

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

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

[0263] ③ If multiple users are blocked multiple times on the same interface, it is suspected that there is a lack of configuration. The permission to block the user's role from accessing the interface will be added to the permission 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 specification can indeed achieve the following effects: Improve security: Reduce the risk of security vulnerabilities by centrally managing authentication and authorization. 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, reducing the processing burden of microservices and improving 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, users' access rights to microservices can be controlled in a fine-grained manner to prevent vertical unauthorized access. Support dynamic monitoring: Lack of dynamic permission monitoring makes it impossible to detect missing permission configuration problems in a timely manner.

[0265] Although the present specification provides method operation steps as described in the embodiments or flow charts, more or less 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 a unique 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 "include", "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 a 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. The first, second, etc. words are used to represent the name, and do not represent any particular order.

[0266] Those skilled in the art also know that, in addition to implementing the controller in a purely computer-readable program code, the controller can be made to implement the same function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered as a hardware component, and the devices for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules for implementing the method and structures within the hardware component.

[0267] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. 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 communication 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 known that those skilled in the art can clearly understand that the present specification can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present specification can essentially be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a 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 each embodiment of the present specification or some parts of the embodiments.

[0269] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. This specification can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

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

Claims

1. A method for processing transaction data, characterized in that: 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, and the method includes: Receive a target transaction service request; wherein the target transaction service 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 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 authority authentication service according to the preset business authority management rules; When the target user's login token validity verification is confirmed to have passed, the target transaction service is detected to determine whether it is a transaction service that prevents vertical overreaching according to the preset business authority management rules and the transaction identifier of the target transaction service; When it is determined that the target transaction business service belongs to the transaction business service that prevents vertical overreach, 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, 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: Receiving 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; When it is determined that the target user has passed the login verification, the login verification service is called 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 and 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; When it is determined that the login token of the target user exists in the redis cache of the authentication service, obtain the validity tag and current time of the login token of the target user; According to the valid tag and current time of the target user's login token, check whether the target user's login token is currently valid; 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.

5. The method according to claim 1, characterized in that 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: When it is determined that the target user's login token validity verification fails, a first error message is generated; A first error notification is sent to the target client application.

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

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; 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 label 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 match is passed.

8. The method according to claim 1, characterized in that After performing authority matching according to the preset business authority management rules, using the authority parameters of the target transaction business service and the authority data group of the target user, the method further includes: If it is determined that the permission match fails, a second error prompt is generated; A second error notification is sent 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; According to the key fields, the gateway logs in the current time period are split into a successful data set about successful calls to the transaction business service and a failed data set about failed calls to the transaction business service; Generate rule update data about preset business authority management rules according to 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 business authority management rule according to the rule update data.

10. The method according to claim 9, characterized in that Generate rule update data about preset business authority management rules according to 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 calls to transaction business services 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 about preset business authority management rules according to the success data set and / or the 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; According to the frequency of successful calls to each transaction business service by each target client application in the current time period, detecting whether at least one transaction business service has a frequency of successful calls in the current time period greater than a preset reference threshold; 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 regarding adding or updating permission matching rules for the transaction business service is generated as rule update data regarding the preset business permission management rules.

12. A transaction data processing device, characterized in that: 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, and the device includes: A receiving module, configured to receive a target transaction service request; wherein the target transaction service 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 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 authority authentication service according to the preset business authority management rules; A detection module is used to detect whether the target transaction business service belongs to the transaction business service for preventing vertical overreaching according to the preset business authority management rules and the transaction identifier of the target transaction business service when it is determined that the validity verification of the login token of the target user has passed; 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 belongs to the transaction business service for preventing 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 being executed by a processor.

Images