CN118468320B - Data authority control method and system - Google Patents

Abstract

The present application relates to a data permission control method and system, and relates to the technical field of data control. The method comprises: after a user account successfully logs in, querying a database based on the logged-in user account to obtain all role information associated with the user account; defining and storing data permission rules in the database; the data permission rules include: permission rules for roles, business domains, business entities, accessible data records and permission operation types; the user is a user of a multi-tenant system; querying a permission rule table based on all associated role information; extracting all relevant permission settings based on the permission rule table; the permission settings include: access control lists, operation permissions and data access scopes; caching the extracted permission setting data in the user session, and maintaining the permission setting data throughout the user session; and allowing or denying based on the permission setting data when a user account initiates a data access request.

Description

Data authority control method and system

Technical Field

The present application relates to the technical field of data authority control, and in particular, to a data authority control method and system.

Background Art

In modern software systems, especially multi-tenant systems and cloud-based services, data isolation and access control are critical issues. Existing data permission control schemes are usually fixed and inflexible, and it is difficult to meet the rapidly evolving business needs and fine-grained data access control. In addition, traditional permission control schemes often lack scalability and adaptability, and cannot effectively cope with the ever-changing permission requirements between different users and business domains.

Data permission management in existing technologies usually relies on static permission allocation schemes, which lack flexibility and scalability in multi-tenant and cloud service environments. This limits the ability of organizations to flexibly control data access in a rapidly changing business environment.

Summary of the invention

In order to at least partially solve the above technical problems, the present application provides a data permission control method and system.

In a first aspect, a data permission control method provided in the present application adopts the following technical solution.

A data authority control method, comprising:

After the user account successfully logs in, the database is queried based on the logged-in user account to obtain all role information associated with the user account; data permission rules are defined and stored in the database; the data permission rules include: role, business domain, permission rules for business entities, accessible data records and permission operation types; the user is a user of a multi-tenant system;

Query the permission rule table based on all the associated role information; extract all relevant permission settings based on the permission rule table; the permission settings include: access control list, operation permissions and data access scope;

caching the extracted permission setting data in the user session, and maintaining the permission setting data throughout the user session;

When the user account initiates a data access request, permission or rejection is performed based on the permission setting data.

Optionally, querying the permission rule table based on all the associated role information includes:

After the user account successfully logs in, parse and confirm the user's role;

Extracting permission rules related to the role of the user from the permission configuration storage of the database based on the role of the user;

In the data operation layer, dynamically assemble the where conditions of the SQL query according to the extracted permission rules;

Execute the modified SQL query to ensure that each database query or modification is performed in accordance with the user's data access permissions.

Optionally, the extracted permission settings data is cached in the user session, including:

Write the extracted permission setting data into the distributed cache;

For subsequent data access requests, first query whether there is permission data corresponding to the data access request in the distributed cache; if there is corresponding permission data in the distributed cache, then directly perform permission verification through the cached data in the distributed cache; if there is no corresponding permission data in the distributed cache; then reload the permission setting data from the database;

The distributed cache is updated regularly and cache performance is monitored.

Optionally, when the user account initiates a data access request, allowing or denying the request based on the permission setting data includes:

When a user account initiates a data access request, it is captured by an interceptor; the interceptor is integrated into the data processing layer of the server; the data access request includes reading, updating or deleting data;

The interceptor calls the permission check service; when the permission check service runs, it retrieves the permission rules preloaded in the distributed cache from the user session;

Determine whether the requested data point matches the cached permission rules; if the data access request matches the user permissions, access is allowed; if not, access is denied and a corresponding error message or warning message is returned.

Optionally, dynamically stitch the where conditions of the SQL query based on the extracted permission rules at the data operation layer, including:

Pre-configure a permission rule model, wherein the permission rule model stores permission information of different roles;

After the user logs in successfully, the user's role is parsed, and the corresponding permission rules are extracted from the permission configuration storage according to the role;

Constructing a permission parser, which dynamically constructs query conditions according to the user's permission rules;

Abstract permission rules into query condition templates;

Construct a dynamic SQL generator, which dynamically generates SQL statements according to the template provided by the authority parser and the actual query requirements;

