A data permission control method and device based on microservices

Abstract

The present invention discloses a data permission control method and device based on microservices, the method comprising: intercepting the user's access request, querying the permission result matching the access request in the preset permission database, judging whether the user meets the preset access condition according to the found permission result; if satisfied, accessing the corresponding data; if not satisfied, sending an unauthorized access prompt. It can be seen that the implementation of the present invention can obtain the permission result by querying the permission database once in the permission authentication stage, reducing the loss of performance caused by permission authentication, and at the same time, it can enable the data permission service to support more complex, finer-grained, and multi-dimensional permission control, and adapt to the current complex business system based on the microservice architecture. The demand for data permissions.

Description

Technical Field

[0001] The present invention relates to the technical field of permission control, and in particular to a data permission control method and device based on microservices. Background Art

[0002] At present, the permission control of business data is mainly implemented through annotations, hard coding or configuration files, but the existing permission control scheme cannot adapt to the increasingly complex business systems. First, most of the latest business systems will adopt microservice solutions, and under the microservice architecture, cross-service data permission control becomes inevitable, and the annotation hard coding method is only loaded once when the business service is started, and the rules cannot be modified during runtime, resulting in the inability to perfectly support the data permission requirements under the microservice architecture; secondly, the user roles faced by the business system are becoming more and more complex, and the number of functional pages integrated in the business system is increasing, so the required data permission model is also becoming more and more complex, and the annotation hard coding method is also helpless in the face of such complex permission requirement scenarios; in addition, the business system needs to ensure high availability, and when the hard coding method modifies the permission rules, it is necessary to modify the code and re-publish it, which greatly increases the unavailable time of the system.

[0003] Therefore, how to build a new microservice-based data permission control method to adapt to the current complex business system based on microservice architecture for data permissions is a problem to be solved in this field. Summary of the invention

[0004] The present invention provides a microservice-based data permission control method and device, which can adapt to the current complex business system based on microservice architecture's demand for data permissions.

[0005] The first aspect of the present invention discloses a data permission control method based on microservices, the method comprising:

[0006] Intercepting an access request sent by a user, wherein the access request includes a page identifier of a target page that the user needs to access;

[0007] Querying a preset permission database for a permission result that matches the access request;

[0008] When there is a permission result matching the access request in the preset permission database, judging whether the user meets the preset access condition according to the permission result;

[0009] If it is determined that the user meets the preset access condition, accessing the corresponding data according to the access request;

[0010] If it is determined that the user does not meet the preset access conditions, a prompt indicating that the user has no permission to access is sent to the user.

[0011] As an optional implementation manner, in the first aspect of the present invention, intercepting the access request sent by the user includes:

[0012] Receive access requests sent by users;

[0013] Determine, based on the page identifier included in the access request, an interface identifier of a service that needs to be called by the access request;

[0014] Based on the interface identifier, determine the SQL identifier corresponding to the interface identifier;

[0015] The SQL statement corresponding to the SQL identifier is intercepted by a pre-configured data authority authentication tool.

[0016] As an optional implementation manner, in the first aspect of the present invention, the querying of the preset permission database for the permission result matching the access request includes:

[0017] Based on the page identifier, the interface identifier, and the SQL identifier, query the preset authority database for an authority result that matches the page identifier, the interface identifier, and the SQL identifier.

[0018] As an optional implementation manner, in the first aspect of the present invention, judging whether the user meets the preset access condition according to the permission result includes:

[0019] Determining whether the permission result indicates that a corresponding target permission is pre-configured for the target page or a target interface corresponding to the target page, where the target interface corresponding to the target page is an interface that needs to be called to access the target page;

[0020] If the permission result indicates that the target permission is pre-configured for the target page or the target interface corresponding to the target page, it is determined whether the user meets the preset access condition according to the permission type of the target permission.

[0021] As an optional implementation manner, in the first aspect of the present invention, judging whether the user meets the preset access condition according to the permission type of the target permission includes:

[0022] If the permission type of the target permission is a default permission type, determining that the user meets the preset access condition;

[0023] If the permission type of the target permission is a role permission type, obtain all roles included in the permission result to obtain a first role set, and obtain all roles owned by the user to obtain a second role set, and determine whether the first role set and the second role set have an intersection;

[0024] If there is no intersection between the first role set and the second role set, determining that the user does not meet the preset access condition;

[0025] If the first role set and the second role set have an intersection, it is determined that the user meets the preset access condition.

[0026] As an optional implementation manner, in the first aspect of the present invention, accessing corresponding data according to the access request includes:

[0027] When the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, obtaining permission information corresponding to each role in the second role set;

[0028] Merging the permission information corresponding to all roles in the second role set to obtain a permission union of the second role set;

[0029] Modify the access request according to the permission union of the second role set to obtain a modified access request;

[0030] Access corresponding data according to the modified access request.

[0031] As an optional embodiment, in the first aspect of the present invention, the method further comprises:

[0032] When there is no permission result matching the access request in the preset permission database, a corresponding access operation is performed according to the access request.

[0033] A second aspect of the present invention discloses a data authority control device based on microservices, the device comprising:

[0034] An interception module, used to intercept an access request sent by a user, wherein the access request includes a page identifier of a target page that the user needs to access;

[0035] A query module, used to query a preset permission database for permission results matching the access request;

[0036] A judgment module, configured to judge whether the user meets the preset access condition according to the permission result when there is a permission result matching the access request in the preset permission database;

[0037] An access module, configured to access corresponding data according to the access request if it is determined that the user meets the preset access condition;

[0038] The prompt module is used to send an unauthorized access prompt to the user if it is determined that the user does not meet the preset access conditions.

[0039] As an optional implementation, in the second aspect of the present invention, the way in which the interception module intercepts the access request sent by the user includes:

[0040] Receive access requests sent by users;

[0041] Determine, based on the page identifier included in the access request, an interface identifier of a service that needs to be called by the access request;

[0042] Based on the interface identifier, determine the SQL identifier corresponding to the interface identifier;

[0043] The SQL statement corresponding to the SQL identifier is intercepted by a pre-configured data authority authentication tool.

[0044] As an optional implementation, in the second aspect of the present invention, the query module queries a preset permission database for a permission result matching the access request, including:

[0045] Based on the page identifier, the interface identifier, and the SQL identifier, query the preset authority database for an authority result that matches the page identifier, the interface identifier, and the SQL identifier.

[0046] As an optional implementation, in the second aspect of the present invention, the judgment module judges whether the user meets the preset access condition according to the permission result in the following manner:

[0047] Determining whether the permission result indicates that a corresponding target permission is pre-configured for the target page or a target interface corresponding to the target page, where the target interface corresponding to the target page is an interface that needs to be called to access the target page;

[0048] If the permission result indicates that the target permission is pre-configured for the target page or the target interface corresponding to the target page, it is determined whether the user meets the preset access condition according to the permission type of the target permission.

[0049] As an optional implementation manner, in the second aspect of the present invention, the determining whether the user meets the preset access condition according to the permission type of the target permission includes:

[0050] If the permission type of the target permission is a default permission type, determining that the user meets the preset access condition;

[0051] If the permission type of the target permission is a role permission type, obtain all roles included in the permission result to obtain a first role set, and obtain all roles owned by the user to obtain a second role set, and determine whether the first role set and the second role set have an intersection;

[0052] If there is no intersection between the first role set and the second role set, determining that the user does not meet the preset access condition;

[0053] If the first role set and the second role set have an intersection, it is determined that the user meets the preset access condition.

[0054] As an optional implementation, in the second aspect of the present invention, the access module accesses corresponding data according to the access request in a manner including:

[0055] When the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, obtaining permission information corresponding to each role in the second role set;

[0056] Merging the permission information corresponding to all roles in the second role set to obtain a permission union of the second role set;

[0057] Modify the access request according to the permission union of the second role set to obtain a modified access request;

[0058] Access corresponding data according to the modified access request.

[0059] As an optional implementation manner, in the second aspect of the present invention, the access module is further used for:

[0060] When there is no permission result matching the access request in the preset permission database, a corresponding access operation is performed according to the access request.

[0061] The third aspect of the present invention discloses another data authority control device based on microservices, the device comprising:

[0062] A memory storing executable program code;

[0063] a processor coupled to the memory;

[0064] The processor calls the executable program code stored in the memory to execute the microservice-based data permission control method disclosed in the first aspect of the present invention.

[0065] The fourth aspect of the present invention discloses a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are called, they are used to execute the microservice-based data permission control method disclosed in the first aspect of the present invention.

[0066] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0067] In the embodiment of the present invention, by intercepting the user's access request, querying the permission result matching the access request in the preset permission database, judging whether the user meets the preset access conditions according to the found permission result; if satisfied, accessing the corresponding data; if not satisfied, sending a prompt of unauthorized access. It can be seen that the implementation of the present invention can obtain the permission result by querying the permission database once during the permission authentication stage, reducing the loss of performance caused by permission authentication, and at the same time, it can enable the data permission service to support more complex, finer-grained, and multi-dimensional permission control, and adapt to the current complex business system based on microservice architecture. The demand for data permissions. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0069] Figure 1 It is a flow chart of a data permission control method based on microservices disclosed in an embodiment of the present invention;

[0070] Figure 2 It is a schematic diagram of a system architecture disclosed in an embodiment of the present invention;

[0071] Figure 3 It is a schematic diagram of a flow chart of configuring data authority on a data authority service disclosed in an embodiment of the present invention;

[0072] Figure 4 is a schematic diagram of a permission data model disclosed in an embodiment of the present invention;

[0073] Figure 5 This is a schematic diagram of setting an authority field of an organization type disclosed in an embodiment of the present invention;

[0074] Figure 6 This is a schematic diagram of setting a non-institutional type authority field disclosed in an embodiment of the present invention;

[0075] Figure 7 It is a flowchart of another microservice-based data permission control method disclosed in an embodiment of the present invention;

[0076] Figure 8 It is a flowchart of judging whether a user meets a preset access condition according to an authority result disclosed in an embodiment of the present invention;

[0077] Fig. 9 It is a structural schematic diagram of a microservice-based data authority control device disclosed in an embodiment of the present invention;

