A permission management method, an electronic device, and a computer readable medium

Abstract

The application discloses a permission management method, an electronic device and a computer readable medium, and relates to the technical field of permission management, and comprises the following steps: in the case that it is detected that a project source code file is changed, performing syntax tree analysis on the project source code file to obtain an analysis result; the project source code file comprises a routing configuration file; taking the analysis result as an abstract syntax tree corresponding to the project source code file, performing traversal processing on the abstract syntax tree to obtain a plurality of permission wrapper components; extracting a plurality of permission configuration information corresponding to the project source code file from the routing configuration file and the permission wrapper components; generating a permission identifier corresponding to each permission configuration information, and in the case that the permission identifier is repeated, generating a new permission identifier, and storing the new permission identifier and the corresponding permission configuration information to a data file library. The application can avoid permission identifier repetition.

Description

Technical Field

[0001] This invention relates to the field of access control technology, specifically to an access control method, an electronic device, and a computer-readable medium. Background Technology

[0002] Business systems that handle complex tasks typically involve numerous functional modules. For users, the tasks they handle may only involve some of these modules; therefore, it's sufficient to assign users access permissions to only those modules. However, for some complex business scenarios, different users may have different permissions for the same module.

[0003] Traditional access control involves developers manually configuring permission identifiers and maintaining multiple permission configuration files. This approach is not only labor-intensive but also frequently results in discrepancies between permission configurations and user accounts after system upgrades. Summary of the Invention

[0004] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a permission management method, an electronic device, and a computer-readable medium, which has the advantage of avoiding duplicate permission IDs.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] An access control method, comprising:

[0007] If a change is detected in the project source code file, a syntax tree parsing is performed on the project source code file to obtain the parsing result; the project source code file includes a routing configuration file;

[0008] Using the parsing result as an abstract syntax tree corresponding to the project source code file, the abstract syntax tree is traversed to obtain multiple permission wrapper components;

[0009] Extract multiple permission configuration information corresponding to the project source code file from the routing configuration file and the permission wrapper component;

[0010] Generate permission identifiers corresponding to each permission configuration information, and check whether the permission identifiers are duplicated;

[0011] If the permission identifier is duplicated, a new permission identifier is generated, and the new permission identifier and the corresponding permission configuration information are stored in the data file library.

[0012] Optionally, the step of generating permission identifiers corresponding to each permission configuration information includes:

[0013] Generate a universally unique identifier corresponding to the permission configuration information;

[0014] When the project source code file includes source code files of multiple business systems, the business system identifier of the business system and the universally unique identifier corresponding to the permission configuration information corresponding to each business system shall be used as the permission identifier.

[0015] In the case where the project source code file contains at most one source code file of a business system, the universally unique identifier corresponding to the permission configuration information shall be used as the permission identifier.

[0016] Optionally, the step of extracting multiple permission configuration information corresponding to the project source code file from the routing configuration file and the permission wrapper component includes:

[0017] Determine route permissions using the group identifier in the permission wrapper component;

[0018] Button permissions are determined by the button identifier in the permission wrapper component;

[0019] Extract routing permissions from the routing configuration file.

[0020] Optionally, after storing the new permission identifier and the permission configuration information to the data file library, the method further includes:

[0021] Generate a permission enumeration for the permission identifiers and permission configuration information in the data file library;

[0022] Based on the permission type, the permission enumeration and the metadata of the permission enumeration are stored in the corresponding enumeration file.

[0023] Optionally, the permission configuration information includes permission function names, and the step of generating a permission enumeration based on the permission identifier in the data file library and the permission configuration information includes:

[0024] For the permission identifier and the permission function name in the data file library, the permission identifier is used as an enumeration value and the permission function name is used as an enumeration key.

[0025] Using the enumeration value and the enumeration key, a permission enumeration is generated.

[0026] Optionally, the enumeration file includes a route enumeration file, a group enumeration file, and a button enumeration file. The step of storing the permission enumeration and its metadata into the corresponding enumeration file based on the permission type includes:

[0027] When the permission type is routing permission, the permission enumeration and the metadata of the permission enumeration are stored in the routing enumeration file;

[0028] When the permission type is group permission, the permission enumeration and the metadata of the permission enumeration are stored in the group enumeration file;

[0029] When the permission type is button permission, the permission enumeration and the metadata of the permission enumeration are stored in the button enumeration file.

[0030] Optionally, after performing syntax tree parsing on the project source code file and obtaining the parsing result upon detecting a change in the project source code file, the method further includes:

[0031] The parsing result is used as an abstract syntax tree corresponding to the project source code file. The abstract syntax tree is parsed to determine the dependencies between business components.

[0032] Based on the aforementioned dependencies, a business component dependency graph is constructed;

