A Permission Control Method, Device and Storage Medium Based on a Meta-Model

Abstract

The present application proposes a permission control method, device, and storage medium based on a meta-model. The method includes: creating an application based on business requirements, using the meta-model to describe the page content of each front-end page of the application, and defining the permission definition information that needs to be predefined according to the meta-model standard on each front-end page; when running the application, calling the meta-model engine to execute: parsing each front-end page to obtain all the definition information of each front-end page, constructing the permission definition information of each front-end page into a permission authorization list, and simultaneously persistently saving it to the database and saving it to the meta-model engine; according to the permission authorization list, selecting the corresponding permission resources in the graphical interface to complete the binding and allocation of permissions, obtaining the permission binding relationship, and controlling the corresponding permission resources based on the permission binding relationship; when running the application, calling the meta-model engine to inject the required new permission control points into the permission authorization list and then update it.

Description

Technical Field

[0001] The present application relates to the technical field of permission control, and particularly to a permission control method, device and storage medium based on a meta-model. Background Art

[0002] Currently, the mainstream solution for permission control in software systems is to create and maintain permission point information based on pages. Developers embed the corresponding permission point information in the code, and when the software runs, it is controlled according to the pre-embedded logic. When migrating the environment, the permission point information in the development environment needs to be synchronized to the target environment, that is, the definition and implementation of permissions are separated in form.

[0003] It can be seen that in the above mainstream permission control solution, the permission point information needs to involve actions such as cross-environment migration. Moreover, since the permission point information must be pre-embedded in the code, there is a problem that the permission control points cannot be increased or decreased during the operation of the software system. Summary of the Invention

[0004] Embodiments of the present application provide a permission control method, device and storage medium based on a meta-model to solve the problems existing in the related technologies. The technical solutions are as follows:

[0005] In a first aspect, embodiments of the present application provide a permission control method based on a meta-model, including:

[0006] Based on business requirements, create an application, and use a meta-model to describe the page content of each front-end page of the application, and define the permission definition information that needs to be pre-defined according to the meta-model standard on each front-end page;

[0007] When running the application, call the meta-model engine to parse each front-end page to obtain all the definition information of each front-end page, and the all definition information includes permission definition information;

[0008] Call the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, persistently save the permission authorization list to a database, and at the same time save the permission authorization list to the meta-model engine;

[0009] According to the permission authorization list, select permission resources that meet the identity and needs of specific users, user groups and roles in the graphical interface of the application to complete the binding and allocation of permissions, and obtain a permission binding relationship;

[0010] Call the meta-model engine to control the corresponding permission resources based on the permission binding relationship;

[0011] Among them, when running the application, if a new permission control point needs to be added, the meta-model engine is called to inject the new permission control point into the permission authorization list, and then the permission authorization list is updated.

[0012] In one implementation manner, using a meta-model to describe the page content of each front-end page of the application includes:

[0013] Define a number of page meta-models on each of the front-end pages. Among them, each of the page meta-models includes a number of component meta-models, and there is a hierarchical relationship among the number of component meta-models;

[0014] Describe the number of page meta-models as the page content of each front-end page.

[0015] In one implementation manner, the permission definition information that needs to be predefined described according to the meta-model standard on each of the front-end pages includes:

[0016] On each of the front-end pages, each meta-model is defined as an independent permission control point, and the way to enable the permission definition of each meta-model is configured in the form of code or in the form of configuration in a low-code development interface in a form, to obtain the permission definition information, where each meta-model is a page meta-model or a component meta-model.

[0017] In one implementation manner, calling the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list includes:

[0018] Call the meta-model engine to group all the meta-models of each front-end page according to the applications they belong to, and then construct a tree-structured permission authorization list according to the hierarchical relationship among all the meta-models, to obtain the permission authorization list.

[0019] In one implementation manner, calling the meta-model engine to control the corresponding permission resources based on the permission binding relationship includes:

[0020] Call the meta-model engine to perform user authentication based on the permission binding relationship, and take the intersection permission range between the permission range delimited by the scope and the permission range delimited by the role as the authentication result of the permission;

[0021] Control the corresponding permission resources according to the authentication result.

[0022] In one implementation manner, the method further includes:

[0023] During the process of calling the meta-model engine to perform user authentication based on the permission binding relationship, when verifying the permission of the corresponding meta-model, synchronously verify the permission of the entire hierarchical meta-model link where the corresponding meta-model is located.

[0024] In one implementation, calling the meta-model engine to inject the newly added permission control point into the permission authorization list includes:

[0025] Calling a service to dynamically generate incremental permission description information of the newly added permission control point;

