Data operation authority management and control method and device, electronic equipment and storage medium

Abstract

The invention provides a data operation authority management and control method and device, electronic equipment and a storage medium. The method comprises the steps of obtaining a function tag matched with a to-be-operated object; splitting the function label into a plurality of atomic operation permissions, and performing permission hydration on the plurality of atomic operation permissions, a first baseline permission of the data model and a second baseline permission of the metadata according to a preset permission hydration strategy to obtain a final snapshot of the atomic operation permissions; serializing, signing and compressing the snapshots through a rear end to generate a model-level token and an instance-level token; sending the snapshot, the model-level token and the instance-level token to a front end, determining a token corresponding to the target operation, and sending the token to a rear end for verification; and under the condition that the token is successfully verified, performing interface rendering on the user interface according to the target data model and the execution operation result of the target instance. The operation and maintenance cost of authority management can be reduced, the validity of authority management is improved, and front-end and back-end integration is realized.

Description

Technical Field

[0001] This application relates to the fields of data security, access control and permission management technology, and in particular to a data operation permission management method, device, electronic device and storage medium. Background Technology

[0002] Current mainstream access control solutions generally face the following technical problems that urgently need to be solved in practical applications. These problems not only reduce the effectiveness of access control but also cause security risks and operational burdens: 1. Insufficient granularity: lack of data model / instance / attribute-level atomic operation permissions and consistent execution basis across layers; 2. Fragmented implementation: hard-coding of explicit and implicit permissions on the front end and interception of authentication on the back end lead to inconsistent execution and security risks; 3. Configuration / maintenance burden: traditional implementations often require code modification to change permissions, resulting in slow changes and high regression risks.

[0003] Therefore, a new method for managing data operation permissions is urgently needed to solve the above problems. Summary of the Invention

[0004] In view of this, this application provides a data operation permission control method, apparatus, electronic device and storage medium, which can reduce the operation and maintenance cost of permission management and improve the effectiveness of permission management.

[0005] The first aspect of this application provides a data operation permission control method, comprising: acquiring at least one function tag matching an object to be operated on, wherein each function tag is a minimum authorization unit composed of multiple atomic operation permissions of multiple data models, used to characterize the operation permission of the object to be operated on to instances and attributes in the data models; splitting each function tag into multiple atomic operation permissions, and performing permission hydration on the multiple atomic operation permissions, a preset first baseline permission of the data models, and a second baseline permission of the metadata according to a preset permission hydration strategy to obtain a snapshot of the final atomic operation permissions after hydration; and performing serialization, signing, and compression processing on the snapshot through a backend to generate a model-level token and an instance-level token, wherein the model-level token carries the operation permission on the data models, and the instance-level token carries the operation permission on the data models. An instance-level token carries operation permissions for each instance in the data model. The snapshot, the model-level token, and the instance-level token are sent to the front-end. The front-end renders the front-end user interface components using the atomic operation permissions in the snapshot, model-level token, and instance-level token. After the target object performs a target operation on the front-end user interface components, the front-end determines the token corresponding to the target operation and sends the token to the back-end for verification. If the back-end successfully verifies the token, it performs operations on the target data model and target instance corresponding to the token according to the final atomic operation permission, and returns the result of the operation to the front-end user interface for rendering. After rendering, the functions in the user interface corresponding to the final atomic operation permission are operable.

[0006] In one possible implementation, the function tags include multiple ones; the step of splitting the function tags into multiple atomic operation permissions includes: splitting each function tag into a new permission corresponding to the data model, a delete permission corresponding to the instance, an edit permission corresponding to the attribute, and a view permission; the step of performing permission hydration on the multiple atomic operation permissions, the preset first baseline permission of the data model, and the second baseline permission of the metadata according to a preset permission hydration strategy includes: combining the first baseline permission and the second baseline permission with the atomic operation permissions obtained after splitting each function tag, and merging permissions according to the combination result.

[0007] In one possible implementation, the second baseline permission includes data visibility and data invisibility; the step of performing permission hydration on multiple atomic operation permissions, the first baseline permission of the preset data model, and the second baseline permission of the metadata according to a preset permission hydration strategy to obtain a snapshot of the final atomic operation permission after hydration includes: detecting whether the instance corresponding to the function tag is in the current data model; if the instance corresponding to the function tag is not detected in the current data model, determining the type of the second baseline permission; if the type of the second baseline permission is data visibility, setting the final atomic operation permission to view only; if the type of the second baseline permission is data invisibility, setting the final atomic operation permission to no permission.

[0008] In one possible implementation, the first baseline permission includes data editability, data visibility, and data invisibility; the atomic operation permission includes instance-level permission of the instance corresponding to the function tag and attribute-level permission of the attributes in the instance, wherein the instance-level permission includes display conditions, editing conditions, deletion conditions, and whether new additions are allowed, and the attribute-level permission includes visible editing, anonymized editing, invisible editing, visible, anonymized, and invisible; when it is detected that the instance corresponding to the function tag is in the current data model, the method further includes: determining the type of the first baseline permission; if the type of the first baseline permission is data editability, setting the final atomic operation permission to have all operation permissions; if the type of the first baseline permission is data visibility, setting the display condition in the instance-level permission to null and the invisible attribute in the attribute permission to null, and then merging multiple atomic operation permissions according to the maximum permission priority merging strategy; if the type of the first baseline permission is data invisibility, merging multiple atomic operation permissions according to the maximum permission priority merging strategy.