[0033] Recursively analyze the dependency graph of the business components and take the business components that have a usage relationship with the permission wrapper as the first target business components;

[0034] A bidirectional mapping relationship is constructed based on the usage relationship between the first target business component and the permission identifier.

[0035] Optionally, after constructing the bidirectional mapping relationship based on the usage relationship between the first target business component and the permission identifier, the method further includes:

[0036] If the permission configuration information changes, the changed permission configuration information will be used as the target permission configuration information.

[0037] Based on the target permission identifier of the target permission configuration information, query the bidirectional mapping relationship to determine the second target business component corresponding to the target permission identifier;

[0038] The permissions of the second target business component are updated using an integrated hot update mechanism.

[0039] In a second aspect, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the permission management method described in any of the preceding claims.

[0040] Thirdly, the present invention also provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the permission management method described in any of the preceding claims.

[0041] The core action of system iteration and upgrade is to modify the source code, such as adding routes, modifying permission wrapper components, or adjusting the logic of functional modules. Under the traditional manual configuration method, the core reason why the permission configuration does not match the account after system iteration and upgrade is that the actual permission logic in the modified source code is disconnected from the manually maintained permission configuration. This can be broken down into three underlying reasons:

[0042] Reason 1: Developers manually maintain permission configuration files offline, which is a separate process from system iteration and upgrades. It is impossible to guarantee synchronous updates. In other words, developers are focused on source code development and are prone to missing, delaying, or incorrectly modifying permission configurations, ultimately leading to a mismatch between account permissions and the iterated system.

[0043] Reason 2: The traditional method of configuring permissions involves developers manually writing permission configuration files. This manual writing of permission configuration files is equivalent to a secondary transcription, which is prone to errors during the transcription process.

[0044] Reason 3: System iteration and upgrades inevitably involve the addition, deletion, and modification of functions, but traditional manual configuration cannot detect the addition and deletion of source code.

[0045] Based on this, this invention first strongly binds the update of permission configuration to the iteration of project source code files. That is, whenever the source code is iterated, the subsequent parsing, extraction, and update processes are automatically triggered, preventing situations where permission configuration is forgotten to be updated after the source code iteration is completed. This fundamentally ensures that the timing of permission configuration updates is completely synchronized with source code iteration. Furthermore, when the project source code files are updated, this invention directly extracts permission configuration information from the routing configuration file and permission wrapper component. Since the extracted permission configuration information is the actual effective permission logic in the project source code files, rather than second-hand information interpreted manually, there is no need for developers to manually transcribe it, completely avoiding interpretation errors, coding errors, and omissions of details. Even further, after extracting the permission configuration information, permission identifiers are automatically generated based on the extracted permission configuration information, avoiding errors from manual coding. Moreover, the permission identifiers are dynamically generated based on the permission configuration information. When the permission configuration information changes during iteration, new permission identifiers are automatically generated and synchronously updated to the data file library. User account permission allocation will take effect based on the new identifier, ensuring a one-to-one correspondence between the permission identifier and the permission configuration logic. During iteration, the permission identifier is updated synchronously with the configuration, preventing situations where accounts holding old permission identifiers are unable to operate. In other words, this invention is a natural product of permission configuration in project source code files. Developers no longer need to manually maintain the configuration. Instead, through techniques such as syntax tree parsing, permission logic is directly read from the source code, and permission configuration is automatically generated, updated, and stored. This not only completely solves the core contradiction of inconsistency between permissions and accounts after system iteration, but also allows developers to focus on source code development, freeing them from manual permission configuration and reducing labor costs.

[0046] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0047] The present invention will be further described below with reference to the accompanying drawings:

[0048] Figure 1 A flowchart of one embodiment of the permission management method provided by the present invention;

[0049] Figure 2 This is a schematic diagram of the process for generating permission identifiers corresponding to each permission configuration information provided by the present invention;

[0050] Figure 3This is a flowchart illustrating the process of generating a permission enumeration using the permission identifier and the permission configuration information provided by the present invention.

[0051] Figure 4 A schematic diagram illustrating the process of generating a permission enumeration using permission identifiers and permission function names provided by the present invention.

[0052] Figure 5 This is a schematic diagram illustrating the process of constructing a two-way mapping relationship between business components and permissions provided by the present invention;

[0053] Figure 6 A block diagram illustrating one embodiment of the electronic device provided by the present invention;

[0054] Figure 7 This is a schematic diagram of a computer-readable medium provided by the present invention.

[0055] Explanation of reference numerals in the attached figures:

[0056] 101: Processor; 102: Memory; 103: I / O interface; 104: Bus. Detailed Implementation

[0057] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0058] The terms "an embodiment," "example," or "trademark" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this invention. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0059] As a first aspect of the present invention, a permission management method is provided, such as... Figure 1 As shown, the method includes:

[0060] In step S110, if a change is detected in the project source code file, the project source code file is parsed using a syntax tree to obtain the parsing result.

[0061] The project source code files include routing configuration files.

[0062] Specifically, the electronic device stores the project source code files and is equipped with a chokidar (file monitoring mechanism). When the chokidar detects a change in the project source code files, the electronic device can initiate the Abstract Syntax Tree (AST) parsing process, calling the @babel / parser tool to parse the TypeScript / JSX files in the project source code files and obtain the parsing results.

[0063] In step S120, the parsing result is used as the abstract syntax tree corresponding to the project source code file. The abstract syntax tree is traversed to obtain multiple permission wrapper components.

[0064] In step S130, multiple permission configuration information corresponding to the project source code file are extracted from the routing configuration file and the permission wrapper component.

[0065] In this embodiment, the permission configuration information includes permission type information, permission function name, and permission location information in the project source code file. Permission types include routing permissions, group permissions, and button permissions. Routing permissions are page-level permissions that control whether a user can access a specific page; group permissions are module-level permissions that control whether a group of related functions within a page is visible or available, and a page can contain multiple group permissions. Button permissions are operation-level permissions that control whether a specific operation button can be clicked or seen, and a group permission can contain multiple button permissions.

[0066] After obtaining the parsing results, the parsing results are used as an abstract syntax tree corresponding to the project source code file. The nodes of the abstract syntax tree are traversed, and the component named "PermissionWrapper" in the JSXElement type is identified from the syntax tree nodes. Group permissions and button permissions are extracted from the props list of the permission wrapper component based on the group configuration information and button configuration information. The paths of the group permissions and button permissions in the project source code file are recorded. That is, group permissions are determined by the group identifier in the permission wrapper component; button permissions are determined by the button identifier in the permission wrapper component. Similarly, route permissions are used to control whether a page route is visible to the user. They are usually implemented in the route configuration file by wrapping the route component with a permission wrapper. Therefore, when parsing the project source code file using the AST, the route configuration file should be scanned extensively to identify configurations with the "route" or "router" attribute in the permission wrapper component, thereby obtaining the route permissions. The paths of the route permissions in the project source code file are also recorded, that is, the route permissions are extracted from the route configuration file. After obtaining routing permissions, group permissions, button permissions, and the paths of each permission in the project source code file, a mapping relationship between permission identifiers and paths can be established based on the permission identifiers of each permission, so as to quickly determine the location of each permission in the project source code file.

[0067] In step S140, a permission identifier corresponding to each permission configuration information is generated, and it is detected whether the permission identifier is duplicated.

[0068] After obtaining the permission configuration information, permission identifiers corresponding to each permission configuration can be generated. The electronic device can store a list of permission identifiers, and after generating the permission identifiers corresponding to each permission configuration, it can check whether there are duplicate permission identifiers in the list.

[0069] It's worth noting that a large front-end project can include multiple business systems. For example, a large e-commerce management project might include user management systems, order management systems, product management systems, and other business systems. Similarly, a large financial management project might include transaction systems, risk control systems, auditing systems, and other business systems. Therefore, the corresponding source code files for a large front-end project could include source code files for multiple business systems.

[0070] When the project source code files include source code files from multiple business systems, each business system has corresponding permission configuration information. To avoid duplicate permission identifiers between different business systems, and also to clarify permission ownership and avoid permission confusion across systems, further, as an optional implementation method, refer to... Figure 2 As shown, Figure 2 A flowchart illustrating the process of generating permission identifiers corresponding to each permission configuration information is provided. Step S140 specifically includes:

[0071] In step S210, a universally unique identifier corresponding to the permission configuration information is generated.

[0072] In step S220, when the project source code file includes source code files of multiple business systems, the business system identifier of each business system and the universally unique identifier corresponding to the permission configuration information are used as the permission identifier.

[0073] In step S230, if the project source code file contains at most one source code file of a business system, the universally unique identifier corresponding to the permission configuration information is used as the permission identifier.

[0074] Specifically, after obtaining the permission configuration information, it can be standardized, such as by unifying the format of the extracted permission configuration information and removing special characters, to ensure consistent naming styles among different developers. After standardizing the permission configuration information, a universally unique identifier (UUID) algorithm can be used to generate a universally unique identifier corresponding to each permission configuration information.

[0075] After generating a universally unique identifier for permission configuration information, the permission identifiers for each configuration information can be adaptively adjusted based on the number of source code files for business systems in the project source code file. Specifically, if the project source code file includes source code files for multiple business systems, the business system identifier of each business system and the universally unique identifier corresponding to the permission configuration information will be used as the permission identifier. If the project source code file contains only one source code file for a business system, the universally unique identifier corresponding to the permission configuration information will be used as the permission identifier.