[0026] Calling the meta-model engine to parse the incremental permission description information to obtain permission definition information of the newly added permission control point, and then injecting the permission definition information of the newly added permission control point into the permission authorization list.

[0027] In a second aspect, an embodiment of the present application further provides a meta-model-based permission control device, including:

[0028] A creation unit, configured to create an application based on business requirements, describe the page content of each front-end page of the application using a meta-model, and define, according to the meta-model standard description, the permission definition information that needs to be predefined on each of the front-end pages;

[0029] An analysis unit, configured to, when running the application, call a meta-model engine to analyze each of the front-end pages to obtain all the definition information of each of the front-end pages, where the all definition information includes permission definition information;

[0030] A construction unit, configured to call the meta-model engine to construct the permission definition information of each of the front-end pages into a permission authorization list, persistently save the permission authorization list to a database, and at the same time save the permission authorization list to the meta-model engine;

[0031] A binding unit, configured to, according to the permission authorization list, select permission resources that match the identity and requirements of specific users, user groups, and roles in the graphical interface of the application to complete the binding and allocation of permissions, and obtain a permission binding relationship;

[0032] A control unit, configured to call the meta-model engine to control corresponding permission resources based on the permission binding relationship;

[0033] Wherein, the construction unit is further configured to: when running the application, if a newly added permission control point is required, call the meta-model engine to inject the newly added permission control point into the permission authorization list, and then update the permission authorization list.

[0034] In one implementation, when the creation unit is used to describe the page content of each front-end page of the application using a meta-model, it is specifically configured to:

[0035] Define a number of page meta - models on each of the front - end pages. Among them, each page meta - model includes a number of component meta - models, and there is a hierarchical relationship among the number of component meta - models;

[0036] Describe the number of page meta - models as the page content of each front - end page.

[0037] In one implementation, when the creation unit is used to define and describe the permission definition information that needs to be predefined according to the meta - model standard on each front - end page, it is specifically used for:

[0038] On each front - end page, define each meta - model as an independent permission control point, and configure the way to enable permission definition for each meta - model in the form of code or in the form of configuration in a form through a low - code development interface, where each meta - model is a page meta - model or a component meta - model, to obtain the permission definition information.

[0039] In one implementation, when the construction unit is used to call the meta - model engine to construct the permission authorization list from the permission definition information of each front - end page, it is specifically used for:

[0040] Call the meta - model engine to group all the meta - models of each front - end page according to the applications they belong to, and then construct a tree - structured permission authorization list according to the hierarchical relationship among all the meta - models to obtain the permission authorization list.

[0041] In one implementation, when the control unit is used to call the meta - model engine to control the corresponding permission resources based on the permission binding relationship, it is specifically used for:

[0042] Call the meta - model engine to perform user authentication based on the permission binding relationship, and take the intersection permission range between the permission range delimited by the scope and the permission range delimited by the role as the authentication result of the permission;

[0043] Control the corresponding permission resources according to the authentication result.

[0044] In one implementation, the control unit is further used for:

[0045] During the process of calling the meta - model engine to perform user authentication based on the permission binding relationship, when verifying the permissions of the corresponding meta - model, synchronously verify the permissions of the entire hierarchical meta - model link where the corresponding meta - model is located.

[0046] In one implementation, when the construction unit is used to call the meta - model engine to inject the newly added permission control point into the permission authorization list, it is specifically used for:

[0047] Invoke a service to dynamically generate incremental permission description information for the newly added permission control points;

[0048] Invoke the meta-model engine to parse the incremental permission description information to obtain the permission definition information of the newly added permission control points, and then inject the permission definition information of the newly added permission control points into the permission authorization list.

[0049] Thirdly, an embodiment of the present application further provides a computer device, which includes: a memory and a processor. Instructions are stored in the memory, and the instructions are loaded and executed by the processor to implement the method in any one of the above aspects. Among them, the memory and the processor communicate with each other through an internal connection path.

[0050] Fourthly, an embodiment of the present application further provides a computer-readable storage medium. A computer program is stored in the computer-readable storage medium. When the computer program runs on a computer, the method in any one of the above aspects is implemented.

[0051] The advantages or beneficial effects in the above technical solutions at least include:

[0052] (1) The integration and unification of permission implementation and permission definition: By using meta-model technology, when the application runs, the permission definition information is injected into the meta-model engine, and then the permission control is realized according to the relationship between the permission and the user. The permission definition is bundled with the permission implementation, that is, the definition and implementation are included in the code, and the implementation is the definition. For low-code scenarios, the action of migrating the permission definition information across environments can be omitted, simplifying the development steps.

