Transaction request processing method and device

By adding menu encoding to the header information of transaction requests and performing authentication processing at the back-end gateway layer, the problems of poor permission control effect and large changes to system code in the existing technology are solved, efficient and accurate permission management is achieved, and changes to the original system code are reduced.

CN119671568APending Publication Date: 2025-03-21CHINA CONSTRUCTION BANK +1
View PDF 7 Cites 0 Cited by

Patent Information

Application Number
CN202411742955.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-29
Publication Date
2025-03-21

AI Technical Summary

Technical Problem

The prior art has poor authority control effects in realizing system security, and has greatly changed the original system code, affecting the normal operation of the system.

Method used

By adding menu encoding to the header information of the transaction request and performing authentication processing at the back-end gateway layer, it is determined whether the user has access rights, and only after the authentication is passed, the transaction request will be distributed to the target application.

Benefits of technology

It realizes that while minimizing changes to the original system code, improves the efficiency and accuracy of permission management, reduces the pressure on applications, and avoids adjustments to each application.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119671568A_ABST
    Figure CN119671568A_ABST
Patent Text Reader

Abstract

The invention provides a transaction request processing method and device, and relates to the technical field of big data, and the method comprises the steps that a gateway layer at a back end obtains a transaction request, and a designated field of header information of the transaction request carries a menu code; a back-end gateway layer obtains a user identifier of a user sending the transaction request; the gateway layer at the back end obtains the identification code of the requested transaction from the transaction request; a back-end gateway layer determines whether the user has access authority according to the menu code, the user identifier and the identification code of the transaction; and distributing the transaction request to an application corresponding to the transaction request through a gateway in a back-end gateway layer under the condition that the user has the access authority. Through the scheme, the technical problems that the existing authentication effect is poor and the original system code is greatly changed are solved, and the technical effect of improving the authentication accuracy under the condition that the original system code is changed as little as possible is achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application belongs to the field of big data technology, and in particular, relates to a transaction request processing method and device. Background Art

[0002] With the continuous development of Internet technology, the requirements for system security are getting higher and higher. At present, the main ways to protect data in application systems are: encryption, horizontal permission control and vertical permission control. The previous system construction focused mainly on functional construction, with less consideration for data security, which made the system vulnerable to attacks and the data in the system easy to be stolen or attacked. For security protection, especially the control of horizontal and vertical permissions, it is often necessary to change a lot of code, and the settings will affect the normal operation of the business system.

[0003] There is currently no effective solution for how to efficiently perform permission control to protect the security of the system. Summary of the invention

[0004] The purpose of this application is to provide a transaction request processing method and device, which can achieve efficient management of permissions while reducing changes to the original system code.

[0005] The present application provides a transaction request processing method and device which are implemented as follows:

[0006] A transaction request processing method, the method comprising:

[0007] The gateway layer of the backend obtains a transaction request, wherein a menu code is carried in a designated field of header information of the transaction request, wherein the menu code is used to associate a business function from which the transaction request originates, and a business function is composed of multiple transactions;

[0008] The back-end gateway layer obtains the user ID of the user who sends the transaction request;

[0009] The back-end gateway layer obtains the identification code of the requested transaction from the transaction request;

[0010] The backend gateway layer determines the role assigned to the user according to the user identifier as the target role, and obtains the scope of authority assigned to the target role;

[0011] The backend gateway layer associates and matches the menu code according to the scope of authority assigned to the target role, and determines whether the target role is assigned access authority for the business function corresponding to the menu code;

[0012] In the case where it is determined that the target role is assigned the access right to the business function corresponding to the menu code, determining whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code;

[0013] When it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, it is determined that the user has access rights, and the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

[0014] In one embodiment, the backend gateway layer obtains a transaction request, including:

[0015] The back-end gateway layer intercepts the transaction requests sent by the front-end by setting up interceptors;

[0016] The intercepted transaction request is used as the acquired transaction request;

[0017] The front end generates a transaction request in the following manner: after the user logs in, a menu list is obtained from the cache of the front end, wherein the menu list stores menu codes corresponding to a plurality of business functions;

[0018] According to the interface logged in by the user, the menu code associated with the logged in interface is matched in the menu list;

[0019] The front end adds a request header to the request message, and adds the matched menu code to the request header to obtain the transaction request.

[0020] In one embodiment, a request header is added to the request message at the front end, and the matched menu code is added to the request header. After obtaining the transaction request, the following is further included:

[0021] The front end encrypts the business message in the transaction request with the menu code added through the SDK;

[0022] Accordingly, when it is determined that the user has access rights, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend, including:

[0023] Decrypting the business message in the transaction request through the back-end gateway layer;