[0076] Furthermore, for the permission identifiers generated for each permission configuration information in the source code files of each business system, the PermissionTreePlugin in the Webpack tool can be called to generate a permission tree. For example, the permission tree of the transaction system, the permission tree of the risk control system, and the permission tree of the audit system are composed of routing permissions, page group permissions, and button permissions, respectively. The permission tree of the transaction system, the permission tree of the risk control system, and the permission tree of the audit system can aggregate the permissions in the project source code files to form a complete permission forest.

[0077] In this embodiment, when the project source code file contains multiple business systems such as a transaction system, risk control system, and audit system, different business systems may have permissions with similar functions. For example, both the transaction system and the risk control system have a submit button, so they may both have permissions="submit". If only the universally unique identifier of the permission configuration information is used as the permission identifier, although the universally unique identifier itself has an extremely low probability of duplication, it is not possible to intuitively distinguish the business system to which the permission belongs. For example, the universally unique identifiers of two submit buttons may only have slight differences, making it difficult to manually identify the attribution. Based on this, this embodiment obtains the permission identifier corresponding to each permission configuration information through the business system identifier and the universally unique identifier. This can not only ensure the uniqueness of the permission identifier, but also clearly indicate the attribution of the permission through the business system identifier, avoiding cross-system permission confusion, such as mistakenly assigning the submit permission of the risk control system to a user of the transaction system.

[0078] In step S150, if the permission identifier is duplicated, a new permission identifier is generated, and the new permission identifier and the corresponding permission configuration information are stored in the data file library.

[0079] After querying the list of permission identifiers to see if there are duplicate permission identifiers, if the permission identifiers are duplicated, a new permission identifier can be generated through steps S210-S220. If the new permission identifier is not duplicated, the new permission identifier and the corresponding permission configuration information are stored in the data file library. Conversely, if the permission identifiers are not duplicated, the permission identifier and the corresponding permission configuration information can be stored in the data file library.

[0080] When storing new permission identifiers and their corresponding permission configuration information in the data file library, to facilitate management, these identifiers can be stored in different data file libraries based on their permission types. For example, if the permission configuration information is for routing permissions, the new permission identifier and its corresponding configuration information are stored in the routing data file library, specifically in the `router map.json` file. If the permission configuration information is for group permissions, the new permission identifier and its corresponding configuration information are stored in the group data file library, specifically in the `group map.json` file. If the permission configuration information is for button permissions, the new permission identifier and its corresponding configuration information are stored in the button data file library, specifically in the `buttonmap.json` file.

[0081] The core action of system iteration and upgrade is to modify the source code, such as adding routes, modifying permission wrapper components, or adjusting the logic of functional modules. Under the traditional manual configuration method, the core reason why the permission configuration does not match the account after system iteration and upgrade is that the actual permission logic in the modified source code is disconnected from the manually maintained permission configuration. This can be broken down into three underlying reasons:

[0082] Reason 1: Developers manually maintain permission configuration files offline, which is a separate process from system iteration and upgrades. It is impossible to guarantee synchronous updates. In other words, developers are focused on source code development and are prone to missing, delaying, or incorrectly modifying permission configurations, ultimately leading to a mismatch between account permissions and the iterated system.

[0083] Reason 2: The traditional method of configuring permissions involves developers manually writing permission configuration files. This manual writing of permission configuration files is equivalent to a secondary transcription, which is prone to errors during the transcription process.

[0084] Reason 3: System iteration and upgrades inevitably involve the addition, deletion, and modification of functions, but traditional manual configuration cannot detect the addition and deletion of source code.

[0085] Based on this, this invention first strongly binds the update of permission configuration to the iteration of project source code files. That is, whenever the source code is iterated, the subsequent parsing, extraction, and update processes are automatically triggered, preventing situations where permission configuration is forgotten to be updated after the source code iteration is completed. This fundamentally ensures that the timing of permission configuration updates is completely synchronized with source code iteration. Furthermore, when the project source code files are updated, this invention directly extracts permission configuration information from the routing configuration file and permission wrapper component. Since the extracted permission configuration information is the actual effective permission logic in the project source code files, rather than second-hand information interpreted manually, there is no need for developers to manually transcribe it, completely avoiding interpretation errors, coding errors, and omissions of details. Even further, after extracting the permission configuration information, permission identifiers are automatically generated based on the extracted permission configuration information, avoiding errors from manual coding. Moreover, the permission identifiers are dynamically generated based on the permission configuration information. When the permission configuration information changes during iteration, new permission identifiers are automatically generated and synchronously updated to the data file library. User account permission allocation will take effect based on the new identifier, ensuring a one-to-one correspondence between the permission identifier and the permission configuration logic. During iteration, the permission identifier is updated synchronously with the configuration, preventing situations where accounts holding old permission identifiers are unable to operate. In other words, this invention is a natural product of permission configuration in project source code files. Developers no longer need to manually maintain the configuration. Instead, through techniques such as syntax tree parsing, permission logic is directly read from the source code, and permission configuration is automatically generated, updated, and stored. This not only completely solves the core contradiction of inconsistency between permissions and accounts after system iteration, but also allows developers to focus on source code development, freeing them from manual permission configuration and reducing labor costs.