[0053] In addition, when migrating across environments, only migrating the code can complete the migration of all permission information and logic. In other words, in the scenario of environment migration, only the upgrade of the code itself needs to be concerned, improving the data reliability of the operation and maintenance / development personnel during migration and enhancing the security of the permission.

[0054] (2) The on-demand addition of permission control points during runtime: By using meta-model technology, when the application runs, the permission definition information is injected into the meta-model engine, supporting the online addition and deletion of permission definitions to realize the dynamic addition of permission control logic during the application runtime. It can not only authorize according to the permission control points predefined in the project code, but also dynamically create the permission control points of the corresponding functions on demand according to the project scenario requirements during the project runtime, improving the efficiency, flexibility, and reliability of permission adaptation.

[0055] That is, during the application runtime, flexible and reliable permission management can be realized, the permission control logic can be dynamically increased or decreased online, thereby improving the efficiency of permission development and operation and maintenance, and the permission control points can be newly added online and take effect immediately without code development.

[0056] The above summary is for the purpose of the specification only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of the present application will be readily apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In the drawings, unless otherwise specified, the same reference numerals throughout the several views denote the same or similar components or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in the present application and should not be regarded as limiting the scope of the present application.

[0058] Figure 1 A flowchart example of a permission control method based on a meta-model provided for an embodiment of the present application;

[0059] Figure 2 A user interface example diagram of a front-end page provided for an embodiment of the present application;

[0060] Figure 3 An example diagram of the actual generated data of a front-end page provided for an embodiment of the present application;

[0061] Figure 4 An example diagram of enabling permission control in the form of configuration in a form through a low-code development interface provided for an embodiment of the present application;

[0062] Figure 5 An example diagram of dynamically constructing a permission authorization list according to a comparison structure provided for an embodiment of the present application;

[0063] Figure 6 An example diagram of binding and assigning permissions through a graphical interface provided for an embodiment of the present application;

[0064] Figure 7 A structural block diagram of a permission control device based on a meta-model provided for an embodiment of the present application;

[0065] Figure 8 A structural block diagram of a computer device provided for an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0066] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various different ways without departing from the spirit or scope of the present application. Therefore, the drawings and the description are to be regarded as illustrative in nature and not restrictive.

[0067] In the related art, there are the following two defects in the current mainstream authorization control solutions for software systems:

[0068] (1) Separation of authorization implementation and authorization definition: First, authorization point information (i.e., authorization definition) is created and maintained based on pages and stored in a database. Then, during development, the authorization point information is embedded into the code (i.e., authorization implementation). During this process, there will be problems where some authorization definitions cannot be mapped. In addition, when migrating across environments, the database and the corresponding code version need to be migrated together.

[0069] (2) Authorization control points cannot be added or removed during runtime: Authorization configuration depends on pre-defined authorization point information for authorization binding, which results in the inability to add or remove authorization control points during runtime. However, during project development, it is often impossible to completely pre-define all the required authorization point information, and it is necessary to fill in and develop during business trial operation.

[0070] Based on this, the embodiments of the present application propose an authorization control solution based on a meta-model to solve the defects existing in the current mainstream authorization control solutions for software systems.

[0071] The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0072] Figure 1 The flowchart of an authorization control method based on a meta-model according to an embodiment of the present application is shown. As Figure 1 shown, the method may include the following steps:

[0073] S110. Based on business requirements, create an application, and use a meta-model to describe the page content of each front-end page of the application, and describe the authorization definition information that needs to be pre-defined on each front-end page according to the meta-model standard.

[0074] In one implementation, corresponding applications can be created based on different business requirements. In this way, different business requirements can be met through the corresponding applications.

[0075] In one implementation, using a meta-model to describe the page content of each front-end page of the application may include: defining a number of page meta-models on each front-end page, where each page meta-model includes a number of component meta-models, and there is a hierarchical relationship between the number of component meta-models; and describing the number of page meta-models as the page content of each front-end page.

[0076] It can be understood that in the embodiments of the present application, the page development of the application is mainly implemented in a way that generates standard meta-model instances that conform to the meta-model definition.

[0077] In specific implementation, the component meta-model can be used to describe specific page elements. That is, several component meta-models can include, but are not limited to: tables, forms, and buttons.

[0078] As an example, when using the meta-model to define a button page element on a certain front-end page, its user interface (i.e., UI interface) can be as Figure 2 shown, and the actual generated data can be as Figure 3 shown.