[0009] In one possible implementation, merging multiple atomic operation permissions according to the maximum permission priority merging strategy includes: obtaining a set of editable attributes based on the atomic operation permissions corresponding to the editing conditions hit by the data; if all attributes in the hit atomic operation permissions are desensitized and uneditable, setting the attribute as a desensitized attribute; if all attributes in the hit atomic operation permissions are invisible, setting the attribute as an invisible attribute, and setting other attributes as visible attributes; if any one of the multiple atomic operation permissions is satisfied as a deletion condition, then the final atomic operation permissions include deletable; if any one of the multiple atomic operation permissions is addable, then the final atomic operation permissions include addable.

[0010] In one possible implementation, the backend verifies the token by: verifying whether the token's signature is valid, whether the token has expired, whether the token is bound to the object to be operated on, whether the token is bound to the current instance, and whether the token's permission record has been tampered with; if the token's signature is valid, the token has not expired, the token is bound to the object to be operated on, the token is bound to the current instance, and the token's permission record has not been tampered with, then permission information is obtained from the token; the token is then subjected to secondary verification based on the permission information, and if the secondary verification is successful, the token verification is considered successful; if the token is found to have at least one of the following conditions: invalid signature, expired, not bound to the object to be operated on, not bound to the current instance, or permission record tampered with, then the backend fails to verify the token.

[0011] In one possible implementation, the token includes a target model-level token and a target instance-level token; the secondary verification of the token based on the permission information includes: parsing whether the target model-level token has permission to add new tokens based on the permission information; reading the editable attributes of the target instance-level token, removing non-editable attributes from the target instance-level token when the editable attributes are read, and setting the permissions of the target instance-level token to non-editable when the editable attributes are not read; and parsing whether the target instance-level token has permission to delete tokens based on the permission information.

[0012] Secondly, embodiments of this application also provide a data operation permission control device, including: an acquisition module, a splitting module, a merging module, a backend processing module, and a frontend processing module; the acquisition module is used to acquire at least one functional tag matching the object to be operated on, wherein each functional tag is a minimum authorization unit composed of multiple atomic operation permissions of multiple data models, used to characterize the operation permission of the object to be operated on to instances and attributes in the data models; the splitting module is used to split each functional tag into multiple atomic operation permissions; the merging module is used to perform permission hydration on the multiple atomic operation permissions, the preset first baseline permissions of the data models, and the second baseline permissions of the metadata according to a preset permission hydration strategy, to obtain a snapshot of the final atomic operation permissions after hydration; the backend processing module is used to serialize, sign, and compress the snapshot to generate model-level tokens and instance-level tokens, wherein... The model-level token carries operation permissions for the data model, and the instance-level token carries operation permissions for each row of data in the data table. The backend processing module is further configured to send the snapshot, the model-level token, and the instance-level token to the frontend processing module. The frontend processing module renders the frontend user interface components using the atomic operation permissions in the snapshot, the model-level token, and the instance-level token. After the object to be operated performs a target operation on the frontend user interface components, the frontend determines the token corresponding to the target operation and sends the token to the backend for verification. If the backend processing module successfully verifies the token, the backend processing module is further configured to perform operations on the target data model and target instance corresponding to the token according to the final atomic operation permissions. The frontend processing module is further configured to render the frontend user interface based on the result of the operation. After the user interface is rendered, the functions in the user interface corresponding to the final atomic operation permissions are operable.

[0013] Thirdly, embodiments of this application also provide an electronic device, the electronic device including a processor and a memory, the memory being used to store instructions, and the processor being used to call the instructions in the memory, causing the electronic device to execute the data operation permission control method as described in the first aspect.

[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium that stores computer instructions that, when executed on an electronic device, cause the electronic device to perform the data operation permission control method as described in the first aspect.

[0015] Compared with related technologies, the embodiments of this application have at least the following advantages: By splitting functional tags into multiple atomic operation permissions, and performing permission hydration on multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of metadata according to a preset permission hydration strategy, a snapshot of the final atomic operation permissions after hydration is obtained. Since the user interface of the front end will be rendered based on the final atomic operation permissions in subsequent steps, permission configuration changes only require adjusting the configuration and generating a new snapshot of the hydration permissions and sending it to the front end. The front end / back end executes according to the snapshot without modifying or redeploying the business code, fundamentally eliminating the "change of permissions requires code modification" operational curse, significantly reducing the cost of permission changes and shortening the compliance response time, thereby reducing the operational cost of permission management. In addition, by serializing, signing, and compressing the snapshot on the back end to generate model-level tokens and instance-level tokens, the front end determines the token corresponding to the target operation and sends the token to the back end for verification, effectively avoiding the phenomenon of "front end hard-coding for explicit and implicit permissions, back end intercepting for authentication," ensuring the consistency of front end and back end execution, thereby improving the effectiveness of permission management and realizing front end and back end integration.

[0016] The technical effects achieved by the second, third, and fourth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect, and will not be repeated here. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the steps of a data operation permission control method provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the permission descriptions of atomic operation permissions, first baseline permissions, and second baseline permissions provided in an embodiment of this application; Figure 3 A flowchart for determining the final atomic operation authority is provided as an embodiment of this application; Figure 4 Another flowchart of the data operation permission control method provided in an embodiment of this application; Figure 5 A flowchart illustrating the generation process of a functional label provided in an embodiment of this application; Figure 6 A schematic diagram illustrating the interaction process between the front-end and back-end provided in an embodiment of this application; Figure 7 A functional block diagram of a data operation permission control device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To better understand the above-mentioned objectives, features, and advantages of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0019] The following description sets forth many specific details to provide a full understanding of this application. The described embodiments are only some, not all, of the embodiments of this application.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

