Permission control method and device based on meta-model and storage medium

Abstract

The invention provides a permission control method and device based on a meta-model and a storage medium, and the method comprises the steps: creating an application based on a business demand, describing the page content of each front-end page of the application by adopting the meta-model, and defining and describing permission definition information needing to be predefined on each front-end page according to a meta-model standard; when the application is operated, calling the meta-model engine to execute the following steps: analyzing each front-end page to obtain all definition information of each front-end page, constructing the permission definition information of each front-end page into a permission authorization list, and persistently storing the permission authorization list into the database and the meta-model engine at the same time; according to the permission authorization list, corresponding permission resources are selected in the graphical interface to complete permission binding and distribution, a permission binding relation is obtained, and the corresponding permission resources are controlled based on the permission binding relation; when the application is operated, the meta-model engine is called to inject the required newly-added permission control point into the permission authorization list and then update the permission control point.

Description

Technical Field

[0001] The present application relates to the technical field of permission control, and in particular to a permission control method, device and storage medium based on a metamodel. Background Art

[0002] At present, the mainstream solution for permission control of software systems is to create and maintain permission point information based on pages. Developers embed corresponding permission point information in the code. When the software is running, it is controlled according to the pre-embedded logic. When the environment is migrated, the permission point information of 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 solutions, permission point information needs to involve actions such as cross-environment migration, and because the permission point information must be embedded in the code in advance, there is a problem that permission control points cannot be added or reduced when the software system is running. Summary of the invention

[0004] The embodiments of the present application provide a metamodel-based permission control method, device, and storage medium to solve the problems existing in the related technologies. The technical solutions are as follows: In a first aspect, an embodiment of the present application provides a permission control method based on a metamodel, comprising: 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.

[0005] In one embodiment, 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.

[0006] In one embodiment, the permission definition information that needs to be predefined is described according to the metamodel standard definition on each front-end page and includes: 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.

[0007] In one implementation, 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 front-end page 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.

[0008] In one implementation, calling the metamodel engine to control corresponding authority resources based on the authority binding relationship 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.

[0009] In one embodiment, 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.

[0010] In one implementation, 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.

[0011] In a second aspect, the embodiment of the present application further provides a permission control device based on a metamodel, including: 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.

[0012] In one embodiment, when the creation unit is used to describe the page content of each front-end page of the application using a metamodel, it is specifically used to: 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.

[0013] In one embodiment, when the creation unit is used to describe the permission definition information that needs to be predefined according to the metamodel standard definition on each front-end page, it is specifically used to: 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.

[0014] In one implementation, when the construction unit is used to call the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, it is specifically used to: After calling the metamodel engine to group all metamodels of each front-end page 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.

[0015] In one implementation, when the control unit is used to call the metamodel engine to control the corresponding permission resources based on the permission binding relationship, it is specifically used to: 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.

[0016] In one embodiment, the control unit is further configured to: 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.

[0017] In one implementation, when the construction unit is used to call the metamodel engine to inject the newly added permission control point into the permission authorization list, it is specifically used to: 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.

[0018] In a third aspect, an embodiment of the present application further provides a computer device, comprising: a memory and a processor, wherein the memory stores instructions, and the instructions are loaded and executed by the processor to implement a method in any one of the above-mentioned aspects, wherein the memory and the processor communicate with each other through an internal connection path.

[0019] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program runs on a computer, the method in any one of the above-mentioned embodiments is implemented.

[0020] The advantages or beneficial effects of the above technical solution include at least: (I) Integration and unification of permission implementation and permission definition: By utilizing metamodel technology, permission definition information is injected into the metamodel engine when the application is running, and permission control is implemented based on the relationship between permissions and users. This allows permission definition to be bundled with permission implementation, that is, the code contains both definition and implementation, and the implementation is the definition. For low-code scenarios, the action of migrating permission definition information across environments can be omitted, simplifying the development steps.

[0021] In addition, when migrating across environments, all permission information and logic migration can be completed by migrating only the code. In other words, in the scenario of environment migration, you only need to focus on upgrading the code itself, which improves data reliability during operation and maintenance / developer migration and enhances the security of permissions.

