Data query request processing method, business system, computer equipment and storage medium

Abstract

The invention relates to a data query request processing method, a business system, computer equipment and a storage medium. The method comprises the following steps: a gateway layer receives a data query request, verifies a user login state, injects user permission data into a request parameter, calls a target service according to a user request address, and executes business logic of the called service; calling of a gateway layer for a target service is intercepted through an interface section layer, and user permission data in a request parameter is stored in a thread local variable; the dubbo section layer transparently transmits the user permission data to other services through implicit parameter transmission when the service calls the other services; and the query statement interception layer intercepts a database query request, adds a permission condition clause in an original query statement according to user permission data in a thread local variable, and queries a database according to a target query statement. When the permission query function is updated, the code change amount is reduced, the influence surface is reduced, and the code test difficulty and the system maintenance difficulty after change are reduced.

Description

Technical Field

[0001] This application relates to the technical field of data query, and particularly to a method for processing data query requests, a business system, a computer device, and a storage medium. Background Art

[0002] The principle of least privilege is an important principle in data security. This principle means that each program and system user should have the minimum set of permissions necessary to complete a task. It requires that each module at a specific abstraction layer in the computing environment can only access the information or resources necessary at present. Therefore, the access permissions of users to data rows are usually restricted according to the type of user. For example, operation personnel in Beijing can only access data rows with the area being Beijing, and cannot access data rows with the area being Nanjing. This can prevent the occurrence of data over-authorization.

[0003] In the implementation of the above functions at the backend, generally, the permission data of the currently logged-in user is obtained through the gateway, and then the permission data is spliced into the Structured Query Language (SQL) when requesting the database. Finally, the data retrieved from the database is returned to the front end for display. However, this implementation method has drawbacks. A large amount of permission code implementation is seriously coupled in the business logic. If a new permission query dimension needs to be added due to system upgrade reasons, then all the Structured Query Languages related to permission queries need to be changed. Such an operation has a large amount of changes and a wide impact area, which will increase the testing difficulty of the changed code and also increase the system maintenance difficulty. Summary of the Invention

[0004] This application provides a method for processing data query requests, a business system, a computer device, and a storage medium in view of the above deficiencies or drawbacks. The embodiments of this application can reduce the amount of code changes when updating the permission query function, narrow the impact area of code changes, reduce the testing difficulty of the changed code, and can also reduce the system maintenance difficulty.

[0005] According to a first aspect of this application, a method for processing data query requests is provided. In some embodiments, the method includes:

[0006] Receiving a user's data query request through the gateway layer, verifying the user's login status, injecting the user's permission data into the request parameters of the data query request after successful verification, and calling the target dubbo service according to the user request address. The target dubbo service obtains the query result of the data query request through the business logic of directly querying the database or through the business logic of indirectly querying the database using the dubbo service call chain;

[0007] Executing the business logic of any called dubbo service through the business logic layer;

[0008] Intercept the service call logic of the gateway layer for the target Dubbo service through the interface cut-off layer, and store the user permission data in the request parameters into the thread-local variable of the target Dubbo service;

[0009] When any Dubbo service calls any other Dubbo service through the Dubbo cut-off layer, if there is user permission data in the thread-local variable of the any Dubbo service, pass the user permission data to the any other Dubbo service in an implicit parameter passing manner;

[0010] Intercept the database query requests sent by any Dubbo service through the query statement interception layer. If there is user permission data in the thread-local variable of the Dubbo service that sends the database query request, add a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread-local variable of the Dubbo service that sends the database query request, generate a target query statement, query the database according to the target query statement, and return the query result to the any Dubbo service.

[0011] In some embodiments, the operation of adding a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread-local variable of the Dubbo service that sends the database query request to generate a target query statement includes:

[0012] Obtain the permission enumeration information corresponding to the Dubbo service that sends the database query request; the permission enumeration information includes permission identifier field information;

[0013] Obtain the target permission data from the user permission data in the thread-local variable of the Dubbo service that sends the database query request according to the permission identifier field information;

[0014] Generate a permission condition clause according to the target permission data and splice it into the original query statement carried in the database query request to generate a target query statement.

[0015] In some embodiments, the permission enumeration information further includes permission identifier mapping information;

[0016] The operation of generating a permission condition clause according to the target permission data includes:

[0017] Generate a permission condition clause according to the target permission data and the permission identifier mapping information.

[0018] In some embodiments, the permission enumeration information further includes custom field information; the custom field information includes first indication information for determining the permission data acquisition logic;

[0019] The operation of obtaining target permission data from the user permission data in the thread local variable of the Dubbo service that issues a database query request according to the permission identifier field information includes:

[0020] When the custom field information is empty, obtain the target permission data from the user permission data in the thread local variable of the Dubbo service that issues a database query request according to the permission identifier field information;

[0021] When the custom field information is not empty, determine the permission data acquisition logic according to the first indication information, and execute the permission data acquisition logic to obtain the target permission data.

[0022] In some embodiments, the custom field information further includes a second indication information for indicating the permission identifier mapping information;

[0023] The operation of generating a permission condition clause according to the target permission data includes:

[0024] Generate a permission condition clause according to the target permission data and the second indication information.

[0025] In some embodiments, the method further includes:

[0026] After the business logic of the target Dubbo service is executed, clear the thread local variable of the target Dubbo service through the interface layer;

[0027] After obtaining the query result, clear the thread local variable of the Dubbo service that issues the database query request through the query statement interception layer.

[0028] In some embodiments, when any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, the operation of transparently transmitting the user permission data to the any other Dubbo service in an implicit parameter passing manner includes:

[0029] Before any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, set the user permission data to the implicit parameter, and after the any other Dubbo service is called, store the user permission data in the implicit parameter into the thread local variable of the any other Dubbo service.

[0030] In some embodiments, before any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, the user permission data is set into the implicit parameter, and the operation of storing the user permission data in the implicit parameter into the thread local variable of the any other Dubbo service after the any other Dubbo service is called includes:

[0031] Proxying the Dubbo service provider and Dubbo service consumer through an aspect;

[0032] Intercepting the service call logic of any Dubbo service for any other Dubbo service, and if there is user permission data in the thread local variable of the any Dubbo service before the any other Dubbo service is called, setting the user permission data into the implicit parameter;

[0033] After the any other Dubbo service is called, intercepting the business logic of the any other Dubbo service, and before executing the business logic of the any other Dubbo service, storing the user permission data in the implicit parameter into the thread local variable of the any other Dubbo service.

[0034] According to a second aspect, the present application provides a business system. In some embodiments, the system includes a gateway layer, an interface aspect layer, a Dubbo aspect layer, a query statement interception layer, and a business logic layer;

[0035] The gateway layer is used to receive a data query request from a user, verify the user login status, inject user permission data into the request parameters of the data query request after verification, and call a target Dubbo service according to the user request address. The target Dubbo service obtains the query result of the data query request through the business logic of directly querying the database or through the business logic of indirectly querying the database using a Dubbo service call chain;

[0036] The business logic layer is used to execute the business logic of any Dubbo service that is called;

[0037] The interface aspect layer is used to intercept the service call logic of the gateway layer for the target Dubbo service and store the user permission data in the request parameters into the thread local variable of the target Dubbo service;

[0038] The Dubbo aspect layer is used to, when any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, transparently transmit the user permission data to the any other Dubbo service through implicit parameter passing;

[0039] A query statement interception layer is used to intercept database query requests sent by any Dubbo service. If user permission data exists in the thread local variable of the Dubbo service that sends the database query request, a permission condition clause is added to the original query statement carried in the database query request according to the user permission data in the thread local variable of the Dubbo service that sends the database query request to generate a target query statement. The database is queried according to the target query statement, and the query result is returned to the any Dubbo service.

[0040] According to a third aspect of the present application, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the data query request processing method provided in any of the above embodiments is implemented.

[0041] According to a fourth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the data query request processing method provided in any of the above embodiments is implemented.