[0078] Fig.10 It is a structural diagram of another microservice-based data authority control device disclosed in an embodiment of the present invention. DETAILED DESCRIPTION

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

[0080] The terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish different objects rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, device, product or end including a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units inherent to these processes, methods, products or ends.

[0081] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0082] The present invention discloses a data authority control method and device based on microservices, which can meet the data authority requirements of the current complex business system based on microservices architecture. The following are detailed descriptions.

[0083] Embodiment 1

[0084] See also Figure 1 , Figure 1 : is a flow chart of a data permission control method based on microservices disclosed in an embodiment of the present invention. Figure 1 The described microservice-based data permission control method can be applied to a mobile terminal or a server, and the embodiments of the present invention are not limited thereto. Figure 1 As shown, the microservice-based data permission control method may include the following operations:

[0085] S101: intercepting an access request sent by a user, where the access request includes a page identifier of a target page that the user needs to access.

[0086] In the embodiment of the present invention, please refer to Figure 2 , Figure 2 This is a schematic diagram of a system architecture disclosed in an embodiment of the present invention. The data permission service is configured at the microservice layer of the system architecture. Users access the data permission service through the data permission configuration page. The data permission service is an independent web service at the same level as other microservice applications. The data permission service stores the permission data in a fixed format in the redis cluster, and the permission element data is stored in the relational database.

[0087] See also Figure 3 , Figure 4 , Figure 3 It is a flow chart of configuring data authority on a data authority service disclosed in an embodiment of the present invention. Figure 4 It is a schematic diagram of a permission data model disclosed in an embodiment of the present invention.

[0088] Configure the required role list on the data permission service and grant roles to users based on business needs. In order to classify and manage multiple users with similar permissions, roles are defined, such as system administrator, administrator, etc. A user can include one or more roles, and a role can include one or more users.

[0089] According to the permission requirements in the business system, set the permission element to page-interface-SQL. Configure SQLID, interface ID, and page CODE, where SQLID is the minimum permission unit. The relationship between the three permission elements is SQL>interface>page, that is, one page can be configured with multiple interfaces, one interface can be configured with multiple SQLs, and one SQL can be associated with multiple interfaces, and one interface can be associated with multiple pages.

[0090] After the permission element configuration is completed, authorize the role, select one or more roles in the role list, and then select one or more pages to create a permission set. Select the page and interface in the permission set to set the permission field and permission field type. The permission field type is divided into two types: institution type field and non-institution type field. For permission field settings, please refer to Figure 5-Figure 6 , Figure 5 This is a schematic diagram of setting the authority field of the organization type disclosed in an embodiment of the present invention. Figure 6It is a schematic diagram of setting non-institutional type permission fields disclosed in an embodiment of the present invention. Among them, the institutional type permission field includes default permissions. Default permissions mean that the user has only configured the institutional permission field, but has not assigned a specific role. At this time, all roles and users will use the same permission type. There are two types of default permission types, this unit, this unit and subordinate units. This unit means that all users accessing the interface can only see the data of this unit. This unit and subordinate units mean that all data under this unit can be seen, including subordinate units and subsidiaries. At this point, the data permission configuration on the data permission service is completed.

[0091] It can be seen that through the improvement of the data permission model, the data permission service can support more complex, fine-grained, and multi-dimensional permission control. At the same time, the improvement of data permission configuration has turned complex data permission configuration into a visualization, which only requires simple training for implementation personnel to get started, and data permissions can be dynamically added or modified at runtime, and the data shared through the cache database cluster will take effect in real time.

[0092] In the embodiment of the present invention, optionally, step S101, intercepting the access request sent by the user, includes:

[0093] A1. Receive access request sent by user;

[0094] A2. Based on the page identifier included in the access request, determine the interface identifier of the service that needs to be called by the access request;

[0095] A3. Based on the interface identifier, determine the SQL identifier corresponding to the interface identifier;

[0096] A4. Intercept the SQL statement corresponding to the SQL identifier through the pre-configured data permission authentication tool.

[0097] In this optional embodiment, a data permission authentication tool SDK is integrated into each service that requires data permission control. The data permission authentication SDK is a jar package that is integrated into other microservice application modules for use. Specifically, the data permission authentication SDK is located in each microservice module, and there is a reference relationship between the service and the data permission authentication SDK. The data permission authentication SDK is referenced by the service in the form of a jar package and is set in the pom.xml file of Maven or the build.gradle file of Gradle.

[0098] In this optional embodiment, when a user accesses a page function, the access request sent by the user carries the page identifier pageCode of the target page that the user needs to access, and the data authority service can obtain the association between the pre-configured pageCode and the interface ID and SQLID. For example, if the target page that the user needs to access needs to call the server interface and execute SQL, the data authority service can determine the interface identifier of the service that the access request needs to call, and based on the interface identifier, determine the SQL identifier corresponding to the interface identifier. The data authority authentication SDK will intercept the SQL execution operation, specifically when the persistence layer executes SQL. The interception method can be configured as MyBatis Intercepts, Spring AOP, or Java Agent dynamic injection.