[0022] (II) Adding permission control points on demand during runtime: By utilizing metamodel technology, permission definition information is injected into the metamodel engine when the application is running. This supports online addition and deletion of permission definitions to dynamically add permission control logic during application runtime. Not only can authorization be performed based on the permission control points defined in advance in the project code, but permission control points for corresponding functions can also be dynamically created online as needed during project operation according to the needs of the project scenario, thereby improving the efficiency, flexibility and reliability of permission adaptation.

[0023] That is, when the application is running, flexible and reliable permission management can be achieved, and permission control logic can be dynamically added or reduced online, thereby improving the efficiency of permission development and operation and maintenance. In addition, permission control points can be added online and take effect immediately without the need for code development.

[0024] The above summary is for illustrative purposes 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 accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0026] Figure 1 A flowchart of a metamodel-based permission control method provided in an embodiment of the present application; Figure 2 An example diagram of a user interface of a front-end page provided in an embodiment of the present application; Figure 3 An example diagram of actual generated data of a front-end page provided in an embodiment of the present application; Figure 4 An example diagram of enabling permission control in a form configured through a low-code development interface provided in an embodiment of the present application; Figure 5 An example diagram of dynamically constructing a permission authorization list based on a comparison structure provided in an embodiment of the present application; Figure 6 An example diagram of binding and allocating permissions through a graphical interface provided in an embodiment of the present application; Figure 7 A structural block diagram of a metamodel-based permission control device provided in an embodiment of the present application; Figure 8 A structural block diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary and non-restrictive in nature.

[0028] In the related art, the current mainstream permission control scheme of the software system has the following two defects: (1) Separation of permission implementation and permission definition: First, create and maintain permission point information based on the page (i.e., permission definition), store the permission point information in the database, and then develop and embed the permission point information in the code (i.e., permission implementation). In this process, some problems will arise that the permission definition cannot be mapped. In addition, when migrating across environments, the database and the corresponding code version need to be migrated together.

[0029] (2) Permission control points cannot be increased or decreased during runtime: Permission configuration must rely on pre-defined permission point information for authorization binding, which will result in the inability to increase or decrease permission control points during runtime. However, during project development, it is often not possible to fully pre-define all the required permission point information, and it is necessary to fill in the gaps during business trial operation.

[0030] Based on this, the embodiment of the present application proposes a meta-model-based permission control solution to address the defects of the current mainstream permission control solutions for software systems.

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

[0032] Figure 1 FIG. 1 is a flow chart showing a method for controlling permissions based on a metamodel according to an embodiment of the present application. Figure 1 As shown, the method may include the following steps: S110. Based on business requirements, an application is created, and a metamodel is used to describe the page content of each front-end page of the application, and permission definition information that needs to be pre-defined is described on each front-end page according to the metamodel standard.

[0033] In one implementation, corresponding applications may be created based on different business requirements, so that different business requirements may be met through the corresponding applications.

[0034] In one embodiment, using a metamodel to describe the page content of each front-end page of an application may include: defining several page metamodels on each front-end page, wherein each page metamodel includes several component metamodels, and there is a hierarchical relationship between the several component metamodels; describing the several page metamodels as the page content of each front-end page.

[0035] It can be understood that, in the embodiment of the present application, the page development of the application is mainly implemented by generating a standard metamodel instance that conforms to the metamodel definition.

[0036] In specific implementation, the component metamodel can be used to describe specific page elements, that is, several component metamodels can include but are not limited to: tables, forms, buttons.

[0037] As an example, when a metamodel is used to define a button page element on a front-end page, its user interface (UI interface) can be as follows: Figure 2 As shown, the actual data generated can be Figure 3 shown.

[0038] In one embodiment, describing the permission definition information that needs to be predefined according to the metamodel standard definition on each front-end page may include: on each front-end page, defining each metamodel as an independent permission control point, and configuring each metamodel to enable permission definition in the form of code or in a low-code development interface to obtain permission definition information. Each metamodel is a page metamodel or a component metamodel. In other words, the process of defining permissions through a metamodel is to add content related to permission control to the data that conforms to the metamodel standard definition.

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