[0021] It should be further noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0022] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects, not to describe a specific order or sequence.

[0023] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0024] For ease of understanding, exemplary descriptions of some concepts related to the embodiments of this application are provided for reference.

[0025] Atomic operation permissions: Permission units that control the execution of specific operations on resources, with the smallest granularity being a data model, instance, or attribute.

[0026] Functional tags: Combinations of multiple atomic operation permissions, which are assigned to users, roles, and positions as authorization units.

[0027] Permission hydration: Expand function tabs, application baseline, detect and merge conflicts (maximum permissions take precedence), and generate a hydration permission snapshot.

[0028] Snapshot tokens: Support self-contained token mode, signature, compression, sharding and incremental differential updates, and token_version revocation policy.

[0029] Data model: refers to a unit of data resources that can be authorized, equivalent to a database table, API resource, or microservice object.

[0030] Example: Refers to a specific data item in the data model, equivalent to a database row, API response object, or data record in a microservice.

[0031] Attributes: refer to controllable fields or parameters in an instance, equivalent to database fields, API parameters, or object properties.

[0032] Snapshot token revocation bit: Used to implement the version number or blacklist reference for token revocation.

[0033] Action context: Parameterized information, source path, and behavior sequence summary related to atomic operation permissions.

[0034] Decoupling permissions from code: This means that changes to permission policies are only generated by configuration (feature tags / mappings / baselines) to create a new snapshot and distribute it to the execution end. The execution end runs according to the snapshot without modifying the business implementation code.

[0035] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating one embodiment of the data operation permission control method of this application. Depending on different needs, the order of steps in this flowchart can be changed, and some steps can be omitted.

[0036] It should be noted that the data operation permission control method of this application embodiment can be applied to scenarios involving user operation permission control of data tables. The executing entity can be a data operation permission control device. For example, the data operation permission control device can determine the data table operation permissions matching the user and display the user's operable permissions on the front-end user interface. Of course, the data operation permission control method of this application embodiment can also be applied to other scenarios requiring data operation permission control, and this application does not specifically limit its application in this regard.

[0037] The specific process of this embodiment is as follows: Figure 1 As shown, it includes the following steps: S101, obtain at least one function tag that matches the object to be operated on, wherein each function tag is the smallest authorization unit composed of multiple atomic operation permissions of multiple data models, used to characterize the operation permissions of the object to be operated on to instances and attributes in the data models.

[0038] In some embodiments, the objects to be operated on include, but are not limited to, departments, positions, roles, users, hosts, etc. This embodiment does not specifically limit the type of objects to be operated on.

[0039] In some embodiments, the data model includes, but is not limited to, data tables, views, interfaces, dictionaries, etc. This embodiment does not specifically limit the type of data model.

[0040] It is understandable that an instance is the data in the data model. Taking a data table as an example, an instance is each row of data in the data table.

[0041] In some embodiments, each business function is tagged, generating function tags and assigning them to different objects.

[0042] The method for determining the function labels is described in detail in subsequent embodiments, and will not be repeated here to avoid repetition.

[0043] S102 breaks down each function tag into multiple atomic operation permissions.

[0044] In some embodiments, the function tag is split into multiple atomic operation permissions, including: splitting the function tag into the add permission corresponding to the data model, the delete permission corresponding to the instance, the edit permission corresponding to the attribute, and the view permission.

[0045] It should be noted that the attributes in this embodiment are the fields in the example.

[0046] It should also be noted that, since the function label in this embodiment is the smallest authorized unit composed of multiple atomic operation permissions of multiple data models, when the function label is split, each data model corresponding to the function label will be split into multiple atomic operation permissions.

[0047] S103, according to the preset permission hydration strategy, perform permission hydration on multiple atomic operation permissions, the first baseline permission of the preset data model and the second baseline permission of the metadata, and obtain a snapshot of the final atomic operation permissions after hydration.

[0048] Specifically, the process of watering multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of the metadata according to the preset permission watering strategy includes first watering multiple atomic operation permissions, the first baseline permissions, and the second baseline permissions, and then watering based on the results of the watering and permission conflict detection.

[0049] More specifically, the process of "watering" multiple atomic operation permissions, the first baseline permission, and the second baseline permission includes: combining the first baseline permission and the second baseline permission with the atomic operation permissions obtained after splitting each of the function tags; and the process of "merging" based on permission conflict detection based on the result of the "watering" is the permission merging based on the result of the combination.

[0050] The following is a detailed explanation of how this embodiment performs "merging" based on permission conflict detection, using the results of "water": In some embodiments, the second baseline permissions for metadata include data visibility and data invisibility; the permissions of multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of the metadata are hydrated according to a preset permission hydration strategy to obtain a snapshot of the final atomic operation permissions after hydration, including: detecting whether the instance corresponding to the function tag is in the current data model; if the instance corresponding to the function tag is not detected in the current data model, determining the type of the second baseline permission; if the type of the second baseline permission is data visibility, setting the final atomic operation permission to view only; if the type of the second baseline permission is data invisibility, setting the final atomic operation permission to no permission.