[0042] In the above embodiments of the present application, an interface cut-off layer, a Dubbo cut-off layer, and a query statement interception layer are introduced into the business system. After the gateway layer receives a data query request, in addition to verifying the user login status, user permission data is pre-obtained and injected into the request parameters of the data query request. Subsequently, the interface cut-off layer can be used to store the user permission data in the request parameters into the thread local variable of the target Dubbo service, so that when the business logic of the target Dubbo service is subsequently executed, corresponding operations can be performed according to the user permission data in the thread local variable. Through the query statement interception layer, a permission condition clause can be added to the original query statement carried in the database query request sent by each Dubbo service, so that the business logic of the Dubbo service does not need to concern the permission processing logic. Through the Dubbo cut-off layer, the user permission data can be conveniently passed through to the downstream service during the Dubbo service call process. Through the above improvements, the present application can decouple the business logic from the permission processing logic, unify the permission operations at the query statement interception layer, and only a small amount of code needs to be modified when the permission query function is updated. Moreover, business logic developers do not need to concern the implementation of the permission processing logic, reducing the development and maintenance amount of the code; it can also decouple the micro-service call from the permission processing logic, and can conveniently implement the transmission of user permission data between micro-services, and can better support large projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 It is a schematic flowchart of a data query request processing method provided by the present application according to one or more embodiments;

[0044] Figure 2A flowchart showing the process of generating a target query statement provided by the present application according to one or more embodiments;

[0045] Figure 3 An architecture block diagram of a business system provided by the present application according to one or more embodiments;

[0046] Figure 4 An internal structure diagram of a computer device provided by the present application according to one or more embodiments. Detailed implementation manners

[0047] To make the objectives, technical solutions, and advantages of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings. It should be clear that the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0048] When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present application. On the contrary, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0049] In the description of the present application, it should be understood that the terms "first", "second", "third", etc. are only used to distinguish similar objects and do not have to be used to describe a specific order or sequence, nor can they be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to specific circumstances. In addition, in the description of the present application, unless otherwise specified, "a plurality of" means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0050] In view of the deficiencies or defects of the prior art, the present application provides a method for processing a data query request with decoupled business logic and permission processing logic. This method can reduce the amount of code changes when the permission query function is updated, narrow the impact surface of the code changes, reduce the testing difficulty of the changed code, and also reduce the system maintenance difficulty.

[0051] The following will illustrate this method in detail through embodiments.

[0052] In some embodiments, the method can be applied to a business system. The business system is a system built based on the MyBatis persistence layer framework and the Dubbo microservice architecture. The MyBatis persistence layer framework can be responsible for abstracting database operations into object operations, simplifying the complexity of database interaction. The Dubbo microservice architecture is a service framework that is responsible for service registration, discovery, and invocation, ensuring efficient communication between services. The Mybatis + Dubbo architecture enables database query operations to be flexibly integrated into microservices while maintaining high availability and scalability of the services. The system at least includes a gateway layer, an interface slicing layer, a Dubbo slicing layer, a query statement interception layer, and a business logic layer.

[0053] Please refer to Figure 1 , Figure 1 The steps of the data query request processing method provided in some embodiments are shown as follows, that is:

[0054] S110: Receive the user's data query request through the gateway layer, verify the user's login status, inject the user permission data into the request parameters of the data query request after the verification passes, and call the target Dubbo service according to the user request address. The target Dubbo service obtains the query result of the data query request by directly querying the business logic of the database or by indirectly querying the business logic of the database using the Dubbo service call chain;

[0055] S120: Execute the business logic of any called Dubbo service through the business logic layer;

[0056] S130: Intercept the service call logic of the gateway layer for the target Dubbo service through the interface slicing layer, and store the user permission data in the request parameters into the thread local variable of the target Dubbo service;

[0057] S140: When any Dubbo service calls any other Dubbo service through the Dubbo slicing layer, if there is user permission data in the thread local variable of the any Dubbo service, pass the user permission data to the any other Dubbo service in an implicit parameter passing manner;

[0058] S150: Intercept the database query request sent by any Dubbo service through the query statement interception layer. If there is user permission data in the thread local variable of the Dubbo service that sends the database query request, add a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread local variable of the Dubbo service that sends the database query request to generate a target query statement, query the database according to the target query statement, and return the query result to the any Dubbo service.

[0059] As shown above, the business system at least includes a gateway layer, an interface slicing layer, a Dubbo slicing layer, a query statement interception layer, and a business logic layer. Each layer can be implemented by one or more modules. For example, the gateway layer can be a gateway module, and the business logic layer can include multiple Dubbo services. The gateway layer can call a Dubbo service through the interface exposed by the Dubbo service to execute its (referring to the Dubbo service) business logic. The Dubbo service can call another Dubbo service through the interface exposed by the other Dubbo service to execute its (referring to the other Dubbo service) business logic.