[0040] In the specific implementation, in the process of configuring the way to enable permission definition for each metamodel through code or configuration in the form of a low-code development interface, a description of the permission information can be added to the properties of the metamodel that needs to enable permission control, such as relevant information of the permission information, unique identifier of the permission control point, etc.

[0041] As an example, in the process of configuring each metamodel to enable permission definition in code, taking the metamodel for which permission control needs to be enabled as a page metamodel as an example, the following description of permission information can be added to the properties of the page metamodel through code: Type: Page metamodel Metamodel Id: xxxx Whether to enable permissions: Yes Permission description: Human Resources Management App – Employee Management Page Unique permission identification code: HR-EMPLOYEE-PAGE.

[0042] In this example, the permission unique identifier may not be necessary. If it does not need to be maintained, the metamodel instance Id may be used as the identification code by default.

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

[0044] In the embodiment of the present application, by executing step S110, all metamodel resources can be carried by the application, and one application can have several front-end pages and back-end physical models, which can better meet different business needs.

[0045] S120. When the application is running, the metamodel engine is called to parse each front-end page of the application to obtain all definition information of each front-end page.

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

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

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

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

[0050] S130, 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.

[0051] In one embodiment, calling the metamodel engine to construct the permission definition information of each front-end page into a permission authorization list may include: calling the metamodel engine to group all metamodels of each front-end page according to the applications to which they belong, and then constructing a tree-structured permission authorization list based on the hierarchical relationship between all metamodels to obtain the permission authorization list.

[0052] It can be understood that the metamodel engine will construct a permission authorization list according to the grouping relationship and hierarchical relationship between metamodels. Among them, by grouping all metamodels of each front-end page according to the application to which they belong, the metamodels configured to require authentication can be filtered out.

[0053] That is, in the embodiment of the present application, the permission authorization list is not immutable, and it can be dynamically updated with changes such as the installation and update of the application and the online release of the metamodel. In other words, the dynamic update of the permission authorization list can be implemented based on comparison, for example, Figure 5 As shown, this can be achieved by: (a) Newly installed applications with new authentication meta-models Compare the current permission authorization list with the metamodel in the new application, and identify the metamodels that do not exist in the stock metamodel set but exist in the incremental metamodel set as permission control points that need to be added.

[0054] (b) Update installed applications, which may add metamodels that require authentication, change the hierarchy of existing metamodels, or delete some metamodels that require authentication. Compare the current permission authorization list with the metamodel in the updated application. If a metamodel does not exist in the stock metamodel set of the application but exists in the updated metamodel set, the metamodel is used as a permission control point that needs to be added. Alternatively, if a metamodel has the same ID in the stock metamodel set of the application and in the updated metamodel set but different metamodel levels or permission names, the metamodel is modified. Alternatively, if a metamodel exists in the stock metamodel set of the application but does not exist in the updated metamodel set, the metamodel is deleted.

[0055] In specific implementation, by persisting the permission authorization list in the database, the permission authorization list can be displayed when authorizing users in scenarios where authentication is relatively low-frequency and performance requirements are not high.

[0056] In the specific implementation, by saving the permission authorization list in the metamodel engine, in the scenario with high authentication performance requirements, it is possible to verify whether the resource exists according to the requested resource ID, and return the verification result according to the authorization result, and there is no need for list display and range query.

[0057] That is, in the embodiment of the present application, by storing the permission authorization list in the database and the metamodel engine at the same time, the usage requirements of permission control in different scenarios can be met.

[0058] In actual 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 metamodels is recorded in the front-end page, the storage form in the metamodel engine is discrete and one-dimensional, which is not convenient for query and display. Based on this, the embodiment of the present application can conveniently display the authorized permissions to the user and retrieve the corresponding permission control points according to the conditions in actual use by executing step S130, so as to bind and take effect when configuring user permissions.

[0059] S140. 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.

[0060] In one implementation, after the metamodel engine is called to dynamically construct the permission authorization list, the permissions can be assigned and bound to the user / user group / role. For example, when the user / developer selects the permission resources that meet the identity and needs for a specific user, user group, and role in the graphical interface of the application according to the permission authorization list and saves it, the binding and assignment of permissions can be completed, and the permission binding relationship can be obtained.