[0051] In some embodiments, the first baseline permissions include data editability, data visibility, and data invisibility; atomic operation permissions include instance-level permissions for the instance corresponding to the function tag and attribute-level permissions for the attributes in the instance, wherein instance-level permissions include display conditions, edit conditions, delete conditions, and whether new additions are allowed, and attribute-level permissions include editability, visibility, desensitization, and invisibility; when an instance corresponding to the function tag is detected in the current data model, the method further includes: determining the type of the first baseline permission; if the type of the first baseline permission is data editability, setting the final atomic operation permission to have all operation permissions; if the type of the first baseline permission is data visibility, setting the display condition in the instance-level permissions to null and the invisible attribute in the attribute permissions to null, and then merging multiple atomic operation permissions according to the maximum permission priority merging strategy; if the type of the first baseline permission is data invisibility, merging multiple atomic operation permissions according to the maximum permission priority merging strategy.

[0052] In some embodiments, merging multiple atomic operation permissions according to the maximum permission priority merging strategy includes: obtaining a set of editable attributes based on the atomic operation permissions corresponding to the editing conditions hit by the data; if all attributes in the hit atomic operation permissions are desensitized and uneditable, setting the attribute as a desensitized attribute; if all attributes in the hit atomic operation permissions are invisible, setting the attribute as an invisible attribute, and setting other attributes as visible attributes; if any one of the multiple atomic operation permissions is satisfied as a deletion condition, then the final atomic operation permissions include deletability; if any one of the multiple atomic operation permissions is allowed to be added, then the final atomic operation permissions include addition capability.

[0053] To facilitate understanding, the following will be combined with... Figure 2 and Figure 3 This embodiment provides a detailed explanation of how to obtain a snapshot of the final atomic operation permissions after hydration: Please refer to Figure 2 This is a schematic diagram illustrating the permission descriptions of atomic operation permissions, first baseline permissions, and second baseline permissions provided in the embodiments of this application.

[0054] Specifically, atomic operation permissions are... Figure 2 The permissions corresponding to the function labels shown include instance-level permissions and attribute-level permissions. Instance-level permissions include display conditions, editing conditions, deletion conditions, and whether new items can be added. Attribute-level permissions include visible editing, anonymized editing, invisible editing, visible, anonymized, and invisible. The first baseline permission is... Figure 2 The data model baseline shown includes visible (model default function), visible (automatic desensitization), and invisible (function label). Visible (model default function) means all data models in the data model set are editable; visible (automatic desensitization) means automatically desensitized according to the set desensitization rules and can be viewed; invisible (function label) means the data model is not viewable and is entirely based on matching function labels. The second baseline permissions include visible (automatic desensitization) and invisible (…). Figure 2 (Not shown), but can be seen (automatic desensitization), which means that the desensitization is automatically performed according to the set desensitization rules and can be viewed.

[0055] Please refer to Figure 3 This is a flowchart illustrating the determination of final atomic operation permissions provided in an embodiment of this application. From... Figure 3As can be seen, when the first baseline permission type is "data visible," after setting the display condition in the instance-level permission and the invisible attribute in the attribute permission to "empty," the display condition corresponding to the opcode is merged into the original query conditions of the page. Data is then queried, and the edit / delete conditions matching the data are obtained. Finally, multiple atomic operation permissions are merged according to the maximum permission priority merging strategy. Similarly, when the first baseline permission type is "data invisible," the display condition corresponding to the opcode is merged into the original query conditions of the page. Data is then queried, and the edit / delete conditions matching the data are obtained. Finally, multiple atomic operation permissions are merged according to the maximum permission priority merging strategy.

[0056] S104 serializes, signs, and compresses snapshots through the backend to generate model-level tokens and instance-level tokens.

[0057] Specifically, model-level tokens carry operation permissions for the data model, while instance-level tokens carry operation permissions for each instance in the data model.

[0058] S105, the snapshot, model-level token and instance-level token are sent to the front end. The front end renders the front-end user interface components through the atomic operation permissions in the snapshot, model-level token and instance-level token. After the object to be operated performs the target operation on the front-end user interface component, the front end determines the token corresponding to the target operation and sends the token to the back end for verification.

[0059] S106: If the token is successfully verified on the backend, the target data model and target instance corresponding to the token are executed according to the final atomic operation permission, and the result of the execution operation is returned to the frontend user interface for interface rendering.

[0060] Specifically, after the user interface is rendered, the functions in the user interface corresponding to the final atomic operation permissions become operable.

[0061] It should be noted that how the backend verifies the token is described in detail in subsequent embodiments, and will not be repeated here to avoid repetition.

[0062] The following is a detailed explanation of how permission changes are implemented in this embodiment: Background: The security compliance team needs to restrict the default viewing permissions for certain attributes.

[0063] Operation steps: The security team adjusts the function tag mapping and data model / attribute baseline on the permission management platform, and the permission hydration module generates a new hydration permission snapshot (version X); the snapshot is signed and published as a new snapshot token or distributed as a differential shard; each execution terminal does not need to modify the code, but only executes the authentication and de-identification logic according to the new snapshot after receiving or pulling the new version snapshot.