[0060] The gateway layer is used to receive the user's data query request, verify the user's login status, inject the user permission data into the request parameters of the data query request after successful verification, and call the target Dubbo service according to the user request address. The target Dubbo service obtains the query result of the data query request through the business logic of directly querying the database or indirectly querying the database through the Dubbo service call chain.

[0061] The business logic layer is used to execute the business logic of any called Dubbo service.

[0062] The interface slicing layer is used to intercept the service call logic of the gateway layer for the target Dubbo service and store the user permission data in the request parameters into the thread local variable of the target Dubbo service.

[0063] The Dubbo slicing layer is used to, when any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, transparently pass the user permission data to the any other Dubbo service through implicit parameter passing.

[0064] The query statement interception layer is used to intercept the database query request issued by any Dubbo service. If there is user permission data in the thread local variable of the Dubbo service that issues the database query request, add a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread local variable of the Dubbo service that issues the database query request to generate a target query statement, query the database according to the target query statement, and return the query result to the any Dubbo service.

[0065] Among them, the interface slicing layer is also used to clear the thread local variable of the target Dubbo service after the business logic of the target Dubbo service is executed; the query statement interception layer is also used to clear the thread local variable of the Dubbo service that issues the database query request after obtaining the query result to prevent memory leakage.

[0066] The embodiments of the present application provide a solution for unifying the permission processing code during data query, so that the business logic and the permission processing logic can be isolated, without the need to care about permission data during each data query operation, and the permission query work is unified and centralized, without the need to hard-code the permission query work during each data query operation.

[0067] In a project based on the mybatis persistence layer framework and the dubbo microservice architecture, data query is generally carried out by directly querying the database or indirectly querying the database by calling other microservices. The permission processing logic centralization work for these two data query methods will be introduced separately below.

[0068] For the method of directly querying the database, the general operation process usually has three steps, namely:

[0069] a. Receive the user's data query request at the gateway layer, verify the user's login status, and after successful verification, forward the data query request to the actual business server for processing according to the request address;