[0099] S102: Query a preset authority database for an authority result that matches the access request.

[0100] In an embodiment of the present invention, the preset permission database stores the permission data information configured for the user on the data permission service. According to the access request sent by the user, the permission result matching the access request can be queried in the preset permission database. The preset permission database can be a redis cache cluster.

[0101] In the embodiment of the present invention, optionally, step S102, querying the preset authority database for an authority result matching the access request, includes:

[0102] Based on the page identifier, interface identifier, and SQL identifier, query the preset permission database for permission results that match the page identifier, interface identifier, and SQL identifier.

[0103] In this optional embodiment, a redis cache is requested to obtain permission data, and the data includes pageCode, interface ID, SQLID, and permission-related configuration.

[0104] In the embodiment of the present invention, further optional, please refer to Figure 7 , Figure 7 It is a flow chart of another data permission control method based on microservices disclosed in an embodiment of the present invention. The method further includes: when there is no permission result matching the access request in the preset permission database, executing step S104.

[0105] In this optional embodiment, when querying the preset permission database according to the access request, if there is data in the preset permission database, it means that the SQLID is configured with data permissions. If data permissions are configured, the data permission logic will be executed. If data permissions are not configured, it will be released directly.

[0106] S103. When there is a permission result matching the access request in the preset permission database, determine whether the user meets the preset access conditions based on the permission result; if it is determined that the user meets the preset access conditions, execute step S104; if it is determined that the user does not meet the preset access conditions, execute step S105.

[0107] In the embodiment of the present invention, optionally, please refer to Figure 8 , Figure 8 The flowchart of the embodiment of the present invention is a flowchart of judging whether a user meets a preset access condition according to a permission result. Step S103, judging whether a user meets a preset access condition according to the permission result, includes:

[0108] S801. Determine whether the permission result indicates that the target page or the target interface corresponding to the target page has been pre-configured with the corresponding target permission, and the target interface corresponding to the target page is the interface that needs to be called to access the target page. If the permission result indicates that the target permission has been pre-configured for the target page or the target interface corresponding to the target page, then perform the step of determining whether the user meets the preset access condition according to the permission type of the target permission. If the permission result indicates that the target permission has not been pre-configured for the target page or the target interface corresponding to the target page, then determine that the user does not meet the preset access condition.

[0109] In this optional embodiment, the permission result includes pre-configured permission information for the target page or the target interface corresponding to the target page. For example, role permissions are pre-configured for the target page or the target interface corresponding to the target page. Then, it is determined whether the current permission result indicates that the corresponding target permissions are pre-configured for the target page or the target interface corresponding to the target page. If it indicates that the target permissions are configured, it is necessary to execute data permission logic. If it indicates that the target permissions are not configured, the current user does not have access rights.

[0110] In the embodiment of the present invention, further optionally, if the permission result indicates that a target permission is pre-configured for the target page or the target interface corresponding to the target page, then judging whether the user meets the preset access condition according to the permission type of the target permission includes:

[0111] S802: If the permission result indicates that the target permission is pre-configured for the target page or the target interface corresponding to the target page, determine the permission type of the target permission.

[0112] In this optional embodiment, the permission type of the target permission is the permission type of the permission possessed by the user sending the access request, such as a role permission type, a default permission type, or other permission types pre-assigned to the user.

[0113] S803: If it is determined that the permission type of the target permission is a default permission type, it is determined that the user meets the preset access condition.

[0114] In this optional embodiment, if the permission type of the target permission configured in the current permission result is the default permission type, that is, the role and the user will use the same permission type, that is, the user sending the access request has the permission to access, that is, the user meets the preset access conditions.

[0115] S804: If it is determined that the permission type of the target permission is a role permission type, then step S805 is executed.

[0116] S805. Obtain all roles included in the permission result to obtain a first role set, and obtain all roles owned by the user to obtain a second role set, and execute step S806.

[0117] S806: Determine whether there is an intersection between the first role set and the second role set.

[0118] If there is no intersection between the first role set and the second role set, it is determined that the user does not meet the preset access condition.

[0119] If there is an intersection between the first role set and the second role set, it is determined that the user meets the preset access condition.

[0120] In this optional embodiment, if the permission type of the target permission configured in the current permission result is a role permission type, that is, the user needs to have the same role permission as the target data to be accessed in order to access the data. It is determined whether the first role set of all roles included in the permission result and the second role set of all roles owned by the user have an intersection. If there is an intersection, the user who sent the access request has the permission to access, that is, the user meets the preset access conditions; if there is no intersection, the user who sent the access request does not have the permission to access, that is, the user does not meet the preset access conditions.

[0121] It can be seen that this optional embodiment can analyze the obtained permission result to specifically determine whether the permission result indicates that the corresponding target permission is pre-configured for the target page or the target interface corresponding to the target page, and determine whether the user meets the preset access conditions. That is, only one query of the cache cluster is required during the permission authentication process, which reduces the performance loss of permission authentication.

[0122] S104. Access corresponding data according to the access request.

[0123] In the embodiment of the present invention, when it is determined that the user meets the preset access condition, that is, the user has access rights to the target page, the corresponding data can be accessed according to the access request.