[0061] For example, the user / developer completes Figure 6After performing the relevant selection operations shown and then saving, the binding and allocation of permissions can be completed to obtain the corresponding permission binding relationship.

[0062] S150: Calling the metamodel engine to control corresponding authority resources based on the authority binding relationship.

[0063] In one embodiment, calling the metamodel engine based on the permission binding relationship to control the corresponding permission resources may include: calling the metamodel engine to perform user authentication based on the permission binding relationship, and using 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; and controlling the corresponding permission resources based on the authentication result.

[0064] It can be understood that the specific permission verification logic executed by the metamodel engine depends on the allocation relationship between resources and resource users, that is, whether permissions are granted is determined based on the allocation results. 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 embodiment of the present application, in addition to roles, it can also be associated with users to implement the dimension of permission control.

[0065] In one embodiment, since there is a hierarchical relationship between metamodels, when calling the metamodel engine to perform user authentication based on the permission binding relationship, the permissions of the entire hierarchical metamodel link where the corresponding metamodel is located can be verified simultaneously when verifying the permissions of the corresponding metamodel.

[0066] For example, taking the corresponding metamodel as the new employee button metamodel, when verifying its permissions, the permissions of the following entire hierarchical metamodel link can be verified simultaneously: Human Resources APP metamodel - employee management page metamodel - employee management list metamodel - add employee button metamodel.

[0067] In this example, the prerequisite for determining whether you have the permission to the Add Employee Button metamodel is to have the permission to all ancestor metamodels on its hierarchical link. In other words, if you do not have the permission to the Human Resources APP metamodel, you cannot have the permission to the Add Employee Button (its descendant nodes).

[0068] In the embodiment of the present application, by executing step S150, the metamodel engine can decide whether to allow calling a certain service or display a certain button based on the permission binding relationship.

[0069] Although when developing pages in a low-code platform, you can decide which resources need to be controlled based on the actual business needs of the software product being developed. However, in actual applications, developers often face complex and changing business needs, and it is difficult to absolutely and accurately determine which resources need to be controlled during the development stage.

[0070] Based on this, in the scenario to which the embodiments of the present application are applicable, when running an application, if a new permission control point needs to be added, the following steps can be performed: S160. 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.

[0071] For example, permission authorization lists can be updated in the database and metamodel engine.

[0072] In one implementation, relevant managers can select the metamodel they need (such as a button) based on all definition information of each front-end page parsed by the metamodel engine, and the metamodel can be used as a new permission control point.

[0073] For example, a page has no permission control requirements when the initial upper limit is developed, but in the subsequent use of the page, the user proposes that the page needs permission control. In this case, the corresponding permission control points can be dynamically added.

[0074] In one embodiment, calling the metamodel engine to inject the newly added permission control point into the permission authorization list may include: calling a service to dynamically generate incremental permission description information of the newly added permission control point; calling the metamodel 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. After that, step S140 may be performed again.

[0075] Taking the above example as an example, by executing step S160 and then executing step S140 again, the page can have the ability of permission control.

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

[0077] In specific applications, the above-mentioned metamodel engine can be implemented using the metamodel engine in the Saiyi Gushen IIDP framework, or it can be implemented using other types of metamodel engines, which is not limited in the embodiments of the present application.

[0078] In summary, the metamodel-based permission control method provided in the embodiment of the present application can achieve the following effects by executing the above steps S110 to S160: (I) Integration and unification of permission implementation and permission definition: By utilizing metamodel technology, permission definition information is injected into the metamodel engine when the application is running, and permission control is implemented based on the relationship between permissions and users. This allows permission definition to be bundled with permission implementation, that is, the code contains both definition and implementation, and the implementation is the definition. For low-code scenarios, the action of migrating permission definition information across environments can be omitted, simplifying the development steps.

[0079] In addition, when migrating across environments, all permission information and logic migration can be completed by migrating only the code. In other words, in the scenario of environment migration, you only need to focus on upgrading the code itself, which improves data reliability during operation and maintenance / developer migration and enhances the security of permissions.

[0080] (II) Adding permission control points on demand during runtime: By utilizing metamodel technology, permission definition information is injected into the metamodel engine when the application is running. This supports online addition and deletion of permission definitions to dynamically add permission control logic during application runtime. Not only can authorization be performed based on the permission control points defined in advance in the project code, but permission control points for corresponding functions can also be dynamically created online as needed during project operation according to the needs of the project scenario, thereby improving the efficiency, flexibility and reliability of permission adaptation.