[0024] After successful decryption, the decrypted transaction request is distributed to the application corresponding to the transaction request.

[0025] In one embodiment, according to the interface logged in by the user, matching and obtaining the menu code associated with the logged in interface in the menu list includes:

[0026] According to the user login interface, obtain the business function corresponding to the login page as the target business function;

[0027] Retrieving the menu list;

[0028] Determine whether the target service function is already in the menu list and is configured with a menu code;

[0029] If it is determined that the target business function is not configured with a menu code in the menu list, determining that the transaction request fails;

[0030] When it is determined that the target business function is configured with a menu code in the menu list, the menu code associated with the logged-in interface is matched in the menu list.

[0031] In one embodiment, the backend gateway layer obtains the user identifier of the user who sends the transaction request, including:

[0032] The backend gateway layer extracts token information from the transaction request, wherein the token information is carried in the header information field of the transaction request;

[0033] The backend gateway layer extracts user information from the token information;

[0034] A user identifier of the user who sends the transaction request is obtained from the user information.

[0035] In one embodiment, after the back-end gateway layer determines whether the user has access rights according to the menu code, the user identification and the transaction identification code, the back-end gateway layer further includes:

[0036] If it is determined that the user does not have access rights, intercepting and prohibiting the transaction request;

[0037] After the blocking is completed, a reminder message is returned to the front end, wherein the reminder message is used to indicate that the permission check has not passed.

[0038] A transaction request processing device, located at the back-end gateway layer, comprising:

[0039] A first acquisition module is used to acquire a transaction request, wherein a specified field of header information of the transaction request carries a menu code, wherein the menu code is used to associate a business function from which the transaction request originates, and a business function is composed of multiple transactions;

[0040] A second acquisition module, used to acquire a user identifier of a user who sends the transaction request;

[0041] A third acquisition module, configured to acquire an identification code of the requested transaction from the transaction request;

[0042] A first determination module is used to determine the role assigned to the user according to the user identifier as a target role, and obtain the authority range assigned to the target role;

[0043] A second determination module is used to associate and match the menu code with the scope of authority assigned to the target role, and determine whether the target role is assigned access authority for the business function corresponding to the menu code;

[0044] a third determination module, configured to determine, if it is determined that the target role is assigned the access right to the business function corresponding to the menu code, whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code;

[0045] The distribution module is used to determine that the user has access rights when it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, and distribute the transaction request to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

[0046] An electronic device comprises a processor and a memory for storing instructions executable by the processor, wherein the steps of the above method are implemented when the processor executes the instructions.

[0047] A computer-readable storage medium stores a computer program / instruction, which implements the steps of the above method when executed by a processor.

[0048] A computer program product comprises a computer program / instruction, which implements the steps of the above method when executed by a processor.

[0049] The present application provides a transaction request processing method and device, which obtains a transaction request carrying a menu code, a user ID of the user who sends the transaction request, and an identification code of the transaction through the gateway layer of the back end, and determines the user's access rights based on these three. Only when it is determined that there is access rights, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the back end. In the above example, the query is performed using the menu code as a query condition, and the query efficiency is higher. The joint query of the three parameters can improve the accuracy of authentication. Furthermore, unified processing through the gateway at the back end can reduce the pressure on the application, and because the gateway forwards after authentication, it can avoid adjusting each application, thereby reducing the changes to the original system code. The above scheme solves the existing technical problems of poor authentication effect and large changes to the original system code, and achieves the technical effect of improving the accuracy of authentication while minimizing the changes to the original system code. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0051] Figure 1 It is a method flow chart of an embodiment of the transaction request processing method provided by the present application;

[0052] Figure 2 This is a flow chart of a method for generating a transaction request in a front end according to an embodiment of the present application;

[0053] Figure 3 This is a method flow chart of an embodiment of matching a menu code associated with a logged-in interface in a menu list provided by the present application;

[0054] Figure 4 It is a hardware structure block diagram of an electronic device of a transaction request processing method provided by the present application;

[0055] Figure 5 It is a schematic diagram of the module structure of an embodiment of the transaction request processing device provided by the present application. DETAILED DESCRIPTION

[0056] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0057] At present, the solution to vertical unauthorized access is generally to obtain the fields of the request transaction message in the transaction in a specific scenario, and then control the permissions in the specific transaction, for example: determine the user's role and permissions based on the fields to determine the data that can be returned. Because this method is based on the request transaction message, if the attacker tampers with the request transaction message, it is easy to be attacked by unauthorized access, causing users without high permissions to see high-authorized data. However, for large systems, there are generally thousands of transactions. If the control code is written separately for each transaction, the workload is huge. Moreover, the current control granularity is generally refined to personnel control and transaction control. If a transaction is used under multiple functions, there will be problems of bypassing functional permissions through transactions.