[0124] In the embodiment of the present invention, optionally, step S104, accessing corresponding data according to the access request, includes:

[0125] B1. When the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, obtain permission information corresponding to each role in the second role set.

[0126] In this optional embodiment, when the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, that is, a role owned by the user has access rights, then the SQL executed by the access request needs to be rewritten according to the access rights owned by the user to achieve data access. First, determine all the roles owned by the user and the permission information corresponding to each role owned by the user. For example, the user has three roles, R1, R2, and R3. In a certain interface, R1 has the permission of unit A, R2 has the permission of units A, B, and C, and R3 has the permission of units B, C, and D.

[0127] B2. Merge the permission information corresponding to all roles in the second role set to obtain the permission union of the second role set.

[0128] In this optional embodiment, the union authority information of the authority information corresponding to all roles owned by the user is obtained. For example, by merging the A unit authority of user role R1, the A, B, C unit authority of role R2, and the B, C, D unit authority of role R3, it can be determined that the user has the A, B, C, D unit authority.

[0129] B3. Modify the access request according to the permission union of the second role set to obtain a modified access request.

[0130] In this optional embodiment, the permission condition is generated according to the permission field configured by the user on the permission service page. When the user configures the permission field in the permission service, the user needs to specify the three elements of the permission table, permission field, and permission field value. When generating the permission condition in the permission authentication stage, the three elements of the permission table, permission field, and permission field value corresponding to the permission set owned by the user are combined into an SQL statement and then spliced ​​on the business SQL in the form of "IN (permission condition SQL)" to obtain the modified access request.

[0131] B4. Access the corresponding data according to the modified access request.

[0132] It can be seen that by dynamically modifying SQL according to permission data, permission control can be achieved.

[0133] S105: Send a prompt indicating that the user does not have permission to access the site.

[0134] In the embodiment of the present invention, when the user does not have the access authority to access the corresponding data of the access request, a prompt of no-authority access is sent to the user. At the same time, the relevant information of the user without the access authority can also be sent to the security management terminal for risk prompting.

[0135] It can be seen that the implementation Figure 1 The described microservice-based data permission control method intercepts the user's access request, queries the permission result that matches the access request in the preset permission database, and determines whether the user meets the preset access conditions based on the found permission result; if satisfied, the corresponding data is accessed; if not satisfied, a prompt of unauthorized access is sent. It can be seen that the implementation of the present invention can obtain the permission result by querying the permission database once during the permission authentication stage, reducing the performance loss of permission authentication, and at the same time, it can enable the data permission service to support more complex, finer-grained, and multi-dimensional permission control, and adapt to the current complex business system based on the microservice architecture. The demand for data permissions.

[0136] Embodiment 2

[0137] See also Fig. 9 , Fig. 9 Schematic diagram of a data permission control device based on microservices disclosed in an embodiment of the present invention. Fig. 9 The described microservice-based data authority control device can be integrated into a mobile terminal or a server, which is not limited in the embodiments of the present invention. Fig. 9 As shown, the microservice-based data authority control device may include: an interception module 901, a query module 902, a judgment module 903, an access module 904, and a prompt module 905, wherein:

[0138] The interception module 901 is used to intercept the access request sent by the user, where the access request includes the page identifier of the target page that the user needs to access.

[0139] In the embodiment of the present invention, please refer to Figure 2 , Figure 2 This is a schematic diagram of a system architecture disclosed in an embodiment of the present invention. The data permission service is configured at the microservice layer of the system architecture. Users access the data permission service through the data permission configuration page. The data permission service is an independent web service at the same level as other microservice applications. The data permission service stores the permission data in a fixed format in the redis cluster, and the permission element data is stored in the relational database.

[0140] See also Figure 3 , Figure 4 , Figure 3 It is a flow chart of configuring data authority on a data authority service disclosed in an embodiment of the present invention. Figure 4 It is a schematic diagram of a permission data model disclosed in an embodiment of the present invention.

[0141] Configure the required role list on the data permission service and grant roles to users based on business needs. In order to classify and manage multiple users with similar permissions, roles are defined, such as system administrator, administrator, etc. A user can include one or more roles, and a role can include one or more users.

[0142] According to the permission requirements in the business system, set the permission element to page-interface-SQL. Configure SQLID, interface ID, and page CODE, where SQLID is the minimum permission unit. The relationship between the three permission elements is SQL>interface>page, that is, one page can be configured with multiple interfaces, one interface can be configured with multiple SQLs, and one SQL can be associated with multiple interfaces, and one interface can be associated with multiple pages.

[0143] After the permission element configuration is completed, authorize the role, select one or more roles in the role list, and then select one or more pages to create a permission set. Select the page and interface in the permission set to set the permission field and permission field type. The permission field type is divided into two types: institution type field and non-institution type field. For permission field settings, please refer to Figure 5-Figure 6 , Figure 5 This is a schematic diagram of setting the authority field of the organization type disclosed in an embodiment of the present invention. Figure 6 It is a schematic diagram of setting non-institutional type permission fields disclosed in an embodiment of the present invention. Among them, the institutional type permission field includes default permissions. Default permissions mean that the user has only configured the institutional permission field, but has not assigned a specific role. At this time, all roles and users will use the same permission type. There are two types of default permission types, this unit, this unit and subordinate units. This unit means that all users accessing the interface can only see the data of this unit. This unit and subordinate units mean that all data under this unit can be seen, including subordinate units and subsidiaries. At this point, the data permission configuration on the data permission service is completed.