[0081] That is, when the application is running, flexible and reliable permission management can be achieved, and permission control logic can be dynamically added or reduced online, thereby improving the efficiency of permission development and operation and maintenance. In addition, permission control points can be added online and take effect immediately without the need for code development.

[0082] Figure 7 FIG. 1 shows a block diagram of a metamodel-based permission control device according to an embodiment of the present application. Figure 7 As shown, the device may include: The creation unit 210 is 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 to describe the permission definition information that needs to be pre-defined on each front-end page according to the metamodel standard definition; The parsing unit 220 is used to call the meta-model engine to parse each front-end page when running the application, and obtain all definition information of each front-end page, and all definition information includes permission definition information; A construction unit 230 is used to call the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, persist the permission authorization list in the database, and save the permission authorization list in the meta-model engine; The binding unit 240 is used to select 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 permission authorization list, so as to complete the binding and allocation of permissions and obtain the permission binding relationship; A control unit 250 is used to call the meta-model engine to control corresponding authority resources based on the authority binding relationship; The construction unit 230 is also 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.

[0083] In one implementation, when the creation unit 210 is used to describe the page content of each front-end page of the application using the metamodel, it is specifically used to: A plurality of page metamodels are defined on each front-end page, wherein each page metamodel includes a plurality of component metamodels, and a hierarchical relationship exists between the plurality of component metamodels; Several page meta-models are described as the page content of each front-end page.

[0084] In one implementation, when the creation unit 210 is used to describe the permission definition information that needs to be predefined according to the metamodel standard definition on each front-end page, it is specifically used to: On each front-end page, 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 the form of a low-code development interface to obtain permission definition information, where each metamodel is a page metamodel or a component metamodel.

[0085] In one implementation, when the construction unit 230 is used to call the meta-model engine to construct the permission definition information of each front-end page into a permission authorization list, it is specifically used to: After calling the metamodel engine to group all metamodels of each front-end page 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 a permission authorization list.

[0086] In one implementation, when the control unit 250 is used to call the metamodel engine to control the corresponding permission resources based on the permission binding relationship, it is specifically used to: Call the metamodel engine to perform user authentication based on the permission binding relationship, and use the intersection of the permission range defined by the scope and the permission range defined by the role as the permission authentication result; According to the authentication results, the corresponding permission resources are controlled.

[0087] In one embodiment, the control unit 250 is further configured to: 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.

[0088] In one implementation, when the construction unit 230 is used to call the metamodel engine to inject the newly added permission control point into the permission authorization list, it is specifically used to: Call the service to dynamically generate incremental permission description information for newly added permission control points; The meta-model engine is called to parse the incremental permission description information, 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.

[0089] The functions of each unit in the meta-model-based permission control device of the embodiment of the present application can be found in the corresponding description in the above method, and will not be repeated here.

[0090] Figure 8 FIG. 2 shows a block diagram of a computer device according to an embodiment of the present application. Figure 8 As shown, the computer device includes: a memory 310 and a processor 320. The memory 310 stores instructions, and the instructions are loaded and executed by the processor 320 to implement the metamodel-based permission control method in the above embodiment. The number of the memory 310 and the processor 320 can be one or more.

[0091] The computer device also includes: The communication interface 330 is used to communicate with external devices and perform data exchange transmission.

[0092] 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 connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0093] 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.

[0094] An embodiment of the present application provides 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 embodiment of the present application is implemented.

[0095] An embodiment of the present application also provides a chip, which includes a processor for calling and executing 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.

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

[0097] It should be understood that the processor may be a central processing unit (CPU), or 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. A 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 RISC Machines (ARM) architecture.

[0098] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may also 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 RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct rambus RAM (DR RAM).

[0099] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can 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 process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0100] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0101] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0102] Any process or method description in the flow chart or otherwise described herein can be understood to represent a module, fragment or portion of a code including one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiment of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0103] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which can be embodied 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 system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.

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

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

[0106] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on 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.

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 front-end page 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.

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