[0064] Results: The time for permission policies to take effect is shortened from the traditional "code change - test - release" cycle (days / weeks) to "configuration change - snapshot issuance - immediate / near real-time effect" (minutes / hours), without triggering the CI / CD process, reducing regression risk and maintaining the stability of business code.

[0065] Compared with related technologies, the embodiments of this application have at least the following advantages: By splitting functional tags into multiple atomic operation permissions, and performing permission hydration on multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of metadata according to a preset permission hydration strategy, a snapshot of the final atomic operation permissions after hydration is obtained. Since the user interface of the front end will be rendered based on the final atomic operation permissions in subsequent steps, permission configuration changes only require adjusting the configuration and generating a new snapshot of the hydration permissions and sending it to the front end. The front end / back end executes according to the snapshot without modifying or redeploying the business code, fundamentally eliminating the "change of permissions requires code modification" operational curse, significantly reducing the cost of permission changes and shortening the compliance response time, thereby reducing the operational cost of permission management. In addition, by serializing and compressing the snapshot on the back end to generate model-level tokens and instance-level tokens, the front end determines the token corresponding to the target operation and sends the token to the back end for verification, effectively avoiding the phenomenon of "front end hard-coding for visibility and back end intercepting for authentication", ensuring the consistency of front end and back end execution, thereby improving the effectiveness of permission management and realizing front end and back end integration.

[0066] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating one embodiment of the data operation permission control method of this application. Depending on different needs, the order of the steps in this flowchart can be changed, and some steps can be omitted. This data operation permission control method can be applied to the aforementioned data operation permission control device, but is not limited thereto, and this application embodiment does not limit it in this regard.

[0067] This embodiment provides a detailed description of the foregoing embodiments, primarily illustrating how data queries are performed in the enumeration table and the user table. This approach further improves the query performance for composite enumeration data.

[0068] The specific process of this embodiment is as follows: Figure 4 As shown, it includes the following steps: S401, obtain at least one function tag that matches the object to be operated on, wherein each function tag is the smallest authorized unit composed of multiple atomic operation permissions of multiple data models, used to characterize the operation permissions of the object to be operated on to instances and attributes in the data models.

[0069] To facilitate understanding, the following will be combined with... Figure 5 The method for obtaining the function tags in this embodiment will be described in detail below: Please refer to Figure 5 This is a flowchart illustrating the generation process of functional tags provided in this application embodiment. Specifically, firstly, a first baseline permission for the data model is defined, including but not limited to data editability, data visibility, and data invisibility; then, the scope of instances in the data model is restricted, including but not limited to instances being displayable, editable, and deletable; next, permissions are set for attributes in the instances, including but not limited to visible editing, anonymized editing, invisible editing, visible, anonymized, and invisible; finally, functional tags are determined based on the set first baseline permissions, instance restriction scope, and attribute setting permissions. It can be understood that a functional tag is the smallest business authorization unit.

[0070] S402 breaks down function tags into multiple atomic operation permissions.

[0071] S403, according to the preset permission hydration strategy, perform permission hydration on multiple atomic operation permissions, the first baseline permission of the preset data model and the second baseline permission of the metadata, and obtain a snapshot of the final atomic operation permissions after hydration.

[0072] S404 uses a backend to serialize, sign, and compress snapshots to generate model-level tokens and instance-level tokens.

[0073] S405 sends the snapshot, model-level token, and instance-level token to the front end. The front end renders the front-end user interface components using the atomic operation permissions in the snapshot, model-level token, and instance-level token. After the object to be operated performs the target operation on the front-end user interface component, the front end determines the token corresponding to the target operation and sends the token to the back end for verification.

[0074] S401 to S405 in this embodiment are similar to S101 to S105 in the previous embodiment. To avoid repetition, they will not be described again here.

[0075] S406 verifies whether the token's signature is valid, whether the token has expired, whether the token is bound to the object to be operated on, whether the token is bound to the current instance, and whether the token's permission record has been tampered with.

[0076] S407: If the token signature is found to be valid, the token has not expired, the token is bound to the object to be operated on, the token is bound to the current instance, and the token's permission record has not been tampered with, then the permission information is obtained from the token; the token is then verified a second time based on the permission information; if the second verification is successful, the token verification is considered successful.

[0077] In some embodiments, the token includes a target model-level token and a target instance-level token; the token is further verified based on permission information, including: parsing whether the target model-level token has permission to add; reading the editable attributes of the target instance-level token, removing the non-editable attributes from the target instance-level token when an editable attribute is read, and setting the permissions of the target instance-level token to non-editable when no editable attribute is read; and parsing whether the target instance-level token has permission to delete based on permission information.

[0078] S408 renders the front-end user interface based on the final atomic operation permissions.

[0079] To facilitate understanding, the following will be combined with... Figure 6 The interaction process between the front-end and back-end in this application embodiment, how the back-end verifies the token, and how the front-end renders the user interface are described in detail: Please refer to Figure 6 This is a schematic diagram of the interaction process between the front-end and back-end provided in the embodiments of this application.

[0080] Specifically, the front end sends the FormKey (form ID), TableName (name of the data table to be operated on), Filter (filtering conditions of the data table), and InputParams (parameters to be modified) to the back end, and the back end outputs the parameter modification results. It can be understood that the back end returns a snapshot to the front end, which carries the parameter modification results, model-level tokens, and instance-level tokens.