[0144] It can be seen that through the improvement of the data permission model, the data permission service can support more complex, fine-grained, and multi-dimensional permission control. At the same time, the improvement of data permission configuration has turned complex data permission configuration into a visualization, which only requires simple training for implementation personnel to get started, and data permissions can be dynamically added or modified at runtime, and the data shared through the cache database cluster will take effect in real time.

[0145] In the embodiment of the present invention, optionally, the way in which the interception module 901 intercepts the access request sent by the user includes:

[0146] A1. Receive access request sent by user;

[0147] A2. Based on the page identifier included in the access request, determine the interface identifier of the service that needs to be called by the access request;

[0148] A3. Based on the interface identifier, determine the SQL identifier corresponding to the interface identifier;

[0149] A4. Intercept the SQL statement corresponding to the SQL identifier through the pre-configured data permission authentication tool.

[0150] In this optional embodiment, a data permission authentication tool SDK is integrated into each service that requires data permission control. The data permission authentication SDK is a jar package that is integrated into other microservice application modules for use. Specifically, the data permission authentication SDK is located in each microservice module, and there is a reference relationship between the service and the data permission authentication SDK. The data permission authentication SDK is referenced by the service in the form of a jar package and is set in the pom.xml file of Maven or the build.gradle file of Gradle.

[0151] In this optional embodiment, when a user accesses a page function, the access request sent by the user carries the page identifier pageCode of the target page that the user needs to access, and the data authority service can obtain the association between the pre-configured pageCode and the interface ID and SQLID. For example, if the target page that the user needs to access needs to call the server interface and execute SQL, the data authority service can determine the interface identifier of the service that the access request needs to call, and based on the interface identifier, determine the SQL identifier corresponding to the interface identifier. The data authority authentication SDK will intercept the SQL execution operation, specifically when the persistence layer executes SQL. The interception method can be configured as MyBatis Intercepts, Spring AOP, or Java Agent dynamic injection.

[0152] The query module 902 is used to query the preset permission database for permission results that match the access request.

[0153] In the embodiment of the present invention, optionally, the query module 902 queries the preset authority database for an authority result that matches the access request in the following manner:

[0154] Based on the page identifier, interface identifier, and SQL identifier, query the preset permission database for permission results that match the page identifier, interface identifier, and SQL identifier.

[0155] In this optional embodiment, a redis cache is requested to obtain permission data, and the data includes pageCode, interface ID, SQLID, and permission-related configuration.

[0156] The judgment module 903 is used to judge whether the user meets the preset access condition according to the permission result when there is a permission result matching the access request in the preset permission database.

[0157] In the embodiment of the present invention, optionally, the judgment module 903 judges whether the user meets the preset access condition according to the permission result in the following manner: Figure 8 The process shown is to determine whether the user meets the preset access conditions based on the permission results:

[0158] S801. Determine whether the permission result indicates that the target page or the target interface corresponding to the target page has been pre-configured with the corresponding target permission, and the target interface corresponding to the target page is the interface that needs to be called to access the target page. If the permission result indicates that the target permission has been pre-configured for the target page or the target interface corresponding to the target page, then perform the step of determining whether the user meets the preset access condition according to the permission type of the target permission. If the permission result indicates that the target permission has not been pre-configured for the target page or the target interface corresponding to the target page, then determine that the user does not meet the preset access condition.

[0159] In this optional embodiment, the permission result includes pre-configured permission information for the target page or the target interface corresponding to the target page. For example, role permissions are pre-configured for the target page or the target interface corresponding to the target page. Then, it is determined whether the current permission result indicates that the corresponding target permissions are pre-configured for the target page or the target interface corresponding to the target page. If it indicates that the target permissions are configured, it is necessary to execute data permission logic. If it indicates that the target permissions are not configured, the current user does not have access rights.

[0160] In the embodiment of the present invention, further optionally, if the permission result indicates that a target permission is pre-configured for the target page or the target interface corresponding to the target page, then judging whether the user meets the preset access condition according to the permission type of the target permission includes:

[0161] S802: If the permission result indicates that the target permission is pre-configured for the target page or the target interface corresponding to the target page, determine the permission type of the target permission.

[0162] In this optional embodiment, the permission type of the target permission is the permission type of the permission possessed by the user sending the access request, such as a role permission type, a default permission type, or other permission types pre-assigned to the user.

[0163] S803: If it is determined that the permission type of the target permission is a default permission type, it is determined that the user meets the preset access condition.

[0164] In this optional embodiment, if the permission type of the target permission configured in the current permission result is the default permission type, that is, the role and the user will use the same permission type, that is, the user sending the access request has the permission to access, that is, the user meets the preset access conditions.

[0165] S804: If it is determined that the permission type of the target permission is a role permission type, then step S805 is executed.

