Database access permission control method and device, computer device and storage medium

By carrying a tag mapping table field in the returned object of the interface, the problem of inflexible database access control is solved, enabling access control without modifying business code, thus reducing error rate and development costs.

CN119442267BActive Publication Date: 2026-03-31ZHEJIANG GEELY HLDG GRP CO LTD +1
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-10-21
Publication Date
2026-03-31

AI Technical Summary

Technical Problem

Existing technologies for database access control are not flexible enough, resulting in bloated code that is difficult to modify and cannot adapt to the flexible needs of different roles and permissions.

Method used

By carrying tags in the objects returned by the interface, and using the tags to map the relationship between object fields and table fields, the system intercepts target objects that have passed permission verification, obtains table columns, and filters columns that the user does not have permission to, thereby achieving access control.

Benefits of technology

It eliminates the need to write logic processing code in business logic, reducing error rates, lowering development costs, and enabling flexible control and easy maintenance of database access permissions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119442267B_ABST
    Figure CN119442267B_ABST
Patent Text Reader

Abstract

The application relates to a database access permission control method and device, computer equipment and a storage medium. The method comprises the following steps: receiving an access request initiated by a user, returning an object of an interface according to the access request, determining a target attribute carrying a label in the object, and the target attribute containing a mapping relationship between an object field and a table field; obtaining a permission role list of the table field according to the label and the mapping relationship, and performing permission verification on the permission role list of the table field; intercepting a target object passing the permission verification, and obtaining a table column pointed by an attribute of the target object; and returning data after filtering the table columns without access permission of the user. The method can realize flexible control of database access permission.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of databases, and in particular to a database access control method, apparatus, computer device, and storage medium. Background Technology

[0002] Databases are among a company's most important assets, containing a wealth of trade secrets and customer information. The leakage of critical data in a database can cause serious losses to the company. This confidential data is particularly critical to certain individuals in specific roles, so viewing permissions for data in the database (which may be the entire table or just certain columns) will vary depending on the role. Therefore, flexibly controlling access permissions to entire database tables or specific columns is crucial for improving database management efficiency.

[0003] Traditional methods involve handling logic based on different roles within the business logic code. However, this approach inevitably leads to bloated code, and modifications to data access permissions or the addition of roles may require code changes. Since certain fields in a table are accessed in many places, and these places use different APIs, a new set of logic processing code must be written for each new API.

[0004] Currently, no effective solution has been proposed to address the issue of insufficient flexibility in database access control in related technologies. Summary of the Invention

[0005] Therefore, it is necessary to provide a database access control method, apparatus, computer equipment, and storage medium that can flexibly control database access permissions in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a database access control method. The method includes:

[0007] Receive an access request initiated by a user, return an interface object based on the access request, and determine the target attribute carrying a tag in the object. The target attribute contains the mapping relationship between object fields and table fields.

[0008] The permission role list of the table field is obtained according to the tag and the mapping relationship, and the permission role list of the table field is verified.

[0009] Intercept the target object that passes the permission verification and obtain the table column pointed to by the attribute of the target object;

[0010] The data is returned after filtering out table columns that the user does not have access to.

[0011] In one embodiment, permission verification is performed on the permission role list of the table field, including:

[0012] Retrieve the list of permission roles for the configured sensitive fields;

[0013] Compare the list of permission roles for the table fields with the list of permission roles for the sensitive fields;

[0014] If every permission role in the permission role list of the table field exists in the permission role list of the sensitive field, then the permission verification is deemed to have passed; otherwise, the permission verification is deemed to have failed.

[0015] In one embodiment, obtaining the table column pointed to by the attribute of the target object includes:

[0016] The attributes of the target object are obtained using reflection. These attributes include ordinary field names, table names, and field names corresponding to the object fields carrying the tags.

[0017] In one embodiment, filtering table columns that the user does not have access to before returning data includes:

[0018] Obtain the user's permission roles based on the access request;

[0019] Query the table column access permissions corresponding to the table column stored in the cache;

[0020] Based on the user's permission role and the access permissions of the table columns, determine the table columns that the user does not have access to.

[0021] In one embodiment, prior to responding to a user-initiated access request, the method further includes:

[0022] Define a tag class, which includes table attributes and field attributes;

[0023] Create an entity class, and annotate the object fields in the entity class based on the tag class to map the object fields to the table fields.