[0081] More specifically, the front-end user interface renders UI components based on snapshots sent by the back-end. For example, input: the user has function tags {Customer Management, Order Management}, the baseline of the "Customer" data model layer is: read-only + automatic anonymization, and the mobile phone number is visible by default in the attribute layer; expansion and merging: the tags are expanded into atomic operation permissions, and if a conflict is detected between "Customer Editing" and the data model baseline, explicit rejection is used to prioritize retaining read-only; snapshot generation: a watered-down permission snapshot is formed {Customer Viewing (Anonymized), Order Deletion Allowed}; front-end rendering: customer details (anonymized attributes) are displayed, and the edit button is hidden; the order list displays the delete button; back-end execution: interface authentication is based on the snapshot; the returned data is anonymized for the mobile phone number, and customer editing operations are rejected; persistence layer: the ID number is encrypted and stored according to metadata; soft deletion is implemented through logical tags.

[0082] S409: The backend fails to verify the token if it is found that the token is invalid, expired, not bound to the object to be operated on, not bound to the current instance, or the permission record has been tampered with.

[0083] For ease of understanding, the snapshot token mechanism of this embodiment will be explained in detail below: Issuance: The backend generates a hydrated snapshot, which supports dictionary encoding, compression, and signing.

[0084] Carry: The front end sends the token with the request header, and the back end returns a complete snapshot as needed after verification.

[0085] Signature verification and revocation: The backend verifies the signature. If the signature does not match, it rejects the application and triggers an audit.

[0086] In some embodiments, a persistence layer is also included, which is driven by metadata for soft deletion and attribute encryption, and extends to data source connections, data operations, data model objects and metadata governance permissions, supporting the implementation of application-layer pre-verification and other features.

[0087] For ease of understanding, the following is a detailed explanation of the extended permission control of the persistence layer in this embodiment: Application layer pre-verification: Snapshot verification and operation verification are performed at the business gateway / service layer, which is suitable for most cloud-native scenarios.

[0088] DB Proxy: Adds a proxy at the data source connection layer to intercept requests or operations and execute instance / property-level policies on a snapshot basis, preventing bypassing the application.

[0089] Storage control (RLS / triggers): Use RLS policies or triggers on supported storage systems as a last line of defense, combined with metadata synchronization to achieve attribute-level encryption and soft deletion.

[0090] Recommendation: Adopt a layered protection strategy of "application layer pre-verification + DB Proxy (optional) + storage internal control (for high compliance scenarios)".

[0091] Compared with related technologies, the embodiments of this application have at least the following advantages: By splitting functional tags into multiple atomic operation permissions, and performing permission hydration on multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of metadata according to a preset permission hydration strategy, a snapshot of the final atomic operation permissions after hydration is obtained. Since the user interface of the front end will be rendered based on the final atomic operation permissions in subsequent steps, permission configuration changes only require adjusting the configuration and generating a new snapshot of the hydration permissions and sending it to the front end. The front end / back end executes according to the snapshot without modifying or redeploying the business code, fundamentally eliminating the "change of permissions requires code modification" operational curse, significantly reducing the cost of permission changes and shortening the compliance response time, thereby reducing the operational cost of permission management. In addition, by serializing and compressing the snapshot on the back end to generate model-level tokens and instance-level tokens, the front end determines the token corresponding to the target operation and sends the token to the back end for verification, effectively avoiding the phenomenon of "front end hard-coding for visibility and back end intercepting for authentication", ensuring the consistency of front end and back end execution, thereby improving the effectiveness of permission management.

[0092] Based on the same idea as the data operation permission control method in the above embodiments, this application also provides a data operation permission control device, which can be used to execute the above data operation permission control method. For ease of explanation, the structural diagram of the data operation permission control device embodiment only shows the parts related to the embodiments of this application. Those skilled in the art will understand that the illustrated structure does not constitute a limitation on the device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0093] like Figure 7 As shown, the data operation permission control device 70 includes an acquisition module 701, a splitting module 702, a merging module 703, a backend processing module 704, and a frontend processing module 705. In some embodiments, the above modules can be programmable software instructions stored in memory and executable by a processor. It is understood that in other embodiments, the above modules can also be program instructions or firmware embedded in the processor.

[0094] The acquisition module 701 is used to acquire at least one function tag that matches the object to be operated on, wherein each function tag is the smallest authorization unit composed of multiple atomic operation permissions of multiple data models, and is used to characterize the operation permissions of the object to be operated on to instances and attributes in the data models. Split module 702 is used to split function tags into multiple atomic operation permissions; The merging module 703 is used to perform permission hydration on multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of the metadata according to a preset permission hydration strategy, so as to obtain a snapshot of the final atomic operation permissions after hydration. The backend processing module 704 is used to serialize, sign and compress the snapshot, and generate model-level tokens and instance-level tokens. The model-level token carries the operation permissions for the data model, and the instance-level token carries the operation permissions for each instance in the data model. Backend processing module 704 is also used to send snapshots, model-level tokens and instance-level tokens to frontend processing module 705; The front-end processing module 705 is used to render the front-end user interface components through atomic operation permissions in snapshot, model-level token and instance-level token. After the object to be operated performs the target operation on the front-end user interface component, the front end determines the token corresponding to the target operation and sends the token to the back end for verification. If the backend processing module 704 successfully verifies the token, the backend processing module 704 is also used to perform operations on the target data model and target instance corresponding to the token according to the final atomic operation permission. The frontend processing module 705 is also used to render the frontend user interface according to the result of the execution operation. After the user interface is rendered, the functions in the user interface corresponding to the final atomic operation permission are operable.