[0166] S805. Obtain all roles included in the permission result to obtain a first role set, and obtain all roles owned by the user to obtain a second role set, and execute step S806.

[0167] S806: Determine whether there is an intersection between the first role set and the second role set.

[0168] If there is no intersection between the first role set and the second role set, it is determined that the user does not meet the preset access condition.

[0169] If there is an intersection between the first role set and the second role set, it is determined that the user meets the preset access condition.

[0170] In this optional embodiment, if the permission type of the target permission configured in the current permission result is a role permission type, that is, the user needs to have the same role permission as the target data to be accessed in order to access the data. It is determined whether the first role set of all roles included in the permission result and the second role set of all roles owned by the user have an intersection. If there is an intersection, the user who sent the access request has the permission to access, that is, the user meets the preset access conditions; if there is no intersection, the user who sent the access request does not have the permission to access, that is, the user does not meet the preset access conditions.

[0171] It can be seen that this optional embodiment can analyze the obtained permission result to specifically determine whether the permission result indicates that the corresponding target permission is pre-configured for the target page or the target interface corresponding to the target page, and determine whether the user meets the preset access conditions. That is, only one query of the cache cluster is required during the permission authentication process, which reduces the performance loss of permission authentication.

[0172] The access module 904 is used to access corresponding data according to the access request if it is determined that the user meets the preset access conditions.

[0173] In the embodiment of the present invention, when it is determined that the user meets the preset access condition, that is, the user has access rights to the target page, the corresponding data can be accessed according to the access request.

[0174] In the embodiment of the present invention, optionally, the access module 904 accesses corresponding data according to the access request in the following manner:

[0175] B1. When the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, obtain permission information corresponding to each role in the second role set.

[0176] In this optional embodiment, when the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, that is, a role owned by the user has access rights, then the SQL executed by the access request needs to be rewritten according to the access rights owned by the user to achieve data access. First, determine all the roles owned by the user and the permission information corresponding to each role owned by the user. For example, the user has three roles, R1, R2, and R3. In a certain interface, R1 has the permission of unit A, R2 has the permission of units A, B, and C, and R3 has the permission of units B, C, and D.

[0177] B2. Merge the permission information corresponding to all roles in the second role set to obtain the permission union of the second role set.

[0178] In this optional embodiment, the union authority information of the authority information corresponding to all roles owned by the user is obtained. For example, by merging the A unit authority of user role R1, the A, B, C unit authority of role R2, and the B, C, D unit authority of role R3, it can be determined that the user has the A, B, C, D unit authority.

[0179] B3. Modify the access request according to the permission union of the second role set to obtain a modified access request.

[0180] In this optional embodiment, the permission condition is generated according to the permission field configured by the user on the permission service page. When the user configures the permission field in the permission service, the user needs to specify the three elements of the permission table, permission field, and permission field value. When generating the permission condition in the permission authentication stage, the three elements of the permission table, permission field, and permission field value corresponding to the permission set owned by the user are combined into an SQL statement and then spliced ​​on the business SQL in the form of "IN (permission condition SQL)" to obtain the modified access request.

[0181] B4. Access the corresponding data according to the modified access request.

[0182] It can be seen that by dynamically modifying SQL according to permission data, permission control can be achieved.

[0183] In the embodiment of the present invention, optionally, the access module 904 is further configured to: when there is no permission result matching the access request in the preset permission database, access corresponding data according to the access request.

[0184] In this optional embodiment, when querying the preset permission database according to the access request, if there is data in the preset permission database, it means that the SQLID is configured with data permissions. If data permissions are configured, the data permission logic will be executed. If data permissions are not configured, it will be released directly.

[0185] The prompt module 905 is used to send an unauthorized access prompt to the user if it is determined that the user does not meet the preset access conditions.

[0186] In the embodiment of the present invention, when the user does not have the access authority to access the corresponding data of the access request, a prompt of no-authority access is sent to the user. At the same time, the relevant information of the user without the access authority can also be sent to the security management terminal for risk prompting.

[0187] It can be seen that the implementation Fig. 9 The described microservice-based data permission control device intercepts the user's access request, queries the preset permission database for the permission result that matches the access request, and determines whether the user meets the preset access conditions based on the found permission result; if satisfied, the corresponding data is accessed; if not satisfied, a prompt of unauthorized access is sent. It can be seen that the implementation of the present invention can obtain the permission result by querying the permission database once during the permission authentication stage, reducing the performance loss of permission authentication, and at the same time, it can enable the data permission service to support more complex, finer-grained, and multi-dimensional permission control, and adapt to the current complex business system based on the microservice architecture. The demand for data permissions.

[0188] Embodiment 3

[0189] See also Fig.10 , Fig.10 Schematic diagram of another microservice-based data authority control device disclosed in an embodiment of the present invention. Fig.10 As shown, the microservice-based data authority control device may include:

[0190] A memory 1001 storing executable program codes;

[0191] A processor 1002 coupled to the memory 1001;

[0192] The processor 1002 calls the executable program code stored in the memory 1001 to execute the steps in the microservice-based data permission control method described in Embodiment 1 or Embodiment 2 of the present invention.