[0024] In one embodiment, prior to responding to a user-initiated access request, the method further includes:

[0025] Create permission roles and configure the permission roles for the table fields in the database, generating a list of permission roles for sensitive fields.

[0026] Secondly, this application provides a database access control device, the device comprising:

[0027] The response module is used to receive access requests initiated by users, return an interface object according to the access request, and determine the target attribute carrying the tag in the object. The target attribute contains the mapping relationship between object fields and table fields.

[0028] The verification module is used to obtain the list of permission roles for the table field based on the tag and the mapping relationship, and to perform permission verification on the list of permission roles for the table field.

[0029] The interception module is used to intercept the target object that passes the permission verification and obtain the table column pointed to by the attribute of the target object;

[0030] The filtering module is used to filter table columns that the user does not have access to before returning data.

[0031] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect.

[0032] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0033] The aforementioned database access control method, device, computer equipment, and storage medium, through a newly added interface, return objects based on the interface. Some attributes of the object carry tags, which are used to map the relationship between object fields and table fields. Objects with tagged attributes are intercepted, the table columns pointed to by the attributes in the object are obtained, and data is returned after filtering out table columns that the user does not have access to. With this setup, flexible control of database access permissions can be achieved simply by tagging the table fields controlled by permission roles, without writing any business logic. Attached Figure Description

[0034] Figure 1 This is a hardware structure block diagram of a computer for a database access control method according to an embodiment of this application;

[0035] Figure 2 This is an application environment diagram of a database access control method in one embodiment;

[0036] Figure 3 This is a flowchart illustrating a database access control method in one embodiment;

[0037] Figure 4 This is a flowchart illustrating a database access control method in another embodiment;

[0038] Figure 5This is a flowchart illustrating a database access control method in another embodiment;

[0039] Figure 6 This is a structural block diagram of a database access control device in one embodiment;

[0040] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0042] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning as understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these,” used in this application, do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to such processes, methods, products, or devices. The terms “connected,” “linked,” and “coupled,” used in this application, are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. The term “multiple” used in this application refers to two or more. The "and / or" operator describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: A alone, A and B simultaneously, and B alone. Typically, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," and "third," etc., used in this application are merely for distinguishing similar objects and do not represent a specific ordering of the objects.

[0043] The method embodiments provided in this example can be executed in a computer or similar computing device. For example, running on a computer. Figure 1 This is a hardware block diagram of a computer for a database access control method according to an embodiment of this application. Figure 1 As shown, a computer may include one or more ( Figure 1Only one is shown in the diagram. A processor 101 and a memory 102 for storing data are also shown. The processor 101 may include, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The computer may also include a transmission device 103 for communication functions and an input / output device 104. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer described above. For example, the computer may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0044] The memory 102 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the database access control method in this embodiment. The processor 101 executes various functional applications and data processing by running the computer programs stored in the memory 102, thereby implementing the aforementioned method. The memory 102 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 102 may further include memory remotely located relative to the processor 101, and these remote memories can be connected to the computer via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0045] Transmission device 103 is used to receive or send data via a network. This network includes wireless networks provided by a computer's communication provider. In one example, transmission device 103 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, transmission device 103 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0046] The database access control method provided in this application embodiment can be applied to, for example, Figure 2 In the application environment shown, terminal 201 communicates with server 202 via a network. Data storage system 203 can store data that server 202 needs to process. Data storage system 203 can be integrated into server 202, or it can be placed in the cloud or on other network servers.

[0047] When server 202 receives an access request initiated by terminal 201 (user), server 202 will return an interface object according to the access request, and determine the target attribute carrying the tag in the object. The target attribute contains the mapping relationship between object fields and table fields. Server 202 obtains the permission role list of table fields according to the tag and mapping relationship, and performs permission verification on the permission role list of table fields. Server 202 intercepts the target object that passes the permission verification and obtains the table column pointed to by the attribute of the target object. Server 202 filters the table columns that the user does not have access to before returning the data to terminal 201.

[0048] The terminal 201 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle systems. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 202 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0049] The database query methods of related technologies intercept the SQL query, parse out the table columns, filter out columns with access permissions based on roles, and then reassemble the SQL. However, parsing and reassembling SQL requires writing code, which is prone to syntax errors and program failures. For SQL queries involving particularly complex multi-table joins, where the queried columns also involve multiple tables, it's tedious and error-prone to determine which table each column belongs to based on the parsed SQL. Furthermore, the parsing and assembly logic varies for different SQL queries, requiring developers to ensure their code supports a wide range of SQL types.