When generating SQL queries, combine multiple conditions and optimize the generated query statements;

When permission rules change, update and synchronize the new permission settings.

Optionally, write the extracted permission setting data to the distributed cache, including:

Serialize the permission setting data and convert the permission setting data into a SON string; generate a composite hash key value based on the role, business entity and operation type for each permission setting data, wherein the hash key value is generated based on the role ID, business domain ID and business entity ID;

Use consistent hashing algorithm to shard permission setting data and evenly distribute data to each cache node; retain data copies on different nodes to prevent data unavailability caused by single point failure;

Embed version number and timestamp information in permission setting data. Every time permission rules are updated, the version number is updated synchronously. When caching data, the version number and the last update time are stored together as a basis for judging the freshness of the data. When querying permissions, compare the version information carried in the request with the version information in the cache to determine whether the permissions need to be reloaded.

For permission rules that are frequently accessed but infrequently changed, set a longer cache expiration time; for permissions that change frequently, shorten the cache validity period and combine it with an active monitoring mechanism. Once the background permission configuration changes, immediately notify the cache system to update the corresponding data;

While the permission setting data is written to the database, the atomicity of the data writing operation and the distributed cache update operation is ensured through the distributed transaction mechanism.

In a second aspect, a data permission control method provided in the present application adopts the following technical solution.

A data authority control system, comprising:

The first processing module is used to: after a user account successfully logs in, query the database based on the logged-in user account to obtain all role information associated with the user account; the database defines and stores data permission rules; the data permission rules include: role, business domain, permission rules for business entities, accessible data records and permission operation types; the user is a user of a multi-tenant system;

The second processing module is used to: query the permission rule table based on all the associated role information; extract all relevant permission settings based on the permission rule table; the permission settings include: access control list, operation permission and data access scope;

A third processing module is used to: cache the extracted permission setting data in the user session, and keep the permission setting data throughout the user session;

The fourth processing module is used to: when the user account initiates a data access request, allow or deny it based on the permission setting data.

In a third aspect, the present application discloses an electronic device, comprising a memory and a processor, wherein the memory stores a computer program that is loaded by the processor and executes any of the above methods.

In a fourth aspect, the present application discloses a computer-readable storage medium storing a computer program that can be loaded by a processor and execute any of the above methods.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a flow chart of a data authority control method according to an embodiment of the present application;

FIG2 is a system block diagram of a data authority control method according to an embodiment of the present application;

In the figure, 201 is a first processing module; 202 is a second processing module; 203 is a third processing module; 204 is a fourth processing module.

DETAILED DESCRIPTION

The present application is further described below in conjunction with Figures 1-2 and specific embodiments:

First of all, it should be noted that in the description of this application, if the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inside", "outside" and other directional words appear, the orientation or position relationship indicated is based on the orientation or position relationship shown in the drawings, which is only for the convenience of description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation of this application; in addition, if the terms "first", "second", "third" and other numerical quantifiers appear, they are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in this application, unless otherwise clearly specified and limited, if the terms "installed", "connected", and "connected" appear, they should be understood in a broad sense, for example, it can be a fixed connection, or a detachable connection, a limited connection such as an interference fit, a transition fit, or an integral connection; it can be directly connected or indirectly connected through an intermediate medium; therefore, for ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to the specific circumstances.

An embodiment of the present application discloses a data permission control method.

Some of the names are explained below.

User: refers to a user who can log in to the system to perform operations.

Role: A set of permissions defined by the system. Users obtain corresponding permissions by being assigned to one or more roles.

RBAC: Role-Based Access Control is a mature and widely used permission management method that manages and assigns permissions through roles to simplify permission management and improve security.

Data permissions: Specifies the scope of data that a role can access, such as views, records, fields, etc.

Tenant: A tenant refers to a user or user group in a multi-tenant system who occupies certain system resources and has an independent data space.

Business Domain: Business Domain refers to the collection of relevant business logic and data in the system. It usually defines a series of relevant business rules, entities, relationships and processes. For example, the order domain (power station development and construction process), post-rental (power station operation after construction and transportation), purchase, sales and inventory (logistics ordering, inventory management, etc.)