[0058] Based on this, in this example, a transaction request processing method is proposed. By adding a "menu code" to the header information of the transaction request, the transaction message in the transaction request will not be affected, and only the header information needs to be adjusted. Furthermore, authentication is performed through the "back-end gateway layer". After the authentication is passed, the transaction message is distributed to the target application through the back-end gateway layer. In this way, there is no need to adjust subsequent applications, and there is no need to write control codes for each application separately, and fewer code changes to the original business system.

[0059] Figure 1 It is a method flow chart of an embodiment of the transaction request processing method provided by the present application. Although the present application provides method operation steps or device structures as shown in the following embodiments or drawings, more or fewer operation steps or module units may be included in the method or device based on routine or without creative labor. In the steps or structures where there is no necessary causal relationship logically, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure described in the embodiments of the present application and shown in the drawings. When the method or module structure is applied to an actual device or terminal product, it can be connected according to the method or module structure shown in the embodiments or drawings for sequential execution or parallel execution (for example, a parallel processor or a multi-threaded processing environment, or even a distributed processing environment).

[0060] Specifically, Figure 1As shown, the transaction request processing method may include the following steps:

[0061] Step 101: The gateway layer of the backend obtains a transaction request, wherein a menu code is carried in a designated field of the header information of the transaction request, wherein the menu code is used to associate the business function from which the transaction request originates, and a business function is composed of multiple transactions;

[0062] In order to achieve efficient interception of front-end transaction requests and to perform authentication processing on the transaction requests first, an interceptor can be set at the back-end gateway layer to intercept the transaction data. Specifically, the back-end gateway layer obtains the transaction request, which can include: the back-end gateway layer intercepts the transaction request sent by the front-end by setting an interceptor; and uses the intercepted transaction request as the obtained transaction request. For the front-end, it can be as follows: Figure 2 The method steps shown generate a transaction request:

[0063] Step 201: after the user logs in, a menu list is obtained from the cache of the front end, wherein the menu list stores menu codes corresponding to multiple business functions;

[0064] Step 202: According to the interface logged in by the user, a menu code associated with the logged in interface is matched in the menu list;

[0065] Step 203: the front end adds a request header to the request message, and adds the matched menu code to the request header to obtain the transaction request.

[0066] That is, in order to improve the efficiency of obtaining the menu code, the pre-configured menu code can be stored in the cache of the front end, so that the front end can respond in time to obtain the menu code, thereby improving the efficiency of generating transaction requests. Further, in order to avoid modifying the transaction message, the menu code is added to the header of the transaction request.

[0067] Step 102: The back-end gateway layer obtains the user ID of the user who sends the transaction request;

[0068] Specifically, in a transaction request, the front end first obtains a token through user login, and each transaction request of the interface needs to carry token information in the header information. The back end can process the token information, parse and obtain user information from the token information, and thus obtain the user ID of the user. That is, the gateway layer of the back end can extract the token information from the transaction request, wherein the token information is carried in the header information field of the transaction request; the gateway layer of the back end extracts the user information from the token information; and obtains the user ID of the user who sent the transaction request from the user information.

[0069] Step 103: The back-end gateway layer obtains the identification code of the requested transaction from the transaction request;

[0070] Step 104: The backend gateway layer determines the role assigned to the user according to the user identifier, takes it as the target role, and obtains the scope of authority assigned to the target role;

[0071] Step 105: The backend gateway layer associates and matches the menu code according to the scope of authority assigned to the target role, and determines whether the target role is assigned access authority for the business function corresponding to the menu code;

[0072] Step 106: when it is determined that the target role is assigned the access right of the business function corresponding to the menu code, determining whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code;

[0073] Step 107: When it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, it is determined that the user has access rights, and the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

[0074] Specifically, the above step 202 can be performed as follows: Figure 3 As shown, the following steps are included:

[0075] Step 301: According to the user login interface, obtain the business function corresponding to the login page as the target business function;

[0076] Step 302: Retrieve the menu list;

[0077] Step 303: Determine whether the target service function is in the menu list and is configured with a menu code;

[0078] Step 304: if it is determined that the target business function is not configured with a menu code in the menu list, determining that the transaction request fails;

[0079] Step 305: When it is determined that the target business function is configured with a menu code in the menu list, the menu code associated with the logged-in interface is matched in the menu list.

[0080] That is, a global judgment is made based on the "menu code". If the corresponding business function is not recorded in the menu list, the transaction request is directly determined to have failed. If the corresponding business function is recorded in the menu list, further judgment and decision are made.