[0050] In response to the analysis of the above problems, in one embodiment, such as Figure 3 The diagram shows a flowchart of a database access control method, which is applied to... Figure 1 Taking a computer as an example, the explanation includes the following steps:

[0051] Step S101: Receive the access request initiated by the user, return the interface object according to the access request, and determine the target attribute carrying the tag in the object. The target attribute contains the mapping relationship between the object field and the table field.

[0052] The computer's query interface receives access requests from users, which contain business query information. Generally, this business query information can be a query for data from a specific table, column, or range. For example, to query the interests of male users in the `user` table of a database, a single SQL query can be written. The command is as follows:

[0053] SELECT interests

[0054] FROM user

[0055] WHERE sex='male';

[0056] In this step, the computer does not directly return the table column data queried by the user. Instead, it first returns the object of the (query) interface. This object contains multiple attributes, some of which carry tags and are considered target attributes. The target attribute contains the mapping relationship between the object fields and the table fields; that is, the target attribute points to a specific table column.

[0057] Step S102: Obtain the list of permission roles for the table fields based on the tags and mapping relationships, and perform permission verification on the list of permission roles for the table fields.

[0058] The computer determines the target attribute based on the label, and then, based on the table column pointed to by the target attribute, for table columns with configured access permissions, it can obtain the corresponding table field's permission roles, i.e., obtain the table field's permission role list. When performing permission verification on the table field's permission role list, it can first obtain the configured permission role list for sensitive fields; compare the table field's permission role list with the sensitive field's permission role list; if every permission role in the table field's permission role list also exists in the sensitive field's permission role list, the permission verification is considered successful; otherwise, the permission verification is considered unsuccessful. Optionally, the database administrator can add a configuration to the database of the maximum access permission role list for users with sensitive fields to prevent administrators from misconfiguring data permission roles, leading to sensitive data being viewed by unauthorized individuals.

[0059] Step S103: Intercept the target object that has passed the permission verification and obtain the table column pointed to by the attribute of the target object.

[0060] The computer treats objects that pass permission verification as target objects and intercepts them. Reflection can be used to obtain the attributes of the target object, including ordinary field names, the table name and field name corresponding to the tagged object fields, i.e., the table columns pointed to by the target attributes.

[0061] Step S104: Filter table columns that the user does not have access to before returning the data.

[0062] The computer can obtain the user's permission roles based on the access request; query the table column access permissions stored in the cache corresponding to the table columns; determine the table columns that the user does not have access to based on the user's permission roles and table column access permissions; filter out the table columns that the user does not have access to; and then return the remaining table column data to the user.

[0063] In steps S101 to S104 above, a new interface is added, and an object is returned based on the interface. Some attributes of the object carry tags. These tags are used to map the relationship between object fields and table fields. Objects with tagged attributes are intercepted, and the table columns pointed to by the attributes in the object are obtained. After filtering out table columns that the user does not have access to, the data is returned. With this setup, only table fields controlled by permission roles need to be tagged, and no business logic code needs to be written to achieve flexible control of database access permissions. Compared to intercepting SQL, this reduces the error rate and the development cost for developers who need to adapt to various complex SQL statements and write code to parse and assemble SQL statements.

[0064] In one embodiment, Figure 4 An alternative database access control method is provided, which includes the following steps before receiving access requests initiated by users:

[0065] Step S201: Create permission roles and configure permission roles for table fields in the database, generating a list of permission roles for sensitive fields.

[0066] For example, Table 1 shows the various permission roles, ranked from highest to lowest as Super Administrator, Administrator, and Regular Member. Table 2 shows the permission roles for each sensitive field. Gender and ID number, for example, have special permission roles configured, while the rest do not. This step can be configured in the management backend. Operations personnel can configure it according to business needs. Columns without configured permissions do not distinguish between permissions, and users with regular roles can also access them. After configuration, the configuration information can be stored in a Redis cache.

[0067] Table 1 Permission Roles

[0068] Permission Roles illustrate super Super Administrator admin administrator common ordinary members

[0069] Permission roles for sensitive fields in Table 2