[0095] The data operation permission control device 70 provided in the above embodiments can realize the technical solutions described in the above data operation permission control method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above data operation permission control method embodiments, and will not be repeated here.

[0096] Please refer to Figure 8 , Figure 8 This is a schematic diagram of an embodiment of the electronic device of this application. In this embodiment of the invention, the electronic device 800 includes a processor 801, a memory 802, and a display 803. Figure 8 Only some components of the electronic device 800 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0097] In some embodiments, processor 801 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 802 or process data, such as the data operation permission control method in this invention.

[0098] In some embodiments, processor 801 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 801 may be local or remote. In some embodiments, processor 801 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, intranet, multi-cloud, etc., or any combination thereof.

[0099] In some embodiments, memory 802 may be an internal storage unit of electronic device 800, such as a hard disk or memory of electronic device 800. In other embodiments, memory 802 may also be an external storage device of electronic device 800, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 800.

[0100] Furthermore, the memory 802 may include both internal storage units of the electronic device 800 and external storage devices. The memory 802 is used to store application software and various types of data installed on the electronic device 800.

[0101] In some embodiments, display 803 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 803 is used to display information from electronic device 800 and to display visual user applications. Components 801-803 of electronic device 800 communicate with each other via a system bus.

[0102] In one embodiment, when the processor 801 executes the data operation permission control program in the memory 802, the following steps can be implemented: Obtain at least one functional tag that matches the object to be operated on, wherein each functional tag is the smallest authorized unit composed of multiple atomic operation permissions, used to characterize the operation permissions of the object to be operated on to instances and attributes in the data model; Each of the aforementioned functional tags is divided into multiple atomic operation permissions, and the multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of the metadata are hydrated according to a preset permission hydration strategy to obtain a snapshot of the final hydrated atomic operation permissions. The backend performs serialization, signing, and compression on the snapshot to generate model-level tokens and instance-level tokens. The model-level token carries operation permissions for the data model, and the instance-level token carries operation permissions for each instance in the data model. The snapshot, the model-level token, and the instance-level token are sent to the front end. The front end renders the front-end user interface components using the atomic operation permissions in the snapshot, the model-level token, and the instance-level token. After the object to be operated performs a target operation on the front-end user interface components, the front end determines the token corresponding to the target operation and sends the token to the back end for verification. If the token is successfully verified in the backend, the target data model and target instance corresponding to the token are executed according to the final atomic operation permission, and the result of the execution operation is returned to the frontend user interface for interface rendering. After the interface is rendered, the functions in the user interface corresponding to the final atomic operation permission are operable.

[0103] It should be understood that when the processor 801 executes the data operation permission control program in the memory 802, in addition to the functions mentioned above, it can also perform other functions, as can be found in the description of the corresponding method embodiments above.

[0104] Furthermore, this embodiment of the invention does not specifically limit the type of electronic device 800 mentioned. Electronic device 800 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the invention, electronic device 800 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0105] Accordingly, this application also provides a computer-readable storage medium for storing computer-readable programs or instructions. When the programs or instructions are executed by a processor, they can implement the steps or functions of the data operation permission control methods provided in the above-described method embodiments.

[0106] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0107] The data operation permission control method, device, electronic device, and computer-readable storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for controlling data operation permissions, characterized in that, include: Obtain at least one functional tag that matches the object to be operated on, wherein each functional tag is the smallest authorized unit composed of multiple atomic operation permissions of multiple data models, used to characterize the operation permissions of the object to be operated on to instances and attributes in the data models. Each of the aforementioned functional tags is divided into multiple atomic operation permissions, and the multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of the metadata are hydrated according to a preset permission hydration strategy to obtain a snapshot of the final hydrated atomic operation permissions. The backend performs serialization, signing, and compression on the snapshot to generate model-level tokens and instance-level tokens. The model-level token carries operation permissions for the data model, and the instance-level token carries operation permissions for each instance in the data model. The snapshot, the model-level token, and the instance-level token are sent to the front end. The front end renders the front-end user interface components using the atomic operation permissions in the snapshot, the model-level token, and the instance-level token. After the object to be operated performs a target operation on the front-end user interface components, the front end determines the token corresponding to the target operation and sends the token to the back end for verification. If the token is successfully verified in the backend, the target data model and target instance corresponding to the token are executed according to the final atomic operation permission, and the result of the execution operation is returned to the frontend user interface for interface rendering. After the interface is rendered, the functions in the user interface corresponding to the final atomic operation permission are operable.

2. The data operation permission control method according to claim 1, characterized in that, The function tags include multiple ones; the step of splitting the function tags into multiple atomic operation permissions includes: Each of the aforementioned function tags is further divided into the new permission corresponding to the data model, the delete permission corresponding to the instance, the edit permission corresponding to the attribute, and the view permission. The step of performing permission hydration on multiple atomic operation permissions, the first baseline permissions of the preset data model, and the second baseline permissions of the metadata according to a preset permission hydration strategy includes: The first baseline permission and the second baseline permission are combined with the atomic operation permissions obtained after splitting each of the function tags, and the permissions are merged according to the combination result.