[0081] That is, in the above example, the transaction request carrying the menu code, the user ID of the user who sent the transaction request, and the transaction identification code are obtained through the gateway layer of the backend, and the user access rights are determined based on these three. Only when it is determined that the access rights exist, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend. In the above example, the query is performed using the menu code as the query condition, which is more efficient. The accuracy of authentication can be improved by performing a joint query through the three parameters. Furthermore, unified processing through the gateway at the backend can reduce the pressure on the application, and because the gateway forwards after authentication, it can avoid adjusting each application, thereby reducing the changes to the original system code. The above solution solves the existing technical problems of poor authentication effect and large changes to the original system code, and achieves the technical effect of improving the accuracy of authentication while minimizing the changes to the original system code.

[0082] For example, the administrator first creates a role in the system and grants the current role the permission to access the menu. Each role can be attached to an organization, and the user role is associated with the menu code. The menu refers to the business content. For example, membership renewal can be used as a menu, and one menu corresponds to one id. The above administrator can set up the personnel of the organization and assign different roles according to the different permissions of the personnel. After the personnel are assigned the role, they can obtain the access rights of the menu corresponding to the role.

[0083] In order to prevent the sent transaction request from being cracked, which would affect the data security of the system, a request header is added to the request message at the front end, and the matched menu code is added to the request header. After obtaining the transaction request, it may also include: the front end encrypts the business message in the transaction request with the menu code added through the SDK; accordingly, when it is determined that the user has access rights, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the back end, including: decrypting the business message in the transaction request through the gateway layer of the back end; after the decryption is successful, distributing the decrypted transaction request to the application corresponding to the transaction request.

[0084] That is, the front end encrypts the business message in the transaction request through the SDK, and the back end encrypts the encrypted business message through the gateway layer, and distributes it to the application after decryption. This can ensure the security of the business message on the one hand, and avoid modification of the application on the other hand.

[0085] In the specific implementation, the front-end can also encrypt only the request header through the SDK, so that the back-end gateway layer only needs to decrypt the request header. The front-end can also encrypt both the request header and the business message through the SDK, so that the back-end gateway layer needs to decrypt both the request header and the business message. The specific encryption and decryption objects can be selected according to the security requirements and focus, and this application does not limit this.

[0086] Furthermore, after the gateway layer of the back-end determines whether the user has access rights based on the menu code, the user ID and the transaction identification code, the transaction request may be intercepted and prohibited if it is determined that the user does not have access rights; after interception and prohibition, a reminder message is returned to the front-end, wherein the reminder message is used to indicate that the permission check has failed.

[0087] The above method is described below in conjunction with a specific embodiment. However, it is worth noting that this specific embodiment is only for better illustrating the present application and does not constitute an improper limitation on the present application.

[0088] In view of the problems of many changes to the system code and low authentication efficiency in the existing transaction system authentication, this example provides a configuration-based method to solve the vertical over-authorization of the system. In the method provided in this example, there is no need to modify the business code, so as to avoid affecting the existing functions of the system. The front end adopts a unified method for processing, and the back end also adopts a unified method for processing, so as to ensure that the code is modified slightly, so that the authentication capability of the existing service can be quickly enhanced. Furthermore, the method of adding menu (function) code in the request header does not involve changes in business messages, so as to avoid affecting business functions. Authentication control is more detailed and flexible, and can realize the combination of personnel, roles, functions and transactions, and can flexibly adapt to authentication scenarios. Because the authentication is set to be configurable, the situation of permission control can be more clearly and visually understood, and it can be configurable, which can reduce the invasive modification of the original business system, so as to avoid affecting the existing functions of the system. Furthermore, by adding information such as menu id and role in transaction judgment, it can increase the difficulty for attackers to bypass the front-end interface and directly attack the back-end server.

[0089] Specifically, the administrator first creates a role in the system and grants the current role the menu permissions it can access. Each role can be attached to an organization. The menu refers to the business content. For example, membership renewal can be used as a menu, and one menu corresponds to one id. The above administrator can set up the personnel of the organization and grant different roles according to the different permissions of the personnel. After the personnel are granted the role, they can obtain the access rights to the menu corresponding to the role.

[0090] In view of the situation that the attacker does not attack through the interface but directly through the service call in the existing business system, in this example, the correspondence between transactions and menus is configured. Only when all transactions called by the front end of the system have been configured, the corresponding menu also has the permission to access the back end. The front end adds a request header to the transaction request of the menu page and adds the menu code in the request header. The menu code and the business message in the transaction request can be encrypted to prevent tampering without interfering with the business message information. The back end can do a common pre-processing through the aspect technology. The pre-processing will obtain the current user information, the current user role information, and the transaction URI (transaction code) information according to the token. The menu code information is uniformly carried in the transaction request of the front end. The authentication configuration information is obtained through this information to determine whether the request has permission to access. Among them, a menu represents a function, and the implementation of a function is formed by multiple transactions. That is, the interface request carries the token obtained by the front end through user login. Each interface request needs to carry the token information in the header information. The back end can obtain the token information and parse the token information to obtain the user information.