[0070]

[0071] Step S202: Define a tag class, which includes table attributes and field attributes. An example is shown below:

[0072]

[0073] In the provided code snippet, `DataSourceAspect` is a custom annotation type with two properties: `table` and `field`. Both properties are of string type and have a default value of an empty string. When developers use this annotation in their code, they can specify a table name and a field name.

[0074] Step S203: Create entity classes and annotate the object fields in the entity classes based on tag classes to map the object fields to table fields. An example is shown below:

[0075]

[0076]

[0077] The provided code snippet defines a Java class named `UserVO` that implements the `Serializable` interface. The `UserVO` class contains four properties: `name`, `sex`, `idCard`, and `interest`, all of which are object fields. The `@DataSourceAspect` annotation is used to mark object fields that require access control and to specify their mapping in the database. Specifically, the `sex` and `idCard` fields use the `@DataSourceAspect` annotation to specify their correspondence with a particular database table column. For example, the `sex` object field maps to the `sex` column in the `user` database, and the `idCard` object field maps to the `id_card` column in the `user` database. Properties like `name` and `interest`, which are not annotated, indicate that these object fields do not require special access control and therefore do not need to be mapped to a specific database table column.

[0078] In this embodiment, when querying data from the database, the system can determine whether to return data for certain fields based on the user's permissions and the information provided by the `@DataSourceAspect` annotation. For example, if the user does not have permission to access the `id_card` column, the value of the `idCard` field will not be returned even if the `UserVO` object is queried. This method separates the permission control logic from the business logic, making permission control more flexible and easier to maintain. When it is necessary to adjust permissions or add new sensitive fields, only the annotation needs to be modified, without modifying the business code.

[0079] In one embodiment, when adding, deleting, or adjusting permission roles, roles can be added, deleted, or adjusted from an existing list of permission roles. Alternatively, when modifying the access permissions of a table column, the column with already configured access permissions can be directly modified. This setup requires only configuration changes, not code modifications, to affect all instances involving the table column.

[0080] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0081] In one embodiment, Figure 5 Another method for database access control is provided, which includes the following steps:

[0082] Step S301: Create permission roles and configure permission roles for database table fields, generating a list of permission roles for sensitive fields. For example, as shown in Table 1 above, create Level Administrator, Administrator, and Regular Member roles, and as shown in Table 2 above, configure special permission roles for sensitive fields.

[0083] Step S302: Define a tag class, which includes table attributes and field attributes; create an entity class, and annotate the object fields in the entity class based on the tag class to map the object fields to table fields. For example, as shown in the code snippet above, a custom annotation type is defined, and a Java class is defined to implement the new functional interface. The Java class contains multiple attributes, and tags are added to object fields that require access control, so that the object field corresponds to a column in the database table, indicating the mapping location of these object fields in the database.

[0084] Step S303: Receive the user's access request, return the interface object based on the access request, and determine the target attribute carrying the tag within the object. The target attribute contains the mapping relationship between object fields and table fields. The computer does not directly return the table column data queried by the user; instead, it first returns the (queried) interface object. These objects contain multiple attributes, some of which carry tags and are considered target attributes. The target attribute contains the mapping relationship between object fields and table fields; that is, the target attribute points to a specific table column.

[0085] Step S304: Obtain the list of permission roles for table fields based on tags and mapping relationships, and perform permission verification on the list of permission roles for table fields. The computer will determine the target attribute based on the tag, and then, based on the table column pointed to by the target attribute, for table columns with configured access permissions, obtain the corresponding table field's permission roles, thus obtaining the list of permission roles for the table field. When verifying the permission roles for table fields, the configured list of permission roles for sensitive fields can be obtained first; the list of permission roles for table fields and the list of permission roles for sensitive fields are compared; if every permission role in the list of permission roles for table fields exists in the list of permission roles for sensitive fields, the permission verification is considered successful; otherwise, the permission verification is considered unsuccessful. Optionally, the database administrator can add the configuration of the maximum access permission role list for people with sensitive fields to the database to prevent the administrator from misconfiguring the permission roles for the data, causing sensitive data to be seen by unauthorized personnel.

[0086] Step S305: Intercept the target object that passes the permission verification and obtain the table column pointed to by the target object's attributes. The computer treats the object that passes the permission verification as the target object and intercepts it. The attributes of the target object can be obtained using reflection. The attributes include ordinary field names, the table name and field name corresponding to the object field with the tag, that is, the table column pointed to by the target attribute.