3. The data operation permission control method according to claim 2, characterized in that, The second baseline permissions include data visibility and data invisibility; The step of combining the first baseline permission and the second baseline permission with the atomic operation permissions obtained after splitting each of the function tags, and merging the permissions according to the combination result, includes: Detect whether the instance corresponding to the function label is in the current data model; If it is detected that the instance corresponding to the function tag is not in the current data model, the type of the second baseline permission is determined; If the type of the second baseline permission is data visibility, set the final atomic operation permission to view only. If the type of the second baseline permission is "data not visible", then the final atomic operation permission is set to "no permission".

4. The data operation permission control method according to claim 3, characterized in that, The first baseline permissions include data editability, data visibility, and data invisibility; The atomic operation permissions include instance-level permissions of the instance corresponding to the function tag and attribute-level permissions of the attributes in the instance. The instance-level permissions include display conditions, editing conditions, deletion conditions, and whether new items can be added. The attribute-level permissions include visible editing, de-identified editing, invisible editing, visible, de-identified, and invisible. If an instance corresponding to the function label is detected in the current data model, the method further includes: Determine the type of the first baseline permission; If the type of the first baseline permission is data editable, the final atomic operation permission is set to have full operation permissions; When the type of the first baseline permission is data visible, the display condition in the instance-level permission is set to empty, and the invisible attribute in the attribute permission is set to empty. Then, multiple atomic operation permissions are merged according to the maximum permission priority merging strategy. If the type of the first baseline permission is "data not visible", then multiple atomic operation permissions are merged according to the maximum permission priority merging strategy.

5. The data operation permission control method according to claim 4, characterized in that, The merging of multiple atomic operation permissions according to the maximum permission priority merging strategy includes: Based on the atomic operation permissions corresponding to the editing conditions matched by the data, obtain the set of editable attributes; If all atomic operation permissions in the hit are desensitized and uneditable, set that attribute as a desensitized attribute. If all atomic operation permissions in the hit are not visible, set that attribute to be invisible and set the other attributes to be visible. If any one of the deletion conditions among multiple atomic operation permissions is met, then the final atomic operation permission includes "deleteable". If any one of the multiple atomic operation permissions can be added, then the final atomic operation permissions include those that can be added.

6. The data operation permission control method according to claim 5, characterized in that, The backend verifies the token in the following way: Verify whether the token's signature is valid, whether the token has expired, whether the token is bound to the object to be operated on, whether the token is bound to the current instance, and whether the token's permission record has been tampered with; If the token's signature is verified to be valid, the token has not expired, the token is bound to the object to be operated on, the token is bound to the current instance, and the token's permission record has not been tampered with, then the permission information is obtained from the token. The token is verified a second time based on the permission information. If the second verification is successful, it indicates that the token has been successfully verified. If the token is found to have at least one of the following characteristics: invalid signature, expired, not bound to the object to be operated on, not bound to the current instance, or permission record tampered with, the backend will fail to verify the token.

7. The data operation permission control method according to claim 6, characterized in that, The tokens include target model-level tokens and target instance-level tokens; The step of performing secondary verification of the token based on the permission information includes: Based on the permission information, determine whether the target model-level token has permission to add new tokens; Read the editable attributes of the target instance-level token. If the editable attributes are read, remove the non-editable attributes from the target instance-level token. If the editable attributes are not read, set the permissions of the target instance-level token to non-editable. Based on the permission information, determine whether the target instance-level token has permission to be deleted.

8. A data operation permission control device, characterized in that, include: The modules include: acquisition module, split module, merge module, backend processing module, and frontend processing module. The acquisition module is used to acquire at least one functional tag that matches the object to be operated on, wherein each functional tag is the smallest authorized unit composed of multiple atomic operation permissions of multiple data models, and is used to characterize the operation permissions of the object to be operated on to instances and attributes in the data models. The splitting module is used to split each of the function tags into multiple atomic operation permissions; The merging module is used to perform permission hydration on multiple atomic operation permissions, the first baseline permission of the preset data model, and the second baseline permission of the metadata according to a preset permission hydration strategy, so as to obtain a snapshot of the final atomic operation permissions after hydration. The backend processing module is used to serialize, sign and compress the snapshot to generate model-level tokens and instance-level tokens. The model-level token carries operation permissions for the data model, and the instance-level token carries operation permissions for each instance in the data model. The backend processing module is also used to send the snapshot, the model-level token, and the instance-level token to the frontend processing module; The front-end processing module renders the front-end user interface components using the snapshot, the model-level token, and the atomic operation permissions in the instance-level token. After the object to be operated performs a target operation on the front-end user interface component, the front-end determines the token corresponding to the target operation and sends the token to the back-end for verification. If the backend processing module successfully verifies the token, the backend processing module is further configured to perform operations on the target data model and target instance corresponding to the token according to the final atomic operation permission. The frontend processing module is further configured to render the frontend user interface according to the result of the operation. After the user interface is rendered, the functions in the user interface corresponding to the final atomic operation permission are operable.

9. An electronic device, the electronic device comprising a processor and a memory, characterized in that, The memory is used to store instructions, and the processor is used to call the instructions in the memory to cause the electronic device to execute the data operation permission control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on an electronic device, cause the electronic device to perform the data operation permission control method as described in any one of claims 1 to 7.

Images