[0091] Furthermore, for example, a transaction sent from a member payment page will automatically add the menu code corresponding to the member payment page, and the transaction identification code is also carried in the transaction request. Therefore, it is equivalent to performing a joint query through the menu code, the transaction identification code and the user identification.

[0092] When implementing, the backend can be implemented by interceptors. When a transaction request enters the service, the authentication interceptor will obtain the transaction number, read the menu code and transaction number, and perform default processing (ban) if the menu code and transaction number are not configured. If it is determined that the menu code and transaction number have been configured, it will be processed according to the configuration type. Specifically, it can be divided into but not limited to the following types:

[0093] 1) Visitors: the authentication interceptor directly allows this type of transaction;

[0094] 2) Login, the authentication interceptor determines whether the transaction request is initiated by a valid logged-in user. If it is initiated by a valid logged-in user, access is allowed, otherwise it is intercepted;

[0095] 3) Large-scale authentication ban: the authentication processor will obtain the role information of the currently logged-in user, and use the transaction number information and role information to determine whether the transaction permissions corresponding to the user's role are configured. If yes, access is allowed, otherwise it is blocked;

[0096] 4) Refined blocking authentication: The authentication processor obtains the role information of the currently logged-in user, and obtains whether the transaction permission corresponding to the role of this user is configured through the transaction number information, the menu code in the request header, and the role information. If yes, access is allowed, otherwise it is blocked.

[0097] That is, the front end adds a request header to the transaction request, and the back end sets an interceptor to intercept it. The gateway layer of the back end obtains the menu code from the request header. Because the back end can obtain the login information, it knows whether the role has the authority. This is equivalent to introducing the menu code as a query condition, making the authentication more accurate.

[0098] Specifically, the menu list can be cached in the front-end cache, and the current person can get the menu list when logging in. There are many menu codes stored in the menu list, so the corresponding menu code can be directly matched and added to the request header. The menu list can be configured with menus and functions under the menu, that is, it can be set in the form of menus and transactions, multiple menus can be set, and transactions under each menu can be set.

[0099] Because the menu list is cached in the front-end cache, the corresponding back-end also needs the menu list when matching, which involves the synchronization of the front-end and back-end cache lists. Based on this, you can set TTL (Time to Live) for the cache on the back-end, and get the latest data from the front-end after the back-end cache expires periodically, so that you can ensure that the back-end cache data will not be outdated for a long time. Furthermore, the front-end cache can also actively notify the back-end cache of the invalidation when the data is updated. Alternatively, the front-end data can also set a version number, and increase the version number when the data is updated. The back-end cache can determine whether the data needs to be updated based on the version number.

[0100] In order to ensure the consistency of double-write data, you can synchronize the double-write, that is, update the back-end cache while updating the front-end cache. This requires ensuring strong consistency and synchronization between the front-end and the back-end. In order to improve the overall performance of the system, you can also use asynchronous double-write, that is, update the front-end cache first, and update the back-end cache through asynchronous tasks, thereby improving the overall performance of the system. In order to ensure the effectiveness of asynchronous double-write, you need to set a delay and failure retry mechanism.

[0101] Furthermore, for the asynchronous dual-write method, when an asynchronous task fails, the task is sent to a message queue, and a retry strategy (e.g., exponential backoff) is set. For the message queue, the system will periodically retry to execute these tasks until they succeed or the maximum number of retries is reached. By monitoring the message queue and task status, long-unfinished tasks can be discovered and processed in a timely manner. For the asynchronous dual-write method, a compensation transaction mechanism can also be set. Compensation transactions are a method of performing reverse operations to restore system consistency when a task fails. Specifically, before each task is executed, compensation operations are pre-defined and executed when the task fails. Compensation transactions can ensure that the final state of the system remains consistent even if some tasks fail, especially in some financial transactions and other fields that require high data consistency. Alternatively, for the asynchronous dual-write method, a unique identifier (e.g., UUID) can also be set to track each task to avoid data inconsistency caused by repeated execution. When a task fails and is retried, the unique identifier is checked to ensure that the task is only processed once.

[0102] When implementing, the front end can encrypt the request header in the transaction request through the SDK, obtain the header information at the back-end gateway layer for decryption, and distribute it to the corresponding back-end application after decryption. That is, by setting an interceptor at the back-end gateway layer to perform menu verification, and placing the interceptor verifier at the gateway layer, the gateway can handle it uniformly, reducing the pressure on the application, and the gateway sends it to multiple applications, avoiding adjustments to each application.