[0087] Step S306: Filter table columns that the user does not have access to before returning the data. The computer can obtain the user's permission role based on the access request; query the table column access permissions stored in the cache corresponding to the table column; and determine the table columns that the user does not have access to based on the user's permission role and table column access permissions. After filtering out the table columns that the user does not have access to, the remaining table column data is returned to the user.

[0088] In steps S301 to S306 above, a new interface is added, and an object is returned based on the interface. Some attributes of the object carry tags. These tags are used to map the relationship between object fields and table fields. Objects with tag attributes are intercepted, and the table columns pointed to by the attributes in the object are obtained. After filtering out table columns that the user does not have access to, the data is returned. With this setting, only table fields controlled by permission roles need to be tagged, and no business code needs to be written to achieve flexible control of database access permissions. Compared with intercepting SQL, this can reduce the error rate and reduce the development cost for developers who need to adapt to various complex SQL statements and write code to parse and assemble SQL statements. When it is necessary to adjust permissions or add new sensitive fields, only the annotations and configurations need to be modified, without modifying the business code, and the changes will take effect in all places involving the table column. Specific examples in this embodiment can be referred to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0089] This embodiment also provides a database access control device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. The terms "module," "unit," and "subunit," etc., used below refer to combinations of software and / or hardware that perform a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0090] Figure 6 This is a structural block diagram of the database access control device in this embodiment, as shown below. Figure 6 As shown, the device includes: a response module 301, a verification module 302, an interception module 303, and a filtering module 304. The response module 301 receives access requests initiated by users, returns an interface object based on the access request, and determines a target attribute carrying a tag within the object. The target attribute includes a mapping relationship between object fields and table fields. The verification module 302 obtains a list of permission roles for the table fields based on the tag and mapping relationship, and performs permission verification on the list of permission roles for the table fields. The interception module 303 intercepts target objects that pass permission verification and obtains the table columns pointed to by the attributes of the target objects. The filtering module 304 filters table columns that the user does not have access to before returning data. It should be noted that specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0091] In one embodiment, the verification module 302 includes: an acquisition unit for acquiring a list of permission roles for a configured sensitive field; and a comparison unit for comparing the list of permission roles for the table field with the list of permission roles for the sensitive field; if every permission role in the list of permission roles for the table field exists in the list of permission roles for the sensitive field, then the permission verification is deemed to have passed; otherwise, the permission verification is deemed to have failed.

[0092] In one embodiment, the interception module 303 includes a reflection unit, used to obtain the attributes of the target object using a reflection mechanism. The attributes include ordinary field names, table names and field names corresponding to the object fields carrying tags.

[0093] In one embodiment, the filtering module 304 includes: an acquisition unit, configured to acquire the user's permission role based on the access request; a query unit, configured to query the table column access permissions stored in the cache corresponding to the table column; and to determine the table columns that the user does not have access to based on the user's permission role and the table column access permissions.

[0094] In one embodiment, the apparatus further includes a configuration module, which includes: a definition unit for defining a tag class, the tag class containing table attributes and field attributes; and a creation unit for creating an entity class, which annotates object fields in the entity class based on the tag class to map object fields to table fields.

[0095] In one embodiment, the configuration module further includes: a configuration unit for creating permission roles and configuring permission roles for table fields in the database, and generating a list of permission roles for sensitive fields.

[0096] The modules mentioned above can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented in hardware, the modules can reside in the same processor; or the modules can be located in different processors in any combination.

[0097] Furthermore, in conjunction with the database access control methods provided in the above embodiments, this embodiment can also provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the database access control methods described in the above embodiments.

[0098] In one embodiment, when a computer program is executed by a processor, it performs the following steps:

[0099] Receive access requests initiated by users, return an interface object based on the access request, and determine the target attribute carrying the tag in the object. The target attribute contains the mapping relationship between the object field and the table field.

[0100] Retrieve the list of permission roles for the table fields based on the tags and mapping relationships, and perform permission verification on the list of permission roles for the table fields.

[0101] Intercept the target object that passes the permission verification and obtain the table column pointed to by the target object's attribute;

[0102] Filter table columns that the user does not have access to before returning the data.