[0070] b. After the business server receives the database query request, execute the business logic of querying the database. The business logic of directly querying the database usually is to obtain the permission data corresponding to the user (used to indicate the user's data row access permission), and then when constructing the query statement (Structured Query Language, SQL), splice the permission condition clause generated based on the permission data into the query statement, and then send a database query request to the database.

[0071] c. The database returns the query result that matches the query statement carried by the database query request, and the business server assembles the query data based on the query result and responds to the user through the gateway layer.

[0072] When developers develop the code for the above-mentioned business logic of querying the database, they need to consider operations such as obtaining user permission data and splicing user permission data. At this time, the permission processing logic and the business logic of data query are coupled together. If there are changes in the subsequent permission query work, the entire business logic needs to be adjusted. To address this issue, the embodiments of the present application unify the implementation of both the query operation of permission data and the operation of splicing the query statement based on permission data at the query statement interception layer. In this way, all business queries do not need to concern about permissions, and any changes in permissions only need to be uniformly modified at the query statement interception layer without modifying the code of other business logics.

[0073] After the above work, the operation process of directly querying the database can be divided into the following 5 steps:

[0074] a. Receive the user's data query request at the gateway layer, verify the user's login status, and after successful verification, inject the user login data containing the user permission data and user basic data into the request parameters of the data query request. Then, forward the data query request to the business server where the target Dubbo service is deployed for processing according to the request address. The target Dubbo service refers to the Dubbo service determined based on the request address for processing the data query request.

[0075] b. The interface slicing layer intercepts the service call logic of the gateway layer to the target Dubbo service, and then writes the user permission data in the request parameters of the data query request into the thread local variable of the target Dubbo service.

[0076] c. Normally execute the business logic of the target Dubbo service. This business logic constructs a query statement (which can be called the original query statement) based on specific request parameters (excluding user permission data) in the data query request, and sends a database query request including this query statement to the database.

[0077] d. The query statement interception layer intercepts the database query request, and then adds a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread local variable (ThreadLocal) of the target Dubbo service, so as to obtain a new query statement (which can be called the target query statement). Then, send the database query request carrying the target query statement to the database.

[0078] e. The database returns the query result that matches the target query statement carried in the database query request. The query statement interception layer returns the query result to the target Dubbo service, and the target Dubbo service assembles the query data based on the query result and responds to the user through the gateway layer.

[0079] For the method of indirectly querying the database using the Dubbo service call chain, most current software systems are composed of multiple services. A data query request may trigger a series of business processes, and these processes require the collaboration of multiple microservices. For example, an order query may first need to obtain order details from the order service, then obtain inventory status from the inventory service, and obtain logistics information from the logistics service, etc. In view of this situation, the embodiment of the present application introduces a Dubbo slicing layer into the system, so that the user permission data can be simply and conveniently passed to downstream services during the microservice call process. The downstream services can then use the direct database query operation process provided in the above embodiment to complete the data query operation, thereby decoupling the permission processing during service calls and the business logic of data query.

[0080] After receiving the user's data query request, the above steps a and b are still performed. However, the business logic of the target Dubbo service does not directly query the database, but indirectly queries the database through a series of microservice calls. Therefore, the subsequent related operations can be divided into two steps:

[0081] 1. When the target Dubbo service calls other Dubbo services, before the call through the Dubbo slicing layer, the user permission data stored in the thread local variable of the target Dubbo service is set into the Dubbo implicit parameter;

[0082] 2. After other Dubbo services are called, they will execute the corresponding business logic. Before other Dubbo services execute their business logic through the Dubbo slicing layer, the user permission data is obtained from the implicit parameter and stored in the ThreadLocal of other Dubbo services. Then, other Dubbo services normally execute their business logic; the business logic of other Dubbo services may directly query the database or call other Dubbo services. At this time, the user permission data is obtained from the thread local variable and corresponding operations are performed. For example, if directly querying the database, the above steps c to d will be executed; if calling other Dubbo services, the above steps 1 to 2 will be executed.

[0083] In some embodiments, when any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, the operation of transparently transmitting the user permission data to the any other Dubbo service through implicit parameter passing includes: before any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of the any Dubbo service, the user permission data is set into the implicit parameter, and after the any other Dubbo service is called, the user permission data in the implicit parameter is stored in the thread local variable of the any other Dubbo service.

[0084] Among them, before any Dubbo service calls any other Dubbo service, if there is user permission data in the thread local variable of this any Dubbo service, the user permission data is set into the implicit parameter, and after this any other Dubbo service is called, storing the user permission data in the implicit parameter into the thread local variable of this any other Dubbo service can be achieved by aspect proxying the Dubbo service provider and the Dubbo service consumer; intercepting the service call logic of any Dubbo service for any other Dubbo service, before any other Dubbo service is called, if there is user permission data in the thread local variable of this any Dubbo service, the user permission data is set into the implicit parameter; after this any other Dubbo service is called, intercepting the business logic of this any other Dubbo service, and before executing the business logic of this any other Dubbo service, storing the user permission data in the implicit parameter into the thread local variable of this any other Dubbo service.

[0085] This embodiment can conveniently implement the transfer operation of user permission data during the microservice call by using the implicit parameter passing feature of Dubbo.

[0086] In some embodiments, the operation of adding a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread local variable of the Dubbo service that issues the database query request to generate a target query statement, as Figure 2 shown, includes:

[0087] S210: Obtain the permission enumeration information corresponding to the Dubbo service that issues the database query request; the permission enumeration information includes permission identifier field information.

[0088] S220: Obtain the target permission data from the user permission data in the thread local variable of the Dubbo service that issues the database query request according to the permission identifier field information.

[0089] In some embodiments, the permission enumeration information may only include the permission identifier field information, that is, the field information of the permission identifier field, which is used to determine the permission data supported by the interface. If the permission enumeration information only includes the permission identifier field information, then directly obtain the matching permission data from the user permission data in the relevant thread local variable as the target permission data.

[0090] S230: Generate a permission condition clause according to the target permission data and splice it into the original query statement carried in the database query request to generate a target query statement.

[0091] The permission condition clause is the clause in the query statement that indicates the permission condition, such as the where clause used to limit the permission condition.

[0092] In some embodiments, if the permission enumeration information only includes the permission identifier field information, then the permission data found from the user permission data that matches the permission identifier field information is directly used to construct the permission condition in the permission condition clause.

[0093] In some embodiments, the permission enumeration information further includes permission identifier mapping information; at this time, the operation of generating a permission condition clause based on the target permission data includes: generating a permission condition clause based on the target permission data and the permission identifier mapping information.

[0094] If the permission enumeration information further includes permission identifier mapping information, that is, the field information of the permission identifier mapping field, which is used to determine the mapping relationship between the permission field and the database field, at this time, when constructing the permission condition clause, it is necessary to use the permission identifier mapping information to generate the permission condition clause.

[0095] In other embodiments, the permission enumeration information further includes custom field information; the custom field information includes first indication information for determining the permission data acquisition logic. At this time, the operation of obtaining the target permission data from the user permission data in the thread local variable of the dubbo service that issues the database query request according to the permission identifier field information includes:

[0096] When the custom field information is empty, obtain the target permission data from the user permission data in the thread local variable of the dubbo service that issues the database query request according to the permission identifier field information;

[0097] When the custom field information is not empty, determine the permission data acquisition logic according to the first indication information, and execute the permission data acquisition logic to obtain the target permission data.

[0098] Furthermore, the custom field information may further include second indication information for indicating the permission identifier mapping information; at this time, the operation of generating a permission condition clause based on the target permission data includes: generating a permission condition clause based on the target permission data and the second indication information.

[0099] This embodiment supports developers to add some special logics according to actual business requirements, and allows developers to execute custom methods to obtain the target permission data.

[0100] The above embodiments are illustrated by examples below.

[0101] In this example, the business logic and the permission processing logic can be decoupled by injecting a plugin. The plugin at least includes the following modules:

[0102] (1) Automatic injection module

[0103] In the plug-in, the AutoConfiguration of springboot can be defined, so that it is possible to support the access of the project just by introducing the maven dependency, improving the convenience of project access.

[0104] (2) Interface permission enumeration definition

[0105] The enumeration only supports being marked on methods (such as the interfaces of dubbo services). In this embodiment, three fields are defined: permissionKey (permission identification field), permissionMapper (permission identification mapping field), and custom (custom field).

[0106] permissionKey: The default value of this field is ["city", "area"], which represents the types of permissions supported by the current interface. The query statement interception layer will query the permission fields in the user permission data in the relevant thread local variable according to the field information of this field and complete the SQL splicing.

[0107] permissionMapper: This field is default empty, representing the mapping between the fields in permissionKey and the fields in the database. Setting this field is considered because the field names in the database and the user permission data may not be unified. For example, ["cityeCodes:city_code"], which means that cityeCodes will be used to obtain the target permission data that matches it in the user permission data, and when adding a permission condition clause to the original query statement, city_code will be used to construct the permission condition clause.

[0108] custom: This field is default empty. This plug-in supports developers to add some special logics according to actual business requirements, and allows developers to execute custom methods to obtain the target permission data.

[0109] For example, assume that the field information of custom is as follows:

[0110] ["com.test.PermissionUtil$getCityCode:city_code"]

[0111] Among them, "com.test.PermissionUtil$getCityCode" is the first indication information for determining the permission data acquisition logic, and "city_code" is the second indication information for indicating the permission identifier mapping information. When the field information of custom is not empty, when obtaining the target permission data, the target permission data will not be obtained from the user permission data stored in the relevant thread local variable, but will be obtained through the first indication information. The first indication information in the above example includes two parts, "com.test.PermissionUtil" and "getCityCode". The first indication information indicates that the getCityCode method in the com.test.PermissionUtil class will be executed to obtain the target permission data. Then, when adding a permission condition clause to the original query statement, the permission condition clause will be constructed based on the second indication information. The second indication information in the above example indicates that city_code will be used to construct the permission condition clause.

[0112] (3) Interface aspect module

[0113] The function of the interface aspect module is to proxy the corresponding interface according to the above enumeration. After proxying, the user permission data is written into the relevant thread local variable, and then the business method of the relevant dubbo service is called. Moreover, if there is still user permission data in the thread local variable after the execution of the business method, the user permission data is cleared to prevent the thread pool from reusing the thread.

[0114] (4) Query statement interception module

[0115] The query statement interception module can be an SQL interceptor, which can be obtained by secondary development based on mybatis's Interceptor and will take effect when any dubbo service requests to query mybatis. The interceptor will intercept the database query request (such as mysql select request) according to the user permission data stored in the thread local variable of the dubbo service, and then construct the where statement (i.e., the permission condition clause) corresponding to the permission according to the user permission data in the thread local variable, and clear the data in the thread local variable after the execution of the target query statement.

[0116] (5) dubbo aspect module

[0117] The Dubbo aspect module proxies Dubbo service providers and Dubbo service consumers through aspects. When a Dubbo call is executed, if user permission data exists in the current thread local variable, the user permission data is stored in the implicit parameters of Dubbo. After the Dubbo service is called, the user permission data is read from the implicit parameters and stored in the thread local variable of the current service, facilitating the continued use of this plugin when services are called between each other.

[0118] Based on the same inventive concept, the present application also provides a business system. In some embodiments, as Figure 3 shown, the system includes a gateway layer 110, an interface aspect layer 120, a Dubbo aspect layer 130, a query statement interception layer 140, and a business logic layer 150;

[0119] The gateway layer 110 is used to receive a data query request from a user, verify the user login status, inject user permission data into the request parameters of the data query request after successful verification, and call a target Dubbo service according to the user request address. The target Dubbo service obtains the query result of the data query request by directly querying the business logic of the database or indirectly querying the business logic of the database through the Dubbo service call chain;

[0120] The business logic layer 120 is used to execute the business logic of any Dubbo service that is called;

[0121] The interface aspect layer 130 is used to intercept the service call logic of the gateway layer for the target Dubbo service and store the user permission data in the request parameters into the thread local variable of the target Dubbo service;

[0122] The Dubbo aspect layer 140 is used to, when any Dubbo service calls any other Dubbo service, if user permission data exists in the thread local variable of the any Dubbo service, transparently transmit the user permission data to the any other Dubbo service through implicit parameter passing;

[0123] The query statement interception layer 150 is used to intercept a database query request issued by any Dubbo service. If user permission data exists in the thread local variable of the Dubbo service that issues the database query request, add a permission condition clause to the original query statement carried in the database query request according to the user permission data in the thread local variable of the Dubbo service that issues the database query request to generate a target query statement, query the database according to the target query statement, and return the query result to the any Dubbo service.

[0124] For the specific limitations of the business system, reference can be made to the limitations on the data query request processing method in the above text, which will not be elaborated here.

[0125] The present application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the data query request processing method provided in any of the above embodiments can be implemented.

[0126] Further, in some embodiments, the internal structure diagram of the computer device may be as Figure 4 shown. The computer device includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as permission data corresponding to each user, and the specific stored data can also refer to the limitations in the above method embodiments. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a data query request processing method is implemented.

[0127] Those skilled in the art can understand that Figure 4 the structure shown in

[0128] is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0129] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0130] Those of ordinary skill in the art can understand that to implement all or part of the processes in the above method embodiments, it can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above method embodiments. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink), DRAM (SLDRAM), memory bus (Rambus), direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0131] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0132] The above-described embodiments merely represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A method for processing a data query request, characterized in that: The method comprises: Receive the user's data query request through the gateway layer, verify the user's login status, inject the user's permission data into the request parameters of the data query request after the verification, call the target dubbo service according to the user's request address, and the target dubbo service obtains the query result of the data query request by directly querying the database's business logic or indirectly querying the database's business logic by using the dubbo service call chain; Execute the business logic of any called dubbo service through the business logic layer; Intercept the service call logic of the gateway layer for the target dubbo service through the interface aspect layer, and store the user authority data in the request parameter into the thread local variable of the target dubbo service; When any dubbo service calls any other dubbo service through the dubbo aspect layer, if there is user permission data in the thread local variable of any dubbo service, the user permission data is transparently transmitted to any other dubbo service through implicit parameter transmission; The database query request issued by any dubbo service is intercepted through the query statement interception layer. If there is user permission data in the thread local variable of the dubbo service that issues the database query request, a permission condition clause is added to the original query statement carried by the database query request based on the user permission data in the thread local variable of the dubbo service that issues the database query request, and a target query statement is generated. The database is queried according to the target query statement, and the query result is returned to any dubbo service.