[0086] It's important to note that during the compilation of permission configuration information, the permission identifier is hard-coded into the code as a plain string. Since TypeScript's core advantage is static type checking, it can identify type errors during the code writing and compilation phases, such as variable type mismatches or calls to non-existent functions. However, strings are weakly typed, so TypeScript cannot detect errors during the code writing and compilation phases. Errors or system problems only occur at runtime when the program attempts to use this incorrect permission identifier. Therefore, to detect errors during the compilation phase of permission configuration information, further reference... Figure 3 , Figure 3 To illustrate the flowchart for generating a permission enumeration using the permission identifier and the permission configuration information, after step S150, the following steps are also included:

[0087] In step S310, a permission enumeration is generated for the permission identifiers and permission configuration information in the data file library.

[0088] In this embodiment, permission enumeration can be a type-safe mechanism that associates permission identifiers with permission names having specific meanings. The permission configuration information includes permission function names. Therefore, further, as an optional real-time method, referring to Figure 4 as shown in Figure 4 FIG. is a schematic flowchart of generating permission enumeration by using a permission identifier and the permission function name. Step S310 specifically includes:

[0089] In step S410, for the permission identifier and the permission function name in the data file library, the permission identifier is used as an enumeration value, and the permission function name is used as an enumeration key;

[0090] In step S420, a permission enumeration is generated by using the enumeration value and the enumeration key.

[0091] Specifically, for each permission identifier and the corresponding permission function name in the data file library, the permission identifier can be used as an enumeration value, and the permission function name can be used as an enumeration key. Finally, a permission enumeration is generated by using the enumeration value and the enumeration key. Subsequently, when developers perform code compilation on permissions, they can directly use the enumeration key for code compilation instead of directly using the enumeration value.

[0092] For example, when the permission identifier is 550e8400-e29b-41d4-a716-446655440001 and the corresponding permission function name is "USERLISTVIEW", and the permission identifier is 550e8400-e29b-41d4-a716-446655440002 and the corresponding permission function name is "USER_CREATE", a permission enumeration "typescriptexport enumUserPermissionEnum {USERLISTVIEW = "550e8400-e29b-41d4-a716-446655440001",USER_CREATE = "550e8400-e29b-41d4-a716-446655440002}" can be generated. That is, when developers create permissions for users to view the user list, they directly use "<PermissionWrapper permission={UserPermissionEnum.USER_LIST_VIEW}", rather than the permission identifier. And after developers call the corresponding permission enumeration, they can check whether the permission references in the code are legal through the development assistance plugin (DevHelperPlugin) in the Webpack tool, and output permission debugging information through an electronic device to facilitate developers to quickly locate problems.

[0093] In step S320, based on the permission type, the permission enumeration and the metadata of the permission enumeration are stored in the corresponding enumeration file.

[0094] In this embodiment, the metadata includes the generation time of the permission enumeration, the data source, complete TypeScript type annotations, and JSDoc comments. The enumeration files include route enumeration files, group enumeration files, and button enumeration files.

[0095] After obtaining the permission enumeration, to facilitate its management, the permission enumeration and its metadata can be stored according to the permission type. Specifically, if the permission type is routing permission, the permission enumeration and its metadata are stored in the routing enumeration file; if the permission type is group permission, the permission enumeration and its metadata are stored in the group enumeration file; and if the permission type is button permission, the permission enumeration and its metadata are stored in the button enumeration file.

[0096] After storing the permission enumerations in the corresponding enumeration files, if new permissions are added later, a permission enumeration corresponding to the new permissions can be generated and stored in the corresponding enumeration files. That is, the enumeration files do not need to be fully regenerated every time. Only when the permission configuration changes, the affected enumeration files are regenerated. This reduces unnecessary file processing and project build time and improves development efficiency.

[0097] In this embodiment, after extracting the permission configuration information, the permission identifier is used as the enumeration value, and the corresponding permission function name is used as the enumeration key to generate enumeration permissions. When developers compile the permission configuration information, they can directly use the enumeration key to compile the code instead of directly using the enumeration value. Since the enumeration key is strongly typed, TypeScript can detect errors during the code writing and compilation stages by using the enumeration value to compile the permission code. This avoids the situation where an error is thrown or the system causes problems when the program tries to use the wrong permission identifier at runtime, thereby improving the stability of the front-end system.