[0103] In one embodiment, when a computer program is executed by a processor, it performs the following steps:

[0104] Retrieve the list of permission roles for the configured sensitive fields;

[0105] Compare the list of permission roles for the table fields with the list of permission roles for the sensitive fields;

[0106] If every permission role in the permission role list of the table field exists in the permission role list of the sensitive field, then the permission verification is considered successful; otherwise, the permission verification is considered unsuccessful.

[0107] In one embodiment, when a computer program is executed by a processor, it performs the following steps:

[0108] The reflection mechanism is used to obtain the properties of the target object. The properties include ordinary field names, table names and field names corresponding to the object fields with tags.

[0109] In one embodiment, when a computer program is executed by a processor, it performs the following steps:

[0110] Obtain the user's permissions and roles based on the access request;

[0111] Query the table column access permissions stored in the cache corresponding to the table column;

[0112] Based on the user's permission roles and table column access permissions, determine the table columns that the user does not have access to.

[0113] In one embodiment, when a computer program is executed by a processor, it performs the following steps:

[0114] Define a tag class, which contains table attributes and field attributes;

[0115] Create entity classes and annotate the object fields in the entity classes based on the tag classes to map the object fields to the table fields.

[0116] In one embodiment, when a computer program is executed by a processor, it performs the following steps:

[0117] Create permission roles and configure permission roles for database table fields, generating a list of permission roles for sensitive fields.

[0118] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores table-based data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a database access control method.

[0119] Those skilled in the art will understand that Figure 7The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0120] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0121] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0122] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0123] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A database access authority control method characterized by comprising: The method comprises the following steps: receiving a user-initiated access request, returning an object of an entity class of an interface according to the access request, and determining a target attribute carrying a label in the object, the target attribute containing a mapping relationship between an object field and a table field, the label being defined based on a custom annotation; obtaining a permission role list of the table field according to the label and the mapping relationship, and performing permission verification on the permission role list of the table field; intercepting a target object passing the permission verification, and obtaining a table column pointed to by an attribute of the target object; returning data after filtering a table column without access permission of the user.

2. The database access authority control method according to claim 1, characterized by, The permission verification on the permission role list of the table field comprises the following steps: obtaining a permission role list of a configured sensitive field; comparing the permission role list of the table field with the permission role list of the sensitive field; if each permission role in the permission role list of the table field exists in the permission role list of the sensitive field, it is determined that the permission verification is passed; otherwise, it is determined that the permission verification is not passed.

3. The database access authority control method according to claim 1, characterized by, The obtaining of the table column pointed to by the attribute of the target object comprises the following steps: obtaining the attribute of the target object by using a reflection mechanism, the attribute including a normal field name, a table name corresponding to an object field carrying the label, and a field name.

4. The database access authority control method according to claim 1, characterized by, The returning of data after filtering the table column without access permission of the user comprises the following steps: obtaining a permission role of the user according to the access request; querying a table column access permission corresponding to the table column saved in a cache; determining a table column without access permission of the user according to the permission role of the user and the table column access permission.

5. The database access authority control method according to Claim 1, characterized by, Before responding to the user-initiated access request, the method further comprises the following steps: defining a label class, the label class containing a table attribute and a field attribute; creating an entity class, and annotating the object field in the entity class based on the label class to map the object field and the table field.

6. The database access authority control method according to Claim 1, characterized by Before responding to the user-initiated access request, the method further comprises the following steps: creating a permission role, and configuring the permission role for a table field of a database to generate a permission role list of a sensitive field.

7. A database access authority control device characterized by comprising: The apparatus comprises: a response module, configured to receive a user-initiated access request, return an object of an entity class of an interface according to the access request, and determine a target attribute carrying a label in the object, the target attribute containing a mapping relationship between an object field and a table field, the label being defined based on a custom annotation; a verification module, configured to obtain a permission role list of the table field according to the label and the mapping relationship, and perform permission verification on the permission role list of the table field; an interception module, configured to intercept a target object passing the permission verification, and obtain a table column pointed to by an attribute of the target object; a filtering module, configured to return data after filtering a table column without access permission of the user.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the database access in any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program, which is executed by a processor, implements the steps of database access of any of claims 1 to 6.

Citation Information

Patent Citations

  • Method and system for controlling data access right

    CN102063479A

  • Data authority management method and device for business system

    CN118153090A