Business Entity/Table: Business Entity/Table is usually represented as a table in the database, which is a structured form of storing specific types of data in the business domain.

Business attribute/field: A business attribute/field refers to a specific item in a business entity and is used to describe a specific characteristic, quantity, property, or status of a business entity.

Referring to FIG. 1 , as an implementation of a data authority control method, a data authority control method includes the following steps:

Step S101: After the user account logs in successfully, query the database based on the logged in user account to obtain all role information associated with the user account; define and store data permission rules in the database; the data permission rules include: role, business domain, business entity permission rules, accessible data records and permission operation types; the user is a user of a multi-tenant system.

Specifically, the user logs in by entering a user name and password. After the system verifies the correctness of the credentials, it grants login permission.

Step S102, querying the permission rule table based on all the associated role information; extracting all relevant permission settings based on the permission rule table; the permission settings include: access control list, operation permission and data access scope.

Step S103: caching the extracted permission setting data in the user session, and maintaining the permission setting data throughout the user session.

Step S104: when the user account initiates a data access request, permission or rejection is performed based on the permission setting data.

Specifically, a multi-tenant system is an architectural design pattern that allows a single instance of a software application to provide services to multiple organizations (tenants), with each tenant's data and configuration independent and isolated to ensure data privacy and security. In permission management, a role is a set of predefined permissions that represent a user's functions and access rights in the system. Users obtain corresponding permissions by being assigned one or more roles. A business domain refers to an area in the system that focuses on a specific business logic and data set, such as sales, finance, human resources, etc. Each business domain contains specific business entities and operational processes. A business entity refers to a structured object in the system that stores a specific type of business data, such as customers, orders, products, etc. Data permission rules specify the user's access rights on specific business domains and business entities, including which data records and fields can be accessed and the types of operations allowed (such as read, write, delete). Access control lists (ACLs) define a list of rules for which users or roles can access specific resources. Operation permissions refer to the types of operations that users can perform in the system, such as viewing, editing, and deleting data.

After a user logs in, the system first identifies their identity and obtains all the role information associated with them. Based on the user role, the system queries the permission rule table in the database and extracts all the permission settings related to these roles. The extracted permission data is cached in the user's session, so that during the user session, permissions can be quickly verified without repeatedly querying the database, which significantly improves the system response speed and user experience. Using a caching mechanism (such as Redis) further optimizes performance. When a user tries to access data, the system decides whether to allow the access based on the permission settings cached in the session.

The technical solution of this application implements a dynamic data rights management and application mechanism, allowing flexible control of data access based on roles, accounts and business rules. Through integrated rights management and dynamic rights application modules, the system can provide fine-grained data access control without sacrificing performance.

As a specific implementation of a data permission control method, querying a permission rule table based on all the associated role information includes:

After the user account successfully logs in, parse and confirm the user's role;

Extracting permission rules related to the role of the user from the permission configuration storage of the database based on the role of the user;

In the data operation layer, dynamically assemble the where conditions of the SQL query according to the extracted permission rules;

Execute the modified SQL query to ensure that each database query or modification is performed in accordance with the user's data access permissions.

Specifically, by parsing user roles and extracting corresponding permission rules, refined management of user permissions is achieved. Dynamically splicing the where conditions of SQL queries at the data operation layer is a specific embodiment of dynamic permission application. This process ensures that even when executing queries or update operations, data can be filtered in real time according to the user's current permissions to prevent unauthorized access. For example, if a user is only allowed to view the data of his or her own department, the system will automatically add the department ID filtering condition to the SQL query to prevent the user from seeing data from other departments. Compared with the need to query the database permission configuration for each operation, dynamically generating SQL query conditions and applying them at the data operation layer reduces the number of database accesses and improves the system's processing speed and response efficiency. Especially in a high-concurrency environment, this approach significantly reduces the database load.

As a specific implementation of a data permission control method, caching the extracted permission setting data in a user session includes:

Write the extracted permission setting data into the distributed cache;

For subsequent data access requests, first query whether there is permission data corresponding to the data access request in the distributed cache; if there is corresponding permission data in the distributed cache, then directly perform permission verification through the cached data in the distributed cache; if there is no corresponding permission data in the distributed cache; then reload the permission setting data from the database;