[0103] In the above example, a general configurable method is given, which reduces the intrusive modification of the source system and avoids the impact on existing functions. Furthermore, by adding menu codes and role information in transaction judgment, it is more difficult for attackers to bypass the front-end interface and directly attack the back-end server. Furthermore, by adding menu codes in the request header, it does not involve changes to the business message, avoiding the impact on the business, and the configuration operation is visualized, making the permission control clearer and controllable.

[0104] The method embodiments provided in the above embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on an electronic device as an example, Figure 4 This is a hardware structure diagram of an electronic device for a transaction request processing method provided by this application. Figure 4 As shown, the electronic device 10 may include one or more (only one is shown in the figure) processors 02 (the processor 02 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 04 for storing data, and a transmission module 06 for communication functions. It can be understood by those skilled in the art that Figure 4The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 4 More or fewer components as shown, or with Figure 4 Different configurations are shown.

[0105] The memory 04 can be used to store software programs and modules of application software, such as program instructions / modules corresponding to the transaction request processing method in the embodiment of the present application. The processor 02 executes various functional applications and data processing by running the software programs and modules stored in the memory 04, that is, the transaction request processing method of the above-mentioned application is realized. The memory 04 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 04 may further include a memory remotely arranged relative to the processor 02, and these remote memories can be connected to the electronic device 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0106] The transmission module 06 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the electronic device 10. In one example, the transmission module 06 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 06 can be a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet wirelessly.

[0107] At the software level, the transaction request processing device is located at the back-end gateway layer and can be Figure 5 As shown, including:

[0108] A first acquisition module 501 is used to acquire a transaction request, wherein a specified field of header information of the transaction request carries a menu code, wherein the menu code is used to associate the business function from which the transaction request originates, and a business function is composed of multiple transactions;

[0109] A second acquisition module 502 is used to acquire a user identifier of a user who sends the transaction request;

[0110] A third acquisition module 503, configured to acquire an identification code of the requested transaction from the transaction request;

[0111] A first determination module 504 is used to determine the role assigned to the user according to the user identifier as a target role, and obtain the authority range assigned to the target role;

[0112] The second determination module 505 is used to associate and match the menu code with the scope of authority assigned to the target role, and determine whether the target role is assigned access authority for the business function corresponding to the menu code;

[0113] A third determination module 506 is used to determine whether the target role is assigned a transaction item corresponding to the transaction identification code according to the transaction identification code when it is determined that the target role is assigned the access right of the business function corresponding to the menu code;

[0114] The distribution module 507 is used to determine that the user has access rights when it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, and distribute the transaction request to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

[0115] In one embodiment, the back-end gateway layer obtains the transaction request, which may include: the back-end gateway layer intercepts the transaction request sent by the front-end by setting an interceptor; and uses the intercepted transaction request as the obtained transaction request; wherein the front-end generates the transaction request in the following manner: after the user logs in, obtains a menu list from the front-end cache, wherein the menu list stores menu codes corresponding to multiple business functions; according to the user login interface, matches the menu code associated with the login interface in the menu list; the front-end adds a request header in the request message, and adds the matched menu code to the request header to obtain the transaction request.

[0116] In one embodiment, after the front end adds a request header to the request message and adds the matched menu code to the request header to obtain the transaction request, it may also include: the front end encrypts the business message in the transaction request with the menu code added through the SDK; accordingly, when it is determined that the user has access rights, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the back end, which may include: decrypting the business message in the transaction request through the gateway layer of the back end; after the decryption is successful, distributing the decrypted transaction request to the application corresponding to the transaction request.

[0117] In one embodiment, matching the menu code associated with the login interface in the menu list according to the interface through which the user logs in may include: obtaining the business function corresponding to the login page as the target business function according to the interface through which the user logs in; calling the menu list; determining whether the target business function is already in the menu list and is configured with a menu code; determining that the transaction request has failed if it is determined that the target business function is not configured with a menu code in the menu list; and matching the menu code associated with the login interface in the menu list if it is determined that the target business function is configured with a menu code in the menu list.

[0118] In one embodiment, the second acquisition module 502 may specifically extract token information from the transaction request, wherein the token information is carried in a header information field of the transaction request; the back-end gateway layer extracts user information from the token information; and obtains a user identifier of a user who sends the transaction request from the user information.

[0119] In one embodiment, after the gateway layer of the back-end determines whether the user has access rights based on the menu code, the user identification and the transaction identification code, it may also include: if it is determined that the user does not have access rights, intercepting and prohibiting the transaction request; after intercepting and prohibiting, returning a reminder message to the front-end, wherein the reminder message is used to indicate that the permission check has failed.