[0079] In one implementation manner, the permission definition information that needs to be predefined described according to the meta-model standard on each front-end page can include: on each front-end page, each meta-model is defined as an independent permission control point, and the way to configure the permission definition for each meta-model is configured in the form of code or through a low-code development interface in the form of a form in the form, obtaining the permission definition information. Among them, each meta-model is a page meta-model or a component meta-model. In other words, the process of defining permissions through the meta-model is to add content related to permission control to the data that conforms to the meta-model standard definition.

[0080] It can be understood that in the front-end page composed of meta-models such as page meta-models and component meta-models, each meta-model can become an independent permission control point. In this way, the granularity of permission control can be accurately refined to any meta-model, enabling users / developers to freely and flexibly select the meta-models for which permission control needs to be enabled.

[0081] In specific implementation, during the process of configuring the way to configure the permission definition for each meta-model in the form of code or through a low-code development interface in the form of a form in the form, a description of the permission information can be added to the attributes of the meta-model for which permission control needs to be enabled, such as relevant information about the permission information, the unique identifier of the permission control point, etc.

[0082] As an example, during the process of configuring the way to configure the permission definition for each meta-model in the form of code, taking a certain page meta-model for which permission control needs to be enabled as an example, the following description of the permission information can be added to the attributes of this page meta-model through code:

[0083] Type: Page meta-model

[0084] Meta-model Id: xxxx

[0085] Is permission enabled: Yes

[0086] Permission description: Personnel Management App – Employee Management Page

[0087] Permission unique identification code: HR-EMPLOYEE-PAGE.

[0088] Among them, in this example, the permission unique identifier can be non-essential. If it does not need to be maintained, the meta-model instance Id can be defaultly used as the identification code.

[0089] As another example, during the process of configuring the permission definition method for each meta-model in the form configured in the form on the low-code development interface, after selecting the corresponding meta-model on the operation interface, Figure 4 As shown, for this meta-model, click the "Whether to enable permission control" button to enable permission control, and configure the corresponding permission name as the permission identification.

[0090] In the embodiment of the present application, by executing step S110, all meta-model resources can be carried by the application, and an application can have several front-end pages and back-end physical models, which can better meet different business requirements.

[0091] S120: When running the application, call the meta-model engine to parse each front-end page of the application to obtain all the definition information of each front-end page.

[0092] In one implementation, all the definition information may include, but is not limited to: permission definition information.

[0093] In specific implementation, all the definition information may also include meta-model basic information (such as meta-model name, type, etc.), meta-model business information (such as styles of front-end page element size, color, etc.). It can be understood that the parsing content of the meta-model engine may include, but is not limited to: meta-model basic information, meta-model business information, and permission definition information (which can also be called meta-model permission information).

[0094] As an example, when running the application, the front-end page will inject all the meta-models into the meta-model engine in the form of a description file, and the meta-model engine will parse these meta-models to obtain all the definition information of each front-end page.

[0095] In the embodiment of the present application, by executing step S120, specific usable resources such as pages and database tables can be constructed by parsing the meta-model and combining with basic resources.

[0096] S130: Call the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, persistently save the permission authorization list to the database, and at the same time save the permission authorization list to the meta-model engine.

[0097] In one implementation, calling the meta-model engine to construct a permission authorization list from the permission definition information of each front-end page may include: after grouping all the meta-models of each front-end page according to the applications they belong to by calling the meta-model engine, constructing a tree-structured permission authorization list based on the hierarchical relationships among all the meta-models, and obtaining the permission authorization list.

[0098] It can be understood that the meta-model engine constructs a permission authorization list according to the grouping relationships and hierarchical relationships among the meta-models. Among them, by grouping all the meta-models of each front-end page according to the applications they belong to, the meta-models configured to require authentication can be filtered out.

[0099] That is, in the embodiments of the present application, the permission authorization list is not immutable, and it can be dynamically updated as the application is installed, updated, and the meta-models are published online, etc. In other words, the dynamic update of the permission authorization list can be achieved based on comparison. For example, as Figure 5 shown, it can be achieved through the following:

[0100] (a) The newly installed application has new meta-models that require authentication

[0101] Compare the current permission authorization list with the meta-models in the new application, and use the meta-models that do not exist in the set of existing meta-models but exist in the set of incremental meta-models as the permission control points that need to be added.

[0102] (b) Update the installed application, which may add meta-models that require authentication, change the hierarchy of the original meta-models, or delete some meta-models that require authentication

[0103] Compare the current permission authorization list with the meta-models in the updated application. If a certain meta-model does not exist in the set of existing meta-models of the application but exists in the updated set of meta-models, then use this meta-model as the permission control point that needs to be added; or, if a certain meta-model has the same ID in the set of existing meta-models and the updated set of meta-models of the application, but the meta-model hierarchy or permission name is different, then modify this meta-model; or, if a certain meta-model exists in the set of existing meta-models of the application but does not exist in the updated set of meta-models, then delete this meta-model.