[0193] Embodiment 4

[0194] An embodiment of the present invention discloses a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are called, they are used to execute the steps in the microservice-based data permission control method described in Embodiment 1 or Embodiment 2 of the present invention.

[0195] Embodiment 5

[0196] An embodiment of the present invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to enable a computer to execute the steps in the microservice-based data permission control method described in Embodiment 1 or Embodiment 2.

[0197] The device embodiments described above are only illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, i.e., they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative work.

[0198] Through the specific description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the above technical solution can be essentially or partly contributed to the prior art in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, and the storage medium includes a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable rewritable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0199] Finally, it should be noted that the data permission control method and device based on microservices disclosed in the embodiments of the present invention disclose only the preferred embodiments of the present invention, which are only used to illustrate the technical solution of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, it should be understood by those skilled in the art that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data permission control method based on microservices, characterized in that: The method comprises: Intercepting an access request sent by a user, wherein the access request includes a page identifier of a target page that the user needs to access; Querying a preset permission database for a permission result that matches the access request; When there is a permission result matching the access request in the preset permission database, determining whether the permission result indicates that a corresponding target permission is pre-configured for the target page or a target interface corresponding to the target page, and the target interface corresponding to the target page is an interface that needs to be called to access the target page; If the permission result indicates that the target permission is pre-configured for the target page or the target interface corresponding to the target page, then judging whether the user meets the preset access condition according to the permission type of the target permission; If it is determined that the user meets the preset access condition, accessing the corresponding data according to the access request; If it is determined that the user does not meet the preset access conditions, a prompt indicating that the user does not have permission to access is sent to the user; The determining whether the user meets a preset access condition according to the permission type of the target permission includes: If the permission type of the target permission is a default permission type, determining that the user meets the preset access condition; If the permission type of the target permission is a role permission type, obtain all roles included in the permission result to obtain a first role set, and obtain all roles owned by the user to obtain a second role set, and determine whether the first role set and the second role set have an intersection; If there is no intersection between the first role set and the second role set, determining that the user does not meet the preset access condition; If the first role set and the second role set have an intersection, it is determined that the user meets the preset access condition.

2. The microservice-based data permission control method according to claim 1 is characterized in that: The intercepting of the access request sent by the user comprises: Receive access requests sent by users; Determine, based on the page identifier included in the access request, an interface identifier of a service that needs to be called by the access request; Based on the interface identifier, determine the SQL identifier corresponding to the interface identifier; The SQL statement corresponding to the SQL identifier is intercepted by a pre-configured data authority authentication tool.

3. The microservice-based data permission control method according to claim 2 is characterized in that: The querying of the permission result matching the access request in the preset permission database includes: Based on the page identifier, the interface identifier, and the SQL identifier, query the preset authority database for an authority result that matches the page identifier, the interface identifier, and the SQL identifier.

4. The microservice-based data permission control method according to claim 1 is characterized in that: Accessing corresponding data according to the access request includes: When the permission type of the target permission is a role permission type and there is an intersection between the first role set and the second role set, obtaining permission information corresponding to each role in the second role set; Merging the permission information corresponding to all roles in the second role set to obtain a permission union of the second role set; Modify the access request according to the permission union of the second role set to obtain a modified access request; Access corresponding data according to the modified access request.

5. The microservice-based data permission control method according to any one of claims 1 to 4, characterized in that: The method further comprises: When there is no permission result matching the access request in the preset permission database, a corresponding access operation is performed according to the access request.

6. A data authority control device based on microservices, characterized in that: The device comprises: An interception module, used to intercept an access request sent by a user, wherein the access request includes a page identifier of a target page that the user needs to access; A query module, used to query a preset permission database for permission results matching the access request; A judgment module, configured to judge, when there is a permission result matching the access request in the preset permission database, whether the permission result indicates that a corresponding target permission is pre-configured for the target page or a target interface corresponding to the target page, and the target interface corresponding to the target page is an interface that needs to be called to access the target page; if the permission result indicates that the target permission is pre-configured for the target page or a target interface corresponding to the target page, then judging whether the user meets the preset access condition according to the permission type of the target permission; An access module, configured to access corresponding data according to the access request if it is determined that the user meets the preset access condition; A prompt module, configured to send an unauthorized access prompt to the user if it is determined that the user does not meet the preset access conditions; The method in which the judgment module judges whether the user meets the preset access condition according to the permission type of the target permission includes: If the permission type of the target permission is a default permission type, determining that the user meets the preset access condition; If the permission type of the target permission is a role permission type, obtain all roles included in the permission result to obtain a first role set, and obtain all roles owned by the user to obtain a second role set, and determine whether the first role set and the second role set have an intersection; If there is no intersection between the first role set and the second role set, determining that the user does not meet the preset access condition; If the first role set and the second role set have an intersection, it is determined that the user meets the preset access condition.

7. A data authority control device based on microservices, characterized in that: The device comprises: A memory storing executable program code; a processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the microservice-based data permission control method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, which, when called, are used to execute the microservice-based data permission control method according to any one of claims 1 to 5.

Images