2. The method according to claim 1, characterized in that The operation of adding a permission condition clause to the original query statement carried by the database query request according to the user permission data in the thread local variable of the dubbo service that issues the database query request to generate a target query statement includes: Obtaining permission enumeration information corresponding to the dubbo service that issues the database query request; the permission enumeration information includes permission identification field information; Obtaining target permission data from the user permission data in the thread local variable of the dubbo service that issues the database query request according to the permission identification field information; A permission condition clause is generated according to the target permission data, and is spliced ​​into the original query statement carried by the database query request to generate the target query statement.

3. The method according to claim 1, characterized in that The permission enumeration information also includes permission identification mapping information; The operation of generating a permission condition clause according to the target permission data includes: A permission condition clause is generated according to the target permission data and the permission identification mapping information.

4. The method according to claim 2 or 3, characterized in that The permission enumeration information also includes custom field information; the custom field information includes first indication information for determining permission data acquisition logic; The operation of acquiring target permission data from the user permission data in the thread local variable of the dubbo service that issues the database query request according to the permission identification field information includes: When the custom field information is empty, the target permission data is obtained from the user permission data in the thread local variable of the dubbo service that issues the database query request according to the permission identification field information; When the custom field information is not empty, the permission data acquisition logic is determined according to the first indication information, and the permission data acquisition logic is executed to acquire target permission data.