The distributed cache is updated regularly and cache performance is monitored.

Specifically, by caching the permission setting data in a distributed cache (such as Redis), when the system processes the user's data access request, it can quickly obtain the permission information required for permission verification directly from the cache without querying the database every time. This significantly reduces the frequency of database access and the time cost of I/O operations, thereby improving the efficiency of data access and the response speed of the system. Although the permission data is cached, the timeliness of the permission information is ensured by the mechanism of regularly updating the cache. This means that even if the permission configuration changes (such as the administrator adjusts the permissions of a role), these changes will be reflected in the cache after a certain time interval, and then applied to the permission verification process immediately, ensuring the real-time and accuracy of permission control. The introduction of distributed cache enables the system to maintain good performance in the face of expanding user scale and increasing business complexity. By monitoring cache performance, system administrators can obtain real-time feedback on key indicators such as cache hit rate and response time, which is crucial for optimizing cache strategies and identifying potential problems. For example, if the cache hit rate is found to be low, it may be necessary to adjust the cache strategy or increase the cache capacity; if the cache access delay increases, it is necessary to check whether the cache node load is uneven or the network delay is a problem.

As a specific implementation of a data permission control method, when the user account initiates a data access request, permission or rejection is performed based on the permission setting data, including:

When a user account initiates a data access request, it is captured by an interceptor; the interceptor is integrated into the data processing layer of the server; the data access request includes reading, updating or deleting data;

The interceptor calls the permission check service; when the permission check service runs, it retrieves the permission rules preloaded in the distributed cache from the user session;

Determine whether the requested data point matches the cached permission rules; if the data access request matches the user permissions, access is allowed; if not, access is denied and a corresponding error message or warning message is returned.

Specifically, when a user attempts to perform a data access operation (whether it is reading, updating or deleting), the interceptor immediately intervenes at the data processing layer and effectively intercepts all data access requests. The interceptor calls the permission check service, which directly reads the preloaded permission rules (these rules are stored in the distributed cache) from the user session. This process takes advantage of the cache, greatly reduces direct access to the database, speeds up permission verification, and improves system performance. The permission check service accurately matches the specific content of the data access request (such as data type, field, operation type) with the permission rules in the cache, achieving fine-grained permission control. Based on the permission matching results, the system can dynamically decide whether to allow the data access request. If the request matches the user's permissions, the access is successful; if it does not match, the access is immediately denied, and an error or warning message is returned to clearly inform the user that their access rights are insufficient.

As one implementation method of a data permission control method, the where condition of the SQL query is dynamically spliced according to the extracted permission rules at the data operation layer, including:

Pre-configure a permission rule model, wherein the permission rule model stores permission information of different roles;

After the user logs in successfully, the user's role is parsed, and the corresponding permission rules are extracted from the permission configuration storage according to the role;

Constructing a permission parser, which dynamically constructs query conditions according to the user's permission rules;

Abstract permission rules into query condition templates;

Construct a dynamic SQL generator, which dynamically generates SQL statements according to the template provided by the authority parser and the actual query requirements;

When generating SQL queries, combine multiple conditions and optimize the generated query statements;

When permission rules change, update and synchronize the new permission settings.

Specifically, through the pre-configured permission rule model, the system can dynamically adjust data access permissions according to user roles, which enables the permission control strategy to adapt to changes in user roles in real time without manually adjusting each SQL query statement. The WHERE conditions of the SQL query are dynamically spliced at the data operation layer to ensure that each data query strictly follows the user's permission boundaries. Even if the user tries to access unauthorized data, the system can automatically block such requests because the permission restrictions have been embedded in the query conditions, effectively preventing potential data leakage risks. The constructed permission parser and dynamic SQL generator can efficiently generate customized query statements based on user permissions, reducing unnecessary data access and reducing database load. At the same time, by merging multiple conditions and optimizing the generated query statements, the query efficiency is further improved. When the permission rules change, you only need to update the corresponding settings in the permission configuration storage, and the parser and SQL generator will automatically generate query conditions dynamically according to the latest permission rules. By abstracting the permission rules into query condition templates, it becomes easier to add new roles or new permissions. You only need to add corresponding entries in the permission rule model without modifying the underlying SQL generation logic. The dynamically generated SQL statements contain the logic of permission control, which facilitates logging and helps administrators monitor permission usage.

