An interface configuration-based data permission method
The interface-configured data permission method addresses inflexibility and complexity in existing systems by using a@DataPermission annotation and multi-dimensional filtering, ensuring efficient and decoupled data access control with reduced maintenance costs.
Patent Information
- Application Number
- CN202211164482.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-09-23
- Publication Date
- 2025-07-08
- Estimated Expiration
- 2042-09-23
AI Technical Summary
The existing technology has problems such as poor flexibility, inability to adapt to business logic changes, high cost of writing code, strong coupling, and unfriendly user experience in data permission management, and cannot meet the internal refined management needs of enterprises and the security requirements of sensitive data.
Through the data permission method based on interface configuration, the @DataPermission annotation class is used to describe whether the interface needs to be filtered. Combined with AOP sectional programming and data permission configuration table, it supports multi-dimensional data permission control. Users configure permissions through front-end pages to reduce SQL stitching and business code coupling.
It realizes flexible and precise data access control, reduces maintenance costs, improves user experience, supports multi-dimensional permission management, reduces unnecessary SQL operations, and enhances system flexibility and security.
Smart Images

Figure CN115906148B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of permission filtering, and in particular to a data permission method based on interface configuration. Background Art
[0002] With the continuous improvement of enterprise informatization and digitalization, the continuous increase of internal systems, and the continuous increase of business data volume, the original extensive data permission management method can no longer meet the refined management requirements such as business field segmentation, management responsibility segmentation, and personalized management within the enterprise. At the same time, it is also unable to guarantee the security of sensitive data such as customer information and price information.
[0003] The current method commonly used in the industry is to write the control logic of data permissions through code. When a user accesses one type of business data, code is written to control the access rights of that type of business data; when a user accesses another type of business data, another set of code is written to control the access rights of another type of business data. This method has the disadvantages of poor flexibility, inability to adapt to changes in business logic, and high time cost of writing code.
[0004] Therefore, there is an urgent need for a method that can more flexibly, accurately and conveniently control the system users' access rights to different business data within the enterprise.
[0005] For example, the invention application patent with the patent publication number of CN114428802A discloses a data filtering method and system based on user permissions, which can realize data permission filtering, but relies on adding permission attribution fields to the database business data table to realize it, adding fields that are not related to the business, increasing coupling, and is not conducive to maintenance. For another example, the invention application patent with the patent publication number of CN114692208A discloses a method for processing data query service permissions, which can realize the allocation of query permissions of different metadata to users, but cannot authorize data permissions in multiple dimensions, which is not flexible enough. For another example, the invention application patent with the patent publication number of CN114722250A discloses a method for filtering data horizontal and vertical permissions based on configuration, which can realize the configuration of data permission rules for data table fields, which is friendly to developers, but not friendly to system users. Users do not care about the specific data table structure, name and meaning, and the configuration is cumbersome and difficult to understand. Users need to master certain technical knowledge, and cannot be processed according to the particularity of user roles (such as: super administrator, specifying roles with high data permissions). Summary of the invention
[0006] To solve the above problems, the present invention designs a data permission method based on interface configuration, which is beneficial to user data access control, supports configuring data permissions for users through the front-end page, has flexible configuration and simple operation, and can achieve data access control based on a small amount of code.
[0007] To achieve the above object, the present invention provides the following technical solutions:
[0008] A data permission method based on configuration, comprising: S101. Making a data permission configuration table for the user's permission filtering rules and storing it in the database, providing the user with data permission configuration options for each dimension; S102. Configuring the user's permission filtering rules on the front-end page, determining whether data permission filtering is required for each dimension by checking the configuration for each dimension, and persisting the configuration results for each dimension to the data permission configuration table, and at the same time, storing them in redis; S103. Adding a @DataPermission custom annotation class in the system to describe whether the interface needs to perform data permission filtering; S104. When developers develop an interface, adding the @DataPermission annotation to the interface to indicate that the current interface needs to perform data permission filtering; S105. When a user accesses data, scanning whether the accessed interface has the @DataPermission annotation through AOP aspect programming, and judging whether the accessed interface needs to perform data permission filtering by whether the @DataPermission annotation exists; if there is the @DataPermission annotation, data permission filtering is required; directly obtaining the data permission configuration of the current user from redis, if the data permission configuration cannot be directly obtained, querying the data permission configuration through the data permission configuration table of the current user, and storing the query result in redis; and querying the business data table through the obtained data permission configuration to obtain the data permissions for each dimension that meet the current user, and returning the query result; if there is no @DataPermission annotation, data permission filtering is not required, and the query result is directly returned.
[0009] A further technical solution is that the data permission configuration at least includes a primary key, a user ID, and several dimensions for performing permission filtering.
[0010] A further technical solution is that the several dimensions for performing permission filtering at least include: organizational structure dimension, audit dimension, document creator dimension, and full dimension, where the organizational structure dimension, audit dimension, and document creator dimension are subsets of the full dimension, and there may be an intersection among the organizational structure dimension, audit dimension, and document creator dimension.
[0011] A further technical solution is as follows: When the organizational structure dimension is enabled for data permission filtering, the user can access the data of the document preparer or the department to which the associated user belongs, as well as the data of all subordinate departments; when the approval dimension is enabled for data permission filtering, it is necessary to associate with the workflow data table, and there are documents to be approved and approved documents; when the document preparer dimension is enabled for data permission filtering, it means that data filtering is performed by the document preparer, and only the data whose document preparer is oneself can be accessed; when the full dimension is enabled for data permission filtering, it means that data filtering is performed through the full permission dimension, and the current user can access all data without restrictions.
[0012] A further technical solution is as follows: In S105, after obtaining the data permission configuration, find out the dimensions that are true in the user data permission configuration, construct a combined query condition for the dimensions that are true through "or", and hand it over to the interpretation execution engine to convert it into a Predicate query condition object or SQL statement through the built-in converter to query the data permission configuration table in the database.
[0013] A further technical solution is as follows: The converter is a JPA converter or an SQL converter.
[0014] A further technical solution is as follows: In S105, if none of the dimensions in the user data permission configuration are true, then construct a query condition according to the document preparer dimension.
[0015] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0016] A data permission method based on interface configuration of the present invention, the data permission can support multiple dimensions, is convenient and flexible to cooperate, and only the interface with the data permission @DataPermission annotation needs to perform permission filtering, reducing unnecessary SQL splicing, the data permission filtering logic is unified, and it is not coupled with the business code. Compared with the traditional method coupled with the business code, there is no need to add fields for data permission filtering in the business data table, the dimension of the data permission supporting the business organization node is increased, and the maintenance cost of the business data is reduced. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 It is a schematic diagram of several dimensions for permission filtering in an embodiment of the present invention.
[0018] Figure 2 It is a schematic diagram of a data permission method based on interface configuration in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0019] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.
[0020] Embodiment
[0021] Referring to the attached Figure 1-2 , a data permission method based on interface configuration is specifically as follows:
[0022] S101. Create a data permission configuration table for the user's permission filtering rules and store it in the database, providing the user with data permission configuration options in various dimensions;
[0023] In this embodiment, the database is used as the storage medium to save the user's data permission configuration table;
[0024] The data permission configuration includes at least a primary key, a user ID, and several dimensions for permission filtering, such as Figure 1 shown, the several dimensions include at least: the organizational structure dimension, the audit dimension, the document maker dimension, and the full dimension. Among them, the organizational structure dimension, the audit dimension, and the document maker dimension are subsets of the full dimension, and there may be an intersection among the organizational structure dimension, the audit dimension, and the document maker dimension.
[0025] Among them, the field composition of the data permission configuration table includes at least:
[0026] id: Primary key;
[0027] user_id: User ID (indicating the data permission configuration for this user);
[0028] organization: Whether to enable data permission filtering for the organizational structure dimension; when enabling the organizational structure dimension for data permission filtering, the user can access the data of the document maker or the department to which the associated user belongs in the document, as well as the data of all subordinate departments; for example: User Zhang San is in Department A. When the department where the document maker is located is Department A or a subordinate department of Department A, Zhang San can access all users in Department A and the business documents created by users in all sub-departments under Department A.
[0029] audit: Whether to enable data permission filtering for the audit dimension; when the user enables the audit dimension for data permission filtering, the workflow data table needs to be associated at this time, and the user can have access to the documents to be audited and the audited documents; for example: Zhang San can access the documents he has audited or the documents to be audited by him.
[0030] creator: Whether to enable permission filtering by the creator dimension; when the user enables permission filtering by the creator dimension, it means filtering data by the creator, and only data whose creator is the user himself can be accessed.
[0031] all: Whether to enable full-dimension permission filtering; when the user enables full-dimension permission filtering, it means filtering data through the full-permission dimension, and the current user can access all data without restrictions.
[0032] S102. The front-end page configures the user's permission filtering rule D1. By checking and configuring each dimension, it determines whether data permission filtering is required for each dimension, and persists the configuration results of each dimension to the database. At the same time, it is stored in redis for convenient subsequent invocation to improve performance.
[0033] S103. Add a @DataPermission custom annotation class to the system to describe whether the interface requires data permission filtering.
[0034] This annotation class includes but is not limited to the following attributes:
[0035] value: Default is true, which describes whether the interface requires data permission filtering.
[0036] S104. When developers develop an interface, add the @DataPermission annotation to the interface of the view class, indicating that the current interface requires data permission filtering.
[0037] S105. When a user accesses data, use AOP aspect programming to scan whether the accessed interface has the @DataPermission annotation, and judge whether the accessed interface requires data permission filtering by whether the @DataPermission annotation exists.
[0038] If there is a @DataPermission annotation, data permission filtering is required. Specifically: directly obtain the data permission configuration of the current user from redis. If the data permission configuration cannot be directly obtained, query the data permission configuration through the data permission configuration table of the current user, and return and store the query result in redis; and query the business data table through the obtained data permission configuration to obtain the data permissions of each dimension that meet the current user, and return the query result; the data permission configuration table in this embodiment is stored in the database.
[0039] If there is no @DataPermission annotation, data permission filtering is not required, and the query result is directly returned.
[0040] In this embodiment, after obtaining the data permission configuration table of the permission filtering rule D1 through AOP aspect programming, the execution code is parsed to find out multiple dimensions with a value of true in the user data permission configuration. The multiple dimensions include: organization, audit, creator, and all, etc. Query conditions are constructed through AND connection, and the AND connection is represented by "or". When there are multiple dimensions of data permission configuration, the specifications of multiple dimensions are associated with "or (or)", and meeting any one of them is sufficient; to construct a combined query condition, which is handed over to the interpretation execution engine. Through the built-in JPA converter or SQL converter, the combined query condition is converted into a Predicate query condition object in the Criteria API of JPA, or an SQL statement, to query data in the database and return it to the front-end page for display to the user; if none of the multiple dimensions are found, that is, each dimension is not true, when configuring the user data permission filtering rule, the query condition is defaultly constructed according to the dimension of the document preparer to obtain the permission filtering rule and return the result, ending the entire query process.
[0041] Among them, AOP aspect programming: AOP is the abbreviation of Aspect Oriented Programming, which means: aspect-oriented programming. It is a technology that realizes the unified maintenance of program functions through pre-compilation and dynamic proxy during runtime. Using AOP, each part of the business logic can be isolated, thereby reducing the coupling degree between parts of the business logic, improving the reusability of the program, and at the same time improving the development efficiency.
[0042] JPA is the abbreviation of Java Persistence API, and its Chinese name is Java Persistence Layer API. It uses JDK 5.0 annotations or XML to describe the mapping relationship between objects and relational tables, and persists the entity objects during runtime to the database.
[0043] A data permission method based on interface configuration of the present invention. The data permission can support multiple dimensions, is convenient and flexible to cooperate with, and only the interface with the data permission @DataPermission annotation needs to perform permission filtering, reducing unnecessary SQL splicing. The data permission filtering logic is unified and not coupled with the business code. Compared with the traditional method coupled with the business code, there is no need to add fields for data permission filtering in the business data table. The data permission supports an increased dimension of business organization nodes, reducing the maintenance cost of business data.
[0044] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.
Claims
1. A configuration-based data permission method, characterized in that, Including: S101. Create a data permission configuration table for the user's permission filtering rules and store it in the database, providing the user with data permission configuration options for each dimension; S102. Configure the user's permission filtering rules on the front-end page. By checking the configuration for each dimension, determine whether data permission filtering is required for each dimension, and persist the configuration results for each dimension to the data permission configuration table. At the same time, store them in Redis; S103. Add a @DataPermission custom annotation class to the system to describe whether the interface requires data permission filtering; S104. When developers develop an interface, add the @DataPermission annotation to the interface to indicate that the current interface requires data permission filtering; S105. When the user accesses data, use AOP aspect programming to scan whether the accessed interface has the @DataPermission annotation, and judge whether the accessed interface requires data permission filtering based on whether the @DataPermission annotation exists; If there is the @DataPermission annotation, data permission filtering is required; directly obtain the data permission configuration of the current user from Redis. If the data permission configuration cannot be directly obtained, query the data permission configuration through the data permission configuration table of the current user, and store the query result in Redis; and query the business data table through the obtained data permission configuration to obtain the data permissions for each dimension that meet the current user, and return the query result; If there is no @DataPermission annotation, data permission filtering is not required, and the query result is directly returned; In S105, after obtaining the data permission configuration, find out the dimensions with true values in the user data permission configuration, construct a combined query condition through "or" for the dimensions with true values, hand it over to the interpretation execution engine, and convert it into a Predicate query condition object or SQL statement through the built-in converter to query the data permission configuration table in the database.
2. The data permission method based on configuration according to claim 1, wherein The data permission configuration includes at least a primary key, a user ID, and several dimensions for permission filtering.
3. The data permission method based on configuration according to claim 2, wherein The several dimensions for permission filtering include at least: the organizational structure dimension, the approval dimension, the document maker dimension, and the full dimension. Among them, the organizational structure dimension, the approval dimension, and the document maker dimension belong to the subset of the full dimension, and there may be an intersection among the organizational structure dimension, the approval dimension, and the document maker dimension.
4. The method for data permission based on configuration according to claim 3, wherein When the organizational structure dimension is enabled for data permission filtering, the user can access the data of the document maker or the department to which the associated user belongs in the document, as well as the data of all subordinate departments; When the approval dimension is enabled for data permission filtering, it is necessary to associate with the workflow data table, and have the documents to be approved and the approved documents; When the document maker dimension is enabled for data permission filtering, it means that data filtering is performed by the document maker, and only the data whose document maker is oneself can be accessed; When the full - dimension data permission filtering is enabled, it means that data filtering is performed through the full - permission dimension, and the current user can access all data without restrictions.
5. The data permission method based on configuration according to claim 1, characterized in that The converter is a JPA converter or an SQL converter.
6. The method for data permissions based on configuration according to any one of claims 1-5, characterized in that, In S105, if each dimension in the user data permission configuration is not true, the query condition is constructed according to the document preparer dimension.
Citation Information
Patent Citations
Data filtering method and system based on user permission
CN114428802A
Data query service authority processing method
CN114692208A
Data horizontal and vertical permission filtering method realized based on configuration
CN114722250A
API access control method, apparatus and device, and medium
CN112035858A
A micro-service-based data permission control method and device
CN114036552A