[0104] In specific implementation, by persistently saving the permission authorization list to the database, it is possible to display the permission authorization list when authorizing users in scenarios where authentication is relatively infrequent and the performance requirements are not high, etc.

[0105] In specific implementation, by saving the permission authorization list into the meta-model engine, in scenarios with high requirements for authentication performance, it is possible to verify whether a resource exists according to the requested resource ID, and return the verification result according to the authorization result. Moreover, there is no need for list display and range query.

[0106] That is, in the embodiments of the present application, by saving the permission authorization list in the database and the meta-model engine simultaneously, the usage requirements for permission control in different scenarios can be met.

[0107] In practical applications, permission definition information can exist in any form, such as in memory, files, and databases. This will result in the fact that although the hierarchical relationship between meta-models is recorded in the front-end page, the storage form in the meta-model engine is discrete and one-dimensional, which is not convenient for query and display. Based on this, through step S130 in the embodiments of the present application, it is convenient to display the authorized permissions for users in actual use and retrieve the corresponding permission control points according to conditions, so as to be bound and take effect when configuring user permissions.

[0108] S140. According to the permission authorization list, select permission resources that meet the identities and requirements of specific users, user groups, and roles in the graphical interface of the application to complete the binding and allocation of permissions, and obtain the permission binding relationship.

[0109] In one implementation, after calling the meta-model engine to dynamically construct the permission authorization list, it is possible to allocate and bind permissions to users / user groups / roles. For example, when a user / developer saves after selecting permission resources that meet the identities and requirements of specific users, user groups, and roles in the graphical interface of the application according to the permission authorization list, the binding and allocation of permissions can be completed, and the permission binding relationship can be obtained.

[0110] Exemplarily, after the user / developer completes the relevant selection operations as Figure 6 shown and then saves, the binding and allocation of permissions can be completed, and the corresponding permission binding relationship can be obtained.

[0111] S150. Call the meta-model engine to control the corresponding permission resources based on the permission binding relationship.

[0112] In one implementation, calling the meta-model engine to control the corresponding permission resources based on the permission binding relationship may include: calling the meta-model engine to perform user authentication based on the permission binding relationship, and taking the intersection permission range between the permission range delimited by the scope and the permission range delimited by the role as the authentication result of the permission; controlling the corresponding permission resources according to the authentication result.

[0113] It can be understood that the specific permission verification logic executed by the meta-model engine depends on the allocation relationship between resources and resource users, that is, whether permissions can be obtained is determined according to the allocation result. It is similar to but different from the role-resource relationship maintained by the RBAC permission control model. It also has dimensions other than roles, such as scopes, that can be associated with resources, further enhancing the flexibility of permission verification. In other words, in the embodiments of the present application, in addition to roles, it can also be associated with users to implement the dimension of permission control.

[0114] In one implementation, since there is a hierarchical relationship between meta-models, during the process of calling the meta-model engine to perform user authentication based on the permission binding relationship, when verifying the permissions of a corresponding meta-model, the permissions of the entire hierarchical meta-model link where the corresponding meta-model is located can be verified synchronously.

[0115] Exemplarily, taking the corresponding meta-model as the meta-model of the new employee button as an example, when verifying its permissions, the permissions of the following entire hierarchical meta-model link can be verified synchronously:

[0116] Personnel APP meta-model - Employee management page meta-model - Employee management list meta-model - New employee button meta-model.

[0117] In this example, the prerequisite for determining whether to have the permission of the new employee button meta-model is to have the permissions of all ancestor meta-models on its hierarchical link. In other words, if there is no permission for the Personnel APP meta-model, one cannot have the permission of the new employee button (its descendant nodes).

[0118] In the embodiments of the present application, by executing step S150, the meta-model engine can depend on the permission binding relationship to determine whether to allow the invocation of a certain service or display a certain button.

[0119] Although when developing a page in a low-code platform, it can be determined which resources need to be controlled according to the actual business requirements of the software product being developed. However, in actual applications, developers often face complex and changeable business requirements and it is difficult to accurately determine exactly which resources need to be subject to permission control during the development stage.

[0120] Based on this, in the scenarios applicable to the embodiments of the present application, when running an application, if a new permission control point needs to be added, the following steps can be executed:

[0121] S160. Call the meta-model engine to inject the new permission control point into the permission authorization list and then update the permission authorization list.

[0122] For example, the permission authorization list can be updated in the database and the meta-model engine.