As one implementation of a data permission control method, writing the extracted permission setting data into a distributed cache includes:

Serialize the permission setting data and convert the permission setting data into a SON string; generate a composite hash key value based on the role, business entity and operation type for each permission setting data, wherein the hash key value is generated based on the role ID, business domain ID and business entity ID;

Use consistent hashing algorithm to shard permission setting data and evenly distribute data to each cache node; retain data copies on different nodes to prevent data unavailability caused by single point failure;

Embed version number and timestamp information in permission setting data. Every time permission rules are updated, the version number is updated synchronously. When caching data, the version number and the last update time are stored together as a basis for judging the freshness of the data. When querying permissions, compare the version information carried in the request with the version information in the cache to determine whether the permissions need to be reloaded.

For permission rules that are frequently accessed but infrequently changed, set a longer cache expiration time; for permissions that change frequently, shorten the cache validity period and combine it with an active monitoring mechanism. Once the background permission configuration changes, immediately notify the cache system to update the corresponding data;

While the permission setting data is written to the database, the atomicity of the data writing operation and the distributed cache update operation is ensured through the distributed transaction mechanism.

Specifically, by serializing the permission setting data into a JSON string and storing it in a distributed cache, direct access to the database is reduced for each permission verification. Generating a composite hash key value and using a consistent hash algorithm for sharding not only ensures uniform distribution of data, but also improves the fault tolerance of the system by retaining data copies on different nodes. Even if a node fails, permission information can still be obtained from other copies to ensure service continuity. By embedding version numbers and timestamps in cached data and synchronously updating these metadata each time the permission rules are updated, the system can effectively determine the freshness of permission data and ensure data consistency and accuracy. The cache expiration time is dynamically adjusted according to the frequency of permission rule changes. A longer period is set for rules that do not change frequently, while the validity period is shortened for rules that change frequently. Combined with the active monitoring mechanism, efficient resource utilization and real-time requirements are achieved, balancing performance and data timeliness. The distributed transaction mechanism is used to ensure that the synchronization update operation of permission data between the database and the cache system is atomic, that is, either both operations are successful or both fail, avoiding data inconsistency problems and ensuring the rigor of permission control and the integrity of system data.

This application also provides a data permission control method, including:

The first processing module 201 is used to: after a user account successfully logs in, query the database based on the logged-in user account to obtain all role information associated with the user account; define and store data permission rules in the database; the data permission rules include: permission rules for roles, business domains, business entities, accessible data records and permission operation types; the user is a user of a multi-tenant system;

The second processing module 202 is used to: query the permission rule table based on all the associated role information; extract all relevant permission settings based on the permission rule table; the permission settings include: access control list, operation permission and data access scope;

The third processing module 203 is used to: cache the extracted permission setting data in the user session, and keep the permission setting data throughout the user session;

The fourth processing module 204 is used to: when the user account initiates a data access request, allow or deny the request based on the permission setting data.

The embodiment of the present application also discloses an electronic device.

Specifically, the device includes a memory and a processor, and the memory stores a computer program that can be loaded by the processor and execute any of the above-mentioned data authority control methods.

The embodiment of the present application also discloses a computer-readable storage medium. Specifically, the computer-readable storage medium stores a computer program that can be loaded by a processor and execute any of the above-mentioned data authority control methods, and the computer-readable storage medium includes, for example: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

It should be noted that the above embodiments are only used to illustrate the present application and are not intended to limit the technical solutions described in the present application. Although the present application has been described in detail in this specification with reference to the above embodiments, a person of ordinary skill in the art should understand that a person of ordinary skill in the art can still modify or make equivalent substitutions to the present application, and all technical solutions and improvements thereof that do not depart from the spirit and scope of the present application should be included in the scope of the claims of the present application.

Claims (4)

1. A data authority control method, characterized by comprising:

After the user account is successfully logged in, inquiring a database based on the logged-in user account to acquire all role information associated with the user account; defining and storing data authority rules in the database; the data authority rule includes: roles, service domains, authority rules of service entities, accessible data records and operation types of authorities; the user is a user of the multi-tenant system;

Querying a permission rule table based on the associated all role information; extracting all relevant rights settings based on the rights rule table; the authority setting includes: access control list, operation authority and data access range;

caching the extracted authority setting data in a user session, and keeping the authority setting data in the whole session of the user;

When the user account initiates a data access request, allowing or rejecting based on the authority setting data;

querying a permission rule table based on the associated all role information, wherein the permission rule table comprises:

after the user account login is successful, analyzing and confirming the role of the user;

Extracting authority rules related to the roles of the users from authority configuration storage of a database based on the roles of the users;

Dynamically splicing a sphere condition of the SQL query according to the extracted authority rule at a data operation layer;

Executing the modified SQL query to ensure that each database query or modification is performed according to the data access rights of the user;

Caching the extracted rights setting data in the user session, including:

writing the extracted authority setting data into a distributed cache;

For the subsequent data access request, firstly inquiring whether rights data corresponding to the data access request exist in the distributed cache; if the corresponding authority data exists in the distributed cache, directly verifying the authority through the cache data in the distributed cache; if the distributed cache does not have the corresponding authority data; reloading rights setting data from said database;

Periodically updating the distributed cache and monitoring cache performance;

when the user account initiates a data access request, allowing or rejecting based on the permission setting data, including:

capturing through an interceptor when a user account initiates a data access request; the interceptor is integrated in a data processing layer of the server; the data access request comprises reading, updating or deleting data;

The interceptor invokes a rights check service; the authority checking service retrieves the preloaded authority rules in the distributed cache from a user session when running;

judging whether the requested data point is matched with the authority rule of the cache; if the data access request matches the user rights, access is allowed; if the result is not consistent, access is refused and corresponding error information or warning information is returned;

dynamically splicing the sphere condition of the SQL query according to the extracted authority rule at the data operation layer, wherein the sphere condition comprises the following steps:

Pre-configuring a permission rule model, wherein permission information of different roles is stored in the permission rule model;

After the user logs in successfully, analyzing the role of the user, and extracting corresponding authority rules from the authority configuration storage according to the role;

constructing a permission analyzer, wherein the analyzer dynamically constructs query conditions according to permission rules of a user;

Abstracting the authority rule into a template of a query condition;

Constructing a dynamic SQL generator, wherein the dynamic SQL generator dynamically generates SQL sentences according to templates provided by a permission analyzer and actual query requirements;

when SQL query is generated, combining a plurality of conditions, and optimizing the generated query statement;

when the right rule changes, updating and synchronizing the new right setting;

Writing the extracted authority setting data into a distributed cache, including:

Carrying out serialization processing on the authority setting data, and converting the authority setting data into SON character strings; generating a composite hash key value based on a role, a service entity and an operation type for each piece of authority setting data, wherein the hash key value is generated based on a role ID, a service domain ID and a service entity ID;

Fragmenting the authority setting data by adopting a consistent hash algorithm, and uniformly distributing the data to each cache node; data copies are reserved on different nodes so as to prevent data unavailability caused by single-point faults;

Embedding a version number and timestamp information in the permission setting data, and synchronously updating the version number when each permission rule is updated; when caching data, storing the version number and the last updating time together, and taking the version number and the last updating time as the judging basis of the data freshness; when inquiring the rights, judging whether the rights need to be reloaded or not by comparing the version information carried by the request with the version information in the cache;

Setting longer buffer expiration time for authority rules which are accessed frequently and changed infrequently; for the rights which are changed frequently, shortening the cache validity period and combining an active monitoring mechanism, and immediately notifying a cache system to update corresponding data once the background rights configuration is changed;

And when the authority setting data is written into the database, ensuring the atomicity of data writing operation and distributed cache updating operation through a distributed transaction mechanism.

2. A data rights control system, comprising:

A first processing module for: after the user account is successfully logged in, inquiring a database based on the logged-in user account to acquire all role information associated with the user account; defining and storing data authority rules in the database; the data authority rule includes: roles, service domains, authority rules of service entities, accessible data records and operation types of authorities; the user is a user of the multi-tenant system;