[0098] Understandably, in the source code files of medium to large-scale front-end projects, the dependencies between business components such as page components, layout components, and style components are often very complex, and a single permission may be scattered across multiple business components. To clarify the usage relationship between business components and permissions, the traditional approach is for developers to manually record the reference relationships between business components and permissions. However, with iterations, this recording is easily outdated. For example, permission references may be modified after component refactoring but the records are not updated, leading to a disconnect between permission configuration and actual usage. For instance, a permission may be deleted, but some business components still depend on it, causing errors in the production environment; or after adding a permission, a business component that needs to be associated may be missed, resulting in functional abnormalities. Therefore, to achieve traceable, predictable, and efficient permission management, further reference... Figure 5 As shown, Figure 5 To illustrate the process of establishing a two-way mapping relationship between business components and permissions, after step S150, the following is also included:

[0099] In step S510, the parsing result is used as the abstract syntax tree corresponding to the project source code file, and the abstract syntax tree is parsed to determine the dependencies between business components.

[0100] In step S520, a business component dependency graph is constructed based on the dependency relationship.

[0101] In step S530, the dependency graph of the business components is recursively analyzed, and the business components that have a usage relationship with the permission wrapper are taken as the first target business components.

[0102] In step S540, a bidirectional mapping relationship is constructed based on the usage relationship between the first target business component and the permission identifier.

[0103] Specifically, by using AST to parse all import / export statements in the project source code file, the reference relationships between business components can be identified, such as component A depending on component B, component B depending on component C, and a visual business component dependency graph can be formed based on the dependency relationships between business components.

[0104] After obtaining the business component dependency graph, for each business component in the graph, the code of that business component is parsed to determine whether it directly uses a permission wrapper. If a permission wrapper is used, that business component is taken as the first target business component. Based on the dependencies between that business component and other business components, the aforementioned operation is repeated for components with dependencies, recursively, until all business components in the business component dependency graph have been traversed, including deeply nested components of 10 levels or more. Finally, the business component that uses the permission wrapper is taken as the first target business component. In other words, the business component dependency graph is recursively analyzed, and business components that have a usage relationship with the permission wrapper are taken as the first target business components.

[0105] After obtaining the first target business component, for each first target business component, the corresponding permission identifier can be determined according to the permission wrapper used by the first target business component, and a two-way mapping relationship can be constructed according to the correspondence between the first target business component and the permission identifier.

[0106] After establishing the bidirectional mapping relationship, hook functions or configuration file monitoring mechanisms can be used to detect whether the permission configuration information has changed. Upon detecting a change in the permission configuration information, the changed permission configuration information is used as the target permission configuration information. Based on the target permission identifier of the target permission configuration information, the bidirectional mapping relationship is queried to determine the second target business component corresponding to the target permission identifier. After obtaining the second target business component, its permissions can be updated. To improve development efficiency and reduce waiting time during development, a hot integration update mechanism can be used to update the permissions of the second target business component to avoid restarting the development server. That is, as another optional implementation, after step S640, the method further includes: if the permission configuration information changes, using the changed permission configuration information as the target permission configuration information; querying the bidirectional mapping relationship based on the target permission identifier of the target permission configuration information to determine the second target business component corresponding to the target permission identifier; and updating the permissions of the second target business component using an integrated hot update mechanism.

[0107] In this embodiment, a two-way mapping relationship between business components and permissions is constructed. Compared with the inefficient traditional method of manually recording permission associations, on the one hand, developers can quickly locate all business components using the permission through permission identifiers. For example, when querying the order:edit permission, the associated business components such as EditButton and OrderModal are automatically returned without having to check each file. On the other hand, all the permissions required by a business component can be traced back through the business component. For example, when viewing the OrderPage component, the permissions it depends on, such as order:view and order:edit, are obtained simultaneously, which greatly reduces the cost of permission sorting when developing new features and the cost of knowledge transfer when iterating old systems.

[0108] In addition, when permission configurations are modified, such as adding or deleting permissions or adjusting permission logic, all business components that need to be updated synchronously can be quickly identified. For example, when deleting the user:delete permission, the system automatically locates related business components such as the delete button in UserTable and the delete pop-up in UserDetail, avoiding online failures caused by human oversight. Simultaneously, through the hot integration update mechanism, the testing scope can be narrowed from full regression testing to the affected business components, reducing testing time by more than 60%. This reduces testing resource consumption and the potential risks to system stability from permission changes, ensuring the reliability of the system during permission iteration.

[0109] To facilitate better understanding, two specific examples are provided below.

[0110] Example 1:

[0111] In e-commerce management projects, multiple business systems are included, such as user management systems, order management systems, and product management systems. Each system has complex access control requirements. Traditionally, developers manage permissions through the following steps:

[0112] Step 1: Manually define the permission identifier for each permission, such as USERLISTVIEW, ORDERCREATE, PRODUCTEDIT;

[0113] Step 2: Hardcode the permission identifier string directly in the business component, such as PermissionWrapperpermission="USER_LIST_VIEW">. If the permission identifier is misspelled, such as USER_LIST_VEW, it will be difficult to find during the development phase.

[0114] Step 3: All permission IDs need to be manually recorded and ensured to be unique. When permissions are added or deleted, the configuration file needs to be manually updated.

[0115] Step 4: If a permission identifier needs to be modified, such as changing USER_LIST_VIEW to USER_VIEW, you need to manually find all business components that use this permission identifier and modify them one by one.

[0116] This embodiment manages permissions through the following steps, using the user management module as an example:

[0117] Step 1: Developers write components with access control. In components of the user management module, such as UserList.tsx, the user list page, developers use the PermissionWrapper component to wrap elements that need access control, such as the user list table. However, there is no need to manually define permission identifiers; they only need to mark the purpose of the permission through semantic names.

[0118] Step 2: Use an AST parsing tool to batch scan all .tsx files in the project source code, locate all code locations that use the PermissionWrapper component, and extract the values ​​of its permission attributes, such as USER_LIST_VIEW, from the PermissionWrapper component.

[0119] Step 3: Use a universally unique identifier algorithm to automatically generate universally unique identifiers corresponding to each permission configuration information, ensuring that the universally unique identifiers are not duplicated. For example, the universally unique identifier for the permission USER_LIST_VIEW is 550e8400-e29b-41d4-a716-446655440001.

[0120] Step 4: Automatically generate a permission enumeration based on the permission identifier and permission function name, and associate the permission function with a universally unique identifier; for example, typescript export enum UserPermissionEnum {USERLISTVIEW = "550e8400-e29b-41d4-a716-446655440001",USER_CREATE = "550e8400-e29b-41d4-a716-446655440002"};

[0121] Step 5: Developers use enumerations to update the business component code and complete the permission reference, such as... <permissionwrapper permission="{UserPermissionEnum.USER_LIST_VIEW}">.

[0122] In this example, compared to related technologies where developers manually write permission identifiers, this example extracts permission configuration information from the modified project source code files, automatically generates permission identifiers corresponding to the permission configuration information, and automatically compares them with all existing permission identifiers in the database. If a duplicate is found, a new permission identifier is immediately generated and the associated configuration is updated, eliminating the need for manual intervention. This avoids oversights in manual memorization, verification, and modification, thus preventing duplicate, missing, or inconsistent permission IDs and simplifying the permission management process. However, since `permission="USER_LIST_VIEW"` directly uses a string literal, this permission identifier is an unvalidated string. Developers need to manually input the complete permission identifier, relying entirely on manual spelling accuracy, making it difficult to detect spelling errors during project development. Therefore, this example uses a TypeScript enumeration member: `permission={UserPermissionEnum.USER_LIST_VIEW}`. Permission values ​​come from a system-generated enumeration (UserPermissionEnum), which developers can reference using "enumeration.member name" without having to manually enter the string, thus avoiding spelling errors.

[0123] Example 2:

[0124] In large-scale financial management projects, which include multiple business systems such as trading systems, risk control systems, and auditing systems, the amount management project can be divided into a main project and sub-projects to achieve the same access control over multiple business systems. The sub-projects serve as the access control center and include the trading system, risk control system, and auditing system.

[0125] For each business system in a large-scale financial management project, the aforementioned operations can be used to extract permission configuration information and generate permission identifiers corresponding to each permission configuration. After obtaining the permission configuration information and corresponding permission identifiers for each business system, a permission tree corresponding to each business system can be constructed according to the hierarchy of routing permissions → group permissions → button permissions. That is, the transaction system, risk control system, and audit system all include permission trees consisting of routing permissions, group permissions, and button permissions.

[0126] The main project can aggregate the permission trees of each business system to obtain a permission forest, so as to form a globally unified permission view, which makes it easier for administrators to configure roles and view permission distribution.

[0127] In this example, compared with related technologies, not only is unified permission control achieved across multiple subsystems, but permission management efficiency is also improved by over 95%, and the configuration error rate is reduced to below 0.1%, significantly improving system security and development efficiency. See Table 1 for a demonstration of the performance improvement in this example. Furthermore, the permission forest architecture perfectly supports micro-frontend scenarios, realizing a technical upgrade from a single permission tree to a permission forest.

[0128] Table 1

[0129]

[0130] Meanwhile, this embodiment also provides an electronic device, referring to Figure 6 As shown, Figure 6 This is a block diagram of an electronic device, which includes:

[0131] One or more processors 101;