[0123] In one implementation, relevant management personnel can select the required meta-model (such as a certain button) according to all the definition information of each front-end page parsed by the meta-model engine, and this meta-model can be used as a newly added permission control point.

[0124] Exemplarily, when a certain page has no permission control requirements when it is initially put into use after development, but during the subsequent use of this page, the user party requests that this page needs to be controlled by permissions. In this case, corresponding permission control points can be dynamically added.

[0125] In one implementation, injecting the newly added permission control point into the permission authorization list by calling the meta-model engine may include: calling the service to dynamically generate the incremental permission description information of the newly added permission control point; calling the meta-model engine to parse the incremental permission description information to obtain the permission definition information of the newly added permission control point, and then injecting the permission definition information of the newly added permission control point into the permission authorization list. After that, step S140 can be executed again.

[0126] Taking the above example as an example, by executing step S160 and then executing step S140 again, this page can have the ability to control permissions.

[0127] In the embodiments of the present application, by executing step S160, the ability to dynamically inject permission description information can be provided.

[0128] In specific applications, the above-mentioned meta-model engine can be implemented by using the meta-model engine in the Saiyi Gushen IIDP framework, or can be implemented by using other types of meta-model engines. The embodiments of the present application do not make any limitations in this regard.

[0129] In summary, the permission control method based on the meta-model provided by the embodiments of the present application can achieve the following effects by executing the above steps S110 - S160:

[0130] (1) The integration and unification of permission implementation and permission definition: By using the meta-model technology, when the application runs, the permission definition information is injected into the meta-model engine, and then the permission control is realized according to the relationship between permissions and users. The permission definition is bundled on the permission implementation, that is, the code contains both definition and implementation, and implementation is definition. For the low-code scenario, the action of migrating the permission definition information across environments can be omitted, simplifying the development steps.

[0131] In addition, when migrating across environments, only migrating the code can complete the migration of all permission information and logic. In other words, in the scenario of environment migration, only the upgrade of the code itself needs to be concerned, improving the data reliability of the operation and maintenance / development personnel during migration and enhancing the security of permissions.

[0132] (2) Dynamically adding permission control points during runtime: By leveraging meta-model technology, during the runtime of an application, permission definition information is injected into the meta-model engine to support online addition and deletion of permission definitions, thereby realizing dynamic addition of permission control logic during the runtime of the application. It can not only authorize based on the pre-defined permission control points in the project code but also dynamically and online create permission control points for corresponding functions according to the project scenarios during the project runtime, improving the efficiency, flexibility, and reliability of permission adaptation.

[0133] That is, during the runtime of the application, flexible and reliable permission control can be achieved, enabling online dynamic addition and deletion of permission control logic, thereby improving the efficiency of permission development and operation and maintenance. Additionally, new permission control points can be added online and take effect immediately without code development.

[0134] Figure 7 Shown is a structural block diagram of a meta-model-based permission control device according to an embodiment of the present application. As Figure 7 shown, the device may include:

[0135] A creation unit 210, configured to create an application based on business requirements, describe the page content of each front-end page of the application using a meta-model, and define the pre-defined permission definition information on each front-end page according to the meta-model standard;

[0136] A parsing unit 220, configured to, when the application is running, call the meta-model engine to parse each front-end page to obtain all the definition information of each front-end page, where all the definition information includes permission definition information;

[0137] A construction unit 230, configured to call the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, persistently save the permission authorization list to a database, and simultaneously save the permission authorization list to the meta-model engine;

[0138] A binding unit 240, configured to, according to the permission authorization list, select permission resources that match the identity and requirements of specific users, user groups, and roles in the graphical interface of the application to complete the binding and allocation of permissions and obtain a permission binding relationship;

[0139] A control unit 250, configured to call the meta-model engine to control the corresponding permission resources based on the permission binding relationship;

[0140] Among them, the construction unit 230 is further configured to: when the application is running, if a new permission control point needs to be added, call the meta-model engine to inject the new permission control point into the permission authorization list and then update the permission authorization list.

[0141] In an implementation manner, when the creation unit 210 is used to describe the page content of each front-end page of the application using a meta-model, it is specifically configured to:

[0142] Define a number of page meta - models on each front - end page. Among them, each page meta - model includes a number of component meta - models, and there is a hierarchical relationship among the number of component meta - models;

[0143] Describe the number of page meta - models as the page content of each front - end page.

[0144] In one implementation, when the creation unit 210 is used to define and describe the pre - defined permission definition information according to the meta - model standard on each front - end page, it is specifically used for:

[0145] On each front - end page, define each meta - model as an independent permission control point, and configure the way to enable the permission definition for each meta - model in the form of code or in the form of configuration in the form in the low - code development interface to obtain the permission definition information, where each meta - model is a page meta - model or a component meta - model.

[0146] In one implementation, when the construction unit 230 is used to call the meta - model engine to construct the permission authorization list from the permission definition information of each front - end page, it is specifically used for:

[0147] Call the meta - model engine to group all the meta - models of each front - end page according to the applications they belong to, and then construct a tree - structured permission authorization list according to the hierarchical relationship among all the meta - models to obtain the permission authorization list.

[0148] In one implementation, when the control unit 250 is used to call the meta - model engine to control the corresponding permission resources based on the permission binding relationship, it is specifically used for:

[0149] Call the meta - model engine to perform user authentication based on the permission binding relationship, and take the intersection permission range between the permission range delimited by the scope and the permission range delimited by the role as the authentication result of the permission;

[0150] Control the corresponding permission resources according to the authentication result.

[0151] In one implementation, the control unit 250 is also used for:

[0152] During the process of calling the meta - model engine to perform user authentication based on the permission binding relationship, when verifying the permissions of the corresponding meta - model, synchronously verify the permissions of the entire hierarchical meta - model link where the corresponding meta - model is located.

[0153] In one implementation, when the construction unit 230 is used to call the meta - model engine to inject new permission control points into the permission authorization list, it is specifically used for:

[0154] Call the service to dynamically generate the incremental permission description information of the new permission control points;

[0155] Invoke the meta-model engine to parse the incremental permission description information, obtain the permission definition information of the newly added permission control points, and then inject the permission definition information of the newly added permission control points into the permission authorization list.

[0156] For the functions of the units in the meta-model-based permission control device according to the embodiments of the present application, reference may be made to the corresponding descriptions in the above methods, which will not be elaborated herein.

[0157] Figure 8 Shows a structural block diagram of a computer device according to an embodiment of the present application. As Figure 8 shown, the computer device includes: a memory 310 and a processor 320. Instructions are stored in the memory 310, and the instructions are loaded and executed by the processor 320 to implement the meta-model-based permission control method in the above embodiments. The number of the memory 310 and the processor 320 can be one or more.

[0158] The computer device further includes:

[0159] A communication interface 330, configured to communicate with external devices and perform data interaction and transmission.

[0160] If the memory 310, the processor 320, and the communication interface 330 are implemented independently, the memory 310, the processor 320, and the communication interface 330 can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 only a thick line is shown in the figure, but it does not mean that there is only one bus or one type of bus.

[0161] Optionally, in a specific implementation, if the memory 310, the processor 320, and the communication interface 330 are integrated on a chip, the memory 310, the processor 320, and the communication interface 330 can communicate with each other through an internal interface.

[0162] The embodiments of the present application provide a computer-readable storage medium, in which a computer program is stored. When the computer program runs on a computer, the method provided in the embodiments of the present application is implemented.

[0163] An embodiment of the present application also provides a chip, which includes a processor for calling and running instructions stored in a memory, so that a communication device equipped with the chip executes the method provided by the embodiment of the present application.

[0164] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected through an internal connection path. The processor is configured to execute code in the memory. When the code is executed, the processor is configured to execute the method provided by the embodiment of the application.

[0165] It should be understood that the above-mentioned processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor that supports the advanced reduced instruction set machine (ARM) architecture.

[0166] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may further include a non-volatile random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchlink dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).

[0167] In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0168] In the description of this specification, the descriptions referring to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this application. Moreover, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0169] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of this application, "a plurality of" means two or more, unless otherwise specifically defined.

[0170] Any process or method description represented in the flowchart or described in other ways herein can be understood to represent a module, segment, or portion of code including one or more executable instructions for implementing a specific logical function or process. And the scope of the preferred embodiments of this application includes additional implementations, where the functions may be executed in a substantially simultaneous manner or in the reverse order according to the functions involved, rather than in the order shown or discussed.

[0171] The logic and / or steps represented in the flowchart or described in other ways herein, for example, can be considered as a sequenced list of executable instructions for implementing a logical function, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in combination with these instruction execution systems, apparatuses, or devices.

[0172] It should be understood that each part of this application can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the method in the above embodiments can be completed by a program instructing relevant hardware, and this program can be stored in a computer-readable storage medium. When this program is executed, it includes one or a combination of the steps of the method embodiment.

[0173] In addition, each functional unit in various embodiments of the present application may be integrated into a processing module, may exist separately physically for each unit, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. When the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, an optical disc, or the like.