[0120] The embodiments of the present application also provide a specific implementation of an electronic device capable of implementing all the steps in the transaction request processing method in the above embodiments, wherein the electronic device specifically includes the following contents: a processor, a memory, a communications interface, and a bus; wherein the processor, the memory, and the communications interface communicate with each other through the bus; the processor is used to call a computer program in the memory, and when the processor executes the computer program, all the steps in the transaction request processing method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0121] Step 1: The gateway layer of the backend obtains a transaction request, wherein a menu code is carried in a designated field of the header information of the transaction request, wherein the menu code is used to associate the business function from which the transaction request originates, and a business function is composed of multiple transactions;

[0122] Step 2: The back-end gateway layer obtains the user ID of the user who sends the transaction request;

[0123] Step 3: The back-end gateway layer obtains the identification code of the requested transaction from the transaction request;

[0124] Step 4: The backend gateway layer determines the role assigned to the user according to the user identifier as the target role, and obtains the scope of authority assigned to the target role;

[0125] Step 5: The back-end gateway layer associates and matches the menu code according to the scope of authority assigned to the target role, and determines whether the target role is assigned access authority for the business function corresponding to the menu code;

[0126] Step 6: When it is determined that the target role is assigned the access right to the business function corresponding to the menu code, determining whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code;

[0127] Step 7: When it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, it is determined that the user has access rights, and the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

[0128] The embodiments of the present application also provide a computer-readable storage medium capable of implementing all the steps of the transaction request processing method in the above embodiments. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, all the steps of the transaction request processing method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0129] Step 1: The gateway layer of the backend obtains a transaction request, wherein a menu code is carried in a designated field of the header information of the transaction request, wherein the menu code is used to associate the business function from which the transaction request originates, and a business function is composed of multiple transactions;

[0130] Step 2: The back-end gateway layer obtains the user ID of the user who sends the transaction request;

[0131] Step 3: The back-end gateway layer obtains the identification code of the requested transaction from the transaction request;

[0132] Step 4: The backend gateway layer determines the role assigned to the user according to the user identifier as the target role, and obtains the scope of authority assigned to the target role;

[0133] Step 5: The back-end gateway layer associates and matches the menu code according to the scope of authority assigned to the target role, and determines whether the target role is assigned access authority for the business function corresponding to the menu code;

[0134] Step 6: When it is determined that the target role is assigned the access right to the business function corresponding to the menu code, determining whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code;

[0135] Step 7: When it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, it is determined that the user has access rights, and the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

[0136] From the above description, it can be seen that the embodiment of the present application obtains the transaction request carrying the menu code, the user identification of the user sending the transaction request, and the identification code of the transaction through the gateway layer of the backend, and determines the user access rights based on these three. Only when it is determined that there is access rights, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend. In the above example, the query is performed by using the menu code as the query condition, and the query efficiency is higher. The joint query through the three parameters can improve the accuracy of authentication. Furthermore, unified processing through the gateway at the backend can reduce the pressure on the application, and because the gateway forwards after authentication, it can avoid adjusting each application, thereby reducing the change of the original system code. The above scheme solves the existing technical problems of poor authentication effect and large changes to the original system code, and achieves the technical effect of improving the accuracy of authentication while minimizing the change of the original system code.

[0137] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0138] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the hardware + program embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0139] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0140] Although the present application provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative labor. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the actual device or client product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in a parallel processor or multi-threaded processing environment).

[0141] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0142] Although the present specification embodiment provides the method operation steps as described in the embodiment or flow chart, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiment is only one way in the order of execution of many steps, and does not represent a unique execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiment or the accompanying drawings (such as 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 equipment including a series of elements not only includes those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements.

[0143] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing the embodiments of this specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing 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. For example, 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.

[0144] 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.

[0145] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0146] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0147] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0148] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0149] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0150] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0151] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, the embodiments of this specification may take the form of complete hardware embodiments, complete software embodiments or embodiments combining software and hardware. Moreover, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0152] The present specification embodiments 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, etc. that perform specific tasks or implement specific abstract data types. The present specification embodiments 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 storage media, including storage devices.

[0153] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the embodiment of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, in the absence of contradiction, a person skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0154] The above is only an example of the embodiment of the present specification and is not intended to limit the embodiment of the present specification. For those skilled in the art, the embodiment of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiment of the present specification shall be included in the scope of the claims of the embodiment of the present specification.

Claims