[0132] The memory 102 stores one or more computer programs that, when executed by the one or more processors 101, cause the one or more processors 101 to implement the access control method according to the first aspect of the invention.

[0133] The electronic device may also include one or more I / O interfaces 103 connected between the processor 101 and the memory 102, configured to enable information interaction between the processor 101 and the memory 102.

[0134] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the first memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface 103 (read-write interface) is connected between the processor 101 and the memory 102, enabling information exchange between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0135] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0136] As a third aspect of the present invention, this embodiment also provides a computer-readable medium, referring to... Figure 7 As shown, Figure 7 This is a schematic diagram of a computer-readable medium on which a computer program is stored, which, when executed by a processor, implements the access control method provided in the first aspect of this disclosure.

[0137] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can implement the methods of any of the above embodiments. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0138] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.< / permissionwrapper>

Claims

1. A rights management method, characterized by, The application comprises the following steps: In the case of detecting changes in the project source code file, the project source code file is parsed to obtain an analysis result; The project source code file includes a routing configuration file; The analysis result is used as an abstract syntax tree corresponding to the project source code file, and the abstract syntax tree is processed to obtain a plurality of permission wrapper components; From the routing configuration file and the permission wrapper component, a plurality of permission configuration information corresponding to the project source code file is extracted; A permission identifier corresponding to each permission configuration information is generated, and it is detected whether the permission identifier is repeated; In the case of repeated permission identifiers, a new permission identifier is generated, and the new permission identifier and the corresponding permission configuration information are stored in a data file library; After the project source code file is parsed to obtain an analysis result in the case of detecting changes in the project source code file, the following steps are further included: The analysis result is used as an abstract syntax tree corresponding to the project source code file, and the abstract syntax tree is processed to determine the dependency relationship between business components; Based on the dependency relationship, a business component dependency graph is constructed; The business component dependency graph is analyzed recursively, and the business component that has a usage relationship with the permission wrapper component is taken as a first target business component; Based on the usage relationship between the first target business component and the permission identifier, a bidirectional mapping relationship is constructed; After the bidirectional mapping relationship is constructed based on the usage relationship between the first target business component and the permission identifier, the following steps are further included: In the case of changing the permission configuration information, the changed permission configuration information is taken as a target permission configuration information; Based on the target permission identifier of the target permission configuration information, the bidirectional mapping relationship is queried to determine a second target business component corresponding to the target permission identifier; The integrated hot update mechanism is used to update the permissions of the second target business component.

2. The rights management method of claim 1, wherein The step of generating a permission identifier corresponding to each permission configuration information comprises: A universally unique identifier corresponding to the permission configuration information is generated; In the case that the project source code file includes a plurality of source code files of business systems, for the permission configuration information corresponding to each business system, the business system identifier of the business system and the universally unique identifier corresponding to the permission configuration information are taken as the permission identifier; In the case that the project source code file includes at most one source code file of a business system, the universally unique identifier corresponding to the permission configuration information is taken as the permission identifier.

3. The rights management method of claim 1, wherein The step of extracting a plurality of permission configuration information corresponding to the project source code file from the routing configuration file and the permission wrapper component comprises: Determine the group permission through the group identifier in the permission wrapper component; Determine the button permission through the button identifier in the permission wrapper component; Extract the routing permission from the routing configuration file.

4. The rights management method according to claim 3, characterized by, After the new permission identifier and the corresponding permission configuration information are stored in the data file library, the following steps are further included: generating a permission enumeration according to the permission identifier in the data file library and the permission configuration information; storing the permission enumeration and meta information of the permission enumeration into a corresponding enumeration file according to a permission type.

5. The rights management method of claim 4, wherein The permission configuration information includes a permission function name, and the step of generating the permission enumeration according to the permission identifier in the data file library and the permission configuration information includes: taking the permission identifier as an enumeration value and the permission function name as an enumeration key according to the permission identifier in the data file library and the permission function name; generating the permission enumeration by using the enumeration value and the enumeration key.

6. The rights management method of claim 4, wherein The enumeration file includes a route enumeration file, a group enumeration file and a button enumeration file, and the step of storing the permission enumeration and the meta information of the permission enumeration into the corresponding enumeration file according to the permission type includes: storing the permission enumeration and the meta information of the permission enumeration into the route enumeration file when the permission type is a route permission; storing the permission enumeration and the meta information of the permission enumeration into the group enumeration file when the permission type is a group permission; storing the permission enumeration and the meta information of the permission enumeration into the button enumeration file when the permission type is a button permission.

7. An electronic device, comprising: comprise: one or more processors; a memory having one or more computer programs stored thereon, wherein when the one or more computer programs are executed by the one or more processors, the one or more processors implement the permission management method according to any one of claims 1 to 6.

8. A computer readable medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the permission management method according to any one of claims 1 to 6.

Images