[0174] As described above, the foregoing are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present application can easily think of various changes or substitutions thereof, and these should all be covered by the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A permission control method based on a metamodel, characterized in that: include: Based on business needs, create an application, and use a metamodel to describe the page content of each front-end page of the application, and describe the permission definition information that needs to be pre-defined on each front-end page according to the metamodel standard definition; When the application is run, a meta-model engine is called to parse each of the front-end pages to obtain all definition information of each of the front-end pages, wherein all definition information includes permission definition information; Calling the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, persisting the permission authorization list in a database, and saving the permission authorization list in the meta-model engine; According to the permission authorization list, in the graphical interface of the application, for a specific user, user group, or role, a permission resource that meets their identity and needs is selected to complete the binding and allocation of permissions and obtain a permission binding relationship; Calling the metamodel engine to control corresponding authority resources based on the authority binding relationship; Wherein, when running the application, if a new permission control point needs to be added, the metamodel engine is called to inject the new permission control point into the permission authorization list, and then the permission authorization list is updated; According to the updated permission authorization list, the permission resources that meet the identity and needs of specific users, user groups and roles are selected again in the graphical interface of the application to complete the binding and allocation of permissions and obtain the permission binding relationship.

2. The method according to claim 1, characterized in that The page content of each front-end page of the application described by the metamodel includes: A plurality of page meta-models are defined on each of the front-end pages, wherein each of the page meta-models includes a plurality of component meta-models, and a hierarchical relationship exists between the plurality of component meta-models; A plurality of the page meta-models are described as the page content of each of the front-end pages.

3. The method according to claim 2, characterized in that The permission definition information that needs to be predefined is described according to the metamodel standard definition on each of the front-end pages, including: On each of the front-end pages, each metamodel is defined as an independent permission control point, and the way to enable permission definition for each metamodel is configured in code form or in a form in a low-code development interface to obtain the permission definition information, wherein each metamodel is a page metamodel or a component metamodel.

4. The method according to claim 2, characterized in that: Calling the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list includes: After calling the metamodel engine to group all metamodels of each of the front-end pages according to the applications to which they belong, a permission authorization list with a tree structure is constructed according to the hierarchical relationship between all metamodels to obtain the permission authorization list.

5. The method according to claim 1, characterized in that Calling the metamodel engine based on the permission binding relationship to control the corresponding permission resources includes: Calling the metamodel engine to perform user authentication based on the permission binding relationship, and taking the intersection permission range between the permission range defined by the scope and the permission range defined by the role as the permission authentication result; According to the authentication result, corresponding authority resources are controlled.

6. The method according to claim 5, characterized in that The method further comprises: In the process of calling the metamodel engine to perform user authentication based on the permission binding relationship, when verifying the permission of the corresponding metamodel, the permission of the entire hierarchical metamodel link where the corresponding metamodel is located is simultaneously verified.

7. The method according to any one of claims 1 to 6, characterized in that Calling the metamodel engine to inject the newly added permission control point into the permission authorization list includes: Invoke the service to dynamically generate incremental permission description information of the newly added permission control point; The meta-model engine is called to parse the incremental permission description information to obtain the permission definition information of the newly added permission control point, and then the permission definition information of the newly added permission control point is injected into the permission authorization list.

8. A permission control device based on a metamodel, characterized in that: include: A creation unit, used to create an application based on business requirements, and use a metamodel to describe the page content of each front-end page of the application, and describe the permission definition information that needs to be pre-defined on each front-end page according to the metamodel standard definition; A parsing unit, configured to call a meta-model engine to parse each of the front-end pages when the application is running, and obtain all definition information of each of the front-end pages, wherein all definition information includes permission definition information; A construction unit, used for calling the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, persistently saving the permission authorization list in a database, and saving the permission authorization list in the meta-model engine; A binding unit, configured to select permission resources that meet the identity and requirements of specific users, user groups and roles in the graphical interface of the application according to the permission authorization list, so as to complete the binding and allocation of permissions and obtain a permission binding relationship; A control unit, configured to call the metamodel engine to control corresponding authority resources based on the authority binding relationship; The construction unit is further used for: when running the application, if a new permission control point needs to be added, calling the metamodel engine to inject the new permission control point into the permission authorization list, and then updating the permission authorization list; The binding unit selects permission resources that meet the identity and needs of specific users, user groups and roles in the graphical interface of the application according to the updated permission authorization list to complete the binding and allocation of permissions and obtain a permission binding relationship.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory stores instructions, and the instructions are loaded and executed by the processor to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed on a computer, the method according to any one of claims 1 to 7 is implemented.

Images