1. A transaction request processing method, characterized in that: The method comprises: The gateway layer of the backend obtains a transaction request, wherein a menu code is carried in a designated field of header information of the transaction request, wherein the menu code is used to associate a business function from which the transaction request originates, and a business function is composed of multiple transactions; The back-end gateway layer obtains the user ID of the user who sends the transaction request; The back-end gateway layer obtains the identification code of the requested transaction from the transaction request; The backend gateway layer determines the role assigned to the user according to the user identifier as the target role, and obtains the scope of authority assigned to the target role; The backend gateway layer associates and matches the menu code according to the scope of authority assigned to the target role, and determines whether the target role is assigned access authority for the business function corresponding to the menu code; In the case where it is determined that the target role is assigned the access right to the business function corresponding to the menu code, determining whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code; When it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, it is determined that the user has access rights, and the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

2. The method according to claim 1, characterized in that The backend gateway layer obtains the transaction request, including: The back-end gateway layer intercepts the transaction requests sent by the front-end by setting up interceptors; The intercepted transaction request is used as the acquired transaction request; The front end generates a transaction request in the following manner: after the user logs in, a menu list is obtained from the cache of the front end, wherein the menu list stores menu codes corresponding to a plurality of business functions; According to the interface logged in by the user, the menu code associated with the logged in interface is matched in the menu list; The front end adds a request header to the request message, and adds the matched menu code to the request header to obtain the transaction request.

3. The method according to claim 2, characterized in that A request header is added to the request message at the front end, and the matched menu code is added to the request header. After obtaining the transaction request, the following is also included: The front end encrypts the business message in the transaction request with the menu code added through the SDK; Accordingly, when it is determined that the user has access rights, the transaction request is distributed to the application corresponding to the transaction request through the gateway in the gateway layer of the backend, including: Decrypting the business message in the transaction request through the back-end gateway layer; After successful decryption, the decrypted transaction request is distributed to the application corresponding to the transaction request.

4. The method according to claim 3, characterized in that According to the interface logged in by the user, the menu code associated with the logged in interface is matched in the menu list, including: According to the user login interface, obtain the business function corresponding to the login page as the target business function; Retrieving the menu list; Determine whether the target service function is already in the menu list and is configured with a menu code; If it is determined that the target business function is not configured with a menu code in the menu list, determining that the transaction request fails; When it is determined that the target business function is configured with a menu code in the menu list, the menu code associated with the logged-in interface is matched in the menu list.

5. The method according to claim 1, characterized in that The backend gateway layer obtains the user ID of the user who sends the transaction request, including: The backend gateway layer extracts token information from the transaction request, wherein the token information is carried in the header information field of the transaction request; The backend gateway layer extracts user information from the token information; A user identifier of the user who sends the transaction request is obtained from the user information.

6. The method according to claim 1, characterized in that After the back-end gateway layer determines whether the user has access rights according to the menu code, the user identification and the transaction identification code, the back-end gateway layer further includes: If it is determined that the user does not have access rights, intercepting and prohibiting the transaction request; After the blocking is completed, a reminder message is returned to the front end, wherein the reminder message is used to indicate that the permission check has not passed.

7. A transaction request processing device, characterized in that: Located at the backend gateway layer, including: A first acquisition module is used to acquire a transaction request, wherein a specified field of header information of the transaction request carries a menu code, wherein the menu code is used to associate a business function from which the transaction request originates, and a business function is composed of multiple transactions; A second acquisition module, used to acquire a user identifier of a user who sends the transaction request; A third acquisition module, configured to acquire an identification code of the requested transaction from the transaction request; A first determination module is used to determine the role assigned to the user according to the user identifier as a target role, and obtain the authority range assigned to the target role; A second determination module is used to associate and match the menu code with the scope of authority assigned to the target role, and determine whether the target role is assigned access authority for the business function corresponding to the menu code; a third determination module, configured to determine, if it is determined that the target role is assigned the access right to the business function corresponding to the menu code, whether the target role is assigned the transaction item corresponding to the transaction identification code according to the transaction identification code; The distribution module is used to determine that the user has access rights when it is determined that the target role is assigned a transaction item corresponding to the identification code of the transaction, and distribute the transaction request to the application corresponding to the transaction request through the gateway in the gateway layer of the backend.

8. An electronic device comprising a processor and a memory for storing instructions executable by the processor, characterized in that: When the processor executes the instructions, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Citation Information

Patent Citations

  • System access permission granting method and device, server and storage medium

    CN111698228A

  • Interface authority verification method and system, electronic equipment, and storage medium

    CN113672896A

  • Data processing method and device and storage medium

    CN115664808A

  • Gateway-based interface authentication method and device

    CN116488837A

  • Menu and page rendering method and device and electronic equipment

    CN117170784A