5. The method according to claim 4, characterized in that The custom field information further includes second indication information for indicating authority identifier mapping information; The operation of generating a permission condition clause according to the target permission data includes: A permission condition clause is generated according to the target permission data and the second indication information.

6. The method according to claim 1, characterized in that The method further comprises: After the business logic of the target dubbo service is executed, clear the thread local variables of the target dubbo service through the interface aspect layer; After obtaining the query result through the query statement interception layer, the thread local variables of the dubbo service that issued the database query request are cleared.

7. The method according to claim 1, characterized in that When any dubbo service calls any other dubbo service, if there is user permission data in the thread local variable of any dubbo service, the operation of transparently transmitting the user permission data to any other dubbo service through implicit parameter transmission includes: Before any dubbo service calls any other dubbo service, if there is user permission data in the thread local variable of any dubbo service, the user permission data is set to the implicit parameter, and after any other dubbo service is called, the user permission data in the implicit parameter is stored in the thread local variable of any other dubbo service.

8. The method according to claim 7, characterized in that Before any dubbo service calls any other dubbo service, if there is user permission data in the thread local variable of any dubbo service, the user permission data is set to the implicit parameter, and after any other dubbo service is called, the user permission data in the implicit parameter is stored in the thread local variable of any other dubbo service, including: Proxy dubbo service providers and dubbo service consumers through aspects; Intercept the service call logic of any dubbo service for any other dubbo service. Before any other dubbo service is called, if there is user permission data in the thread local variable of any dubbo service, set the user permission data to the implicit parameter; After any other dubbo service is called, the business logic of any other dubbo service is intercepted, and before the business logic of any other dubbo service is executed, the user authority data in the implicit parameter is stored in the thread local variable of any other dubbo service.

9. A business system, characterized in that: The system includes a gateway layer, an interface aspect layer, a Dubbo aspect layer, a query statement interception layer and a business logic layer; The gateway layer is used to receive the user's data query request, verify the user's login status, inject the user's permission data into the request parameters of the data query request after the verification, and call the target dubbo service according to the user's request address. The target dubbo service obtains the query result of the data query request by directly querying the database's business logic or indirectly querying the database's business logic by using the dubbo service call chain; The business logic layer is used to execute the business logic of any called dubbo service; The interface aspect layer is used to intercept the service call logic of the gateway layer for the target dubbo service, and store the user authority data in the request parameters into the thread local variables of the target dubbo service; The dubbo aspect layer is used to transparently transmit the user permission data to any other dubbo service through implicit parameter transmission when any dubbo service calls any other dubbo service if there is user permission data in the thread local variable of any dubbo service; The query statement interception layer is used to intercept database query requests issued by any dubbo service. If there is user permission data in the thread local variable of the dubbo service that issues the database query request, a permission condition clause is added to the original query statement carried by the database query request based on the user permission data in the thread local variable of the dubbo service that issues the database query request, a target query statement is generated, the database is queried according to the target query statement, and the query results are returned to any dubbo service.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 8 is implemented.

Images