A second processing module for: querying a permission rule table based on the associated all role information; extracting all relevant rights settings based on the rights rule table; the authority setting includes: access control list, operation authority and data access range;

A third processing module for: caching the extracted authority setting data in a user session, and keeping the authority setting data in the whole session of the user;

A fourth processing module for: when the user account initiates a data access request, allowing or rejecting based on the authority setting data;

querying a permission rule table based on the associated all role information, wherein the permission rule table comprises:

after the user account login is successful, analyzing and confirming the role of the user;

Extracting authority rules related to the roles of the users from authority configuration storage of a database based on the roles of the users;

Dynamically splicing a sphere condition of the SQL query according to the extracted authority rule at a data operation layer;

Executing the modified SQL query to ensure that each database query or modification is performed according to the data access rights of the user;

Caching the extracted rights setting data in the user session, including:

writing the extracted authority setting data into a distributed cache;

For the subsequent data access request, firstly inquiring whether rights data corresponding to the data access request exist in the distributed cache; if the corresponding authority data exists in the distributed cache, directly verifying the authority through the cache data in the distributed cache; if the distributed cache does not have the corresponding authority data; reloading rights setting data from said database;

Periodically updating the distributed cache and monitoring cache performance;

when the user account initiates a data access request, allowing or rejecting based on the permission setting data, including:

capturing through an interceptor when a user account initiates a data access request; the interceptor is integrated in a data processing layer of the server; the data access request comprises reading, updating or deleting data;

The interceptor invokes a rights check service; the authority checking service retrieves the preloaded authority rules in the distributed cache from a user session when running;

judging whether the requested data point is matched with the authority rule of the cache; if the data access request matches the user rights, access is allowed; if the result is not consistent, access is refused and corresponding error information or warning information is returned;

dynamically splicing the sphere condition of the SQL query according to the extracted authority rule at the data operation layer, wherein the sphere condition comprises the following steps:

Pre-configuring a permission rule model, wherein permission information of different roles is stored in the permission rule model;

After the user logs in successfully, analyzing the role of the user, and extracting corresponding authority rules from the authority configuration storage according to the role;

constructing a permission analyzer, wherein the analyzer dynamically constructs query conditions according to permission rules of a user;

Abstracting the authority rule into a template of a query condition;

Constructing a dynamic SQL generator, wherein the dynamic SQL generator dynamically generates SQL sentences according to templates provided by a permission analyzer and actual query requirements;

when SQL query is generated, combining a plurality of conditions, and optimizing the generated query statement;

when the right rule changes, updating and synchronizing the new right setting;

Writing the extracted authority setting data into a distributed cache, including:

Carrying out serialization processing on the authority setting data, and converting the authority setting data into SON character strings; generating a composite hash key value based on a role, a service entity and an operation type for each piece of authority setting data, wherein the hash key value is generated based on a role ID, a service domain ID and a service entity ID;

Fragmenting the authority setting data by adopting a consistent hash algorithm, and uniformly distributing the data to each cache node; data copies are reserved on different nodes so as to prevent data unavailability caused by single-point faults;

Embedding a version number and timestamp information in the permission setting data, and synchronously updating the version number when each permission rule is updated; when caching data, storing the version number and the last updating time together, and taking the version number and the last updating time as the judging basis of the data freshness; when inquiring the rights, judging whether the rights need to be reloaded or not by comparing the version information carried by the request with the version information in the cache;

Setting longer buffer expiration time for authority rules which are accessed frequently and changed infrequently; for the rights which are changed frequently, shortening the cache validity period and combining an active monitoring mechanism, and immediately notifying a cache system to update corresponding data once the background rights configuration is changed;

And when the authority setting data is written into the database, ensuring the atomicity of data writing operation and distributed cache updating operation through a distributed transaction mechanism.

3. An electronic device comprising a memory and a processor, the memory having stored thereon a computer program for loading and executing the method of claim 1 by the processor.

4. A computer readable storage medium, characterized in that a computer program is stored which can be loaded by a processor and which performs the method as claimed in claim 1.