An abstract syntax tree-based permission control method and control system

Abstract

The application discloses a permission control method and system based on an abstract syntax tree, and the method comprises the following steps: in step 101, route information is acquired based on system front-end source code; in step 102, the route information is traversed, and in the traversing process, page entry source code is acquired, parsed into an abstract syntax tree, and traversed to acquire information of page entry file dependent modules; dependent modules and request interface information are acquired by recursively traversing the dependent module information; and a permission tree is generated after the end; in step 103, the permission tree is converted into an xml file, and the xml file is parsed into a json by a back end in the form of an interface and used in the system; and in step 104, the system requests a permission tree interface, and controls page display based on information on the permission tree. The application solves the problem of frequent update of permission information in the system development iteration process, and perfects the process of permission data generation, storage and use in the permission management process.

Description

Technical Field

[0001] This invention mainly relates to the field of access control technology, specifically to an access control method and control system based on an abstract syntax tree. Background Technology

[0002] Access control generally refers to the system's security rules or policies that allow users to access exactly the resources they are authorized to access, no more and no less. Access control is present in almost any system that uses usernames and passwords.

[0003] To implement permission management in the system, permission data is maintained at different levels of fineness, typically down to whether a user has permission to call a certain interface. During the iterative upgrade of the system, there will inevitably be additions, deletions, and modifications to pages and interfaces, so the permission data needs to be adjusted frequently. This process is very tedious when done entirely manually, and if the modification is incorrect, it may lead to unpredictable errors. Summary of the Invention

[0004] To address the technical problems existing in the prior art, this invention provides an abstract syntax tree-based permission control method and control system that improves the generation, storage, and use of permission data during the permission management process.

[0005] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows:

[0006] An access control method based on abstract syntax trees includes the following steps:

[0007] Step 101: Obtain routing information based on the system front-end source code;

[0008] Step 102: Traverse the route information, obtain the page entry source code during the traversal, parse it into an abstract syntax tree, traverse the abstract syntax tree to obtain the information of the page entry file's dependent modules, recursively traverse the dependent module information to obtain its dependent modules and request interface information, and generate the permission tree after completion.

[0009] Step 103: Convert the permission tree into an XML file. The backend then uses an API to parse this XML file into JSON for use in the system.

[0010] Step 104: The system requests the permission tree interface to control the display of the page based on the information on the permission tree.

[0011] Preferably, the specific process of step 102 is as follows:

[0012] Step 201: Read the page content and use the compilation tool to generate the page's abstract syntax tree;

[0013] Step 202: Traverse the abstract syntax tree to collect information about page dependency files;

[0014] Step 203: Traverse the abstract syntax tree to collect request information about page dependencies;

[0015] Step 204: Recursively traverse the dependency file information and repeat the previous steps until all the dependency files of the page have been parsed;

[0016] Step 205: Collect all dependency and request information for the page.

[0017] Preferably, the specific process of step 201 is as follows:

[0018] Step 2011: Lexical analysis, which decomposes the input code string into lexical units, also known as tokens;

[0019] Step 2012: Syntax analysis, which combines word sequences into various grammatical phrases based on lexical analysis;

[0020] Step 2013: Generate an abstract syntax tree.

[0021] Preferably, in step 101, based on the project's path mapping configuration, the path of the routing information configuration entry file in the front-end source code is found and converted into an absolute path. The file content is read through the file path. Furthermore, the modular syntax in the routing entry file and its dependent files is converted into CommonJS syntax through compilation tools and corresponding plugins. The routing information is further obtained through CommonJS import syntax.

[0022] Preferably, in step 102, the route traversal adopts a depth-first traversal. During the traversal, the parent node path identifier is passed to the child node and merged with the child node's path identifier to represent the unique identifier of the current node. When traversing to a leaf node, the traversal stops. Leaf nodes in the route information are generally page configuration objects. Whether to skip the current leaf node and continue traversing is determined by whether the leaf node has child nodes and whether it contains page entry file path information. If the route contains some layout components, and these layout components use requests, their request information also needs to be matched. According to different business requirements, these requests are divided into common modules or into pages. If they are divided into common requests, all layout component information needs to be collected during the traversal and parsed and processed separately after the traversal is completed. If they are divided into pages, the layout component information is passed to the leaf node and merged with the leaf node's page entry file information. Their dependencies and request information are then parsed together.

[0023] Preferably, in step 102, the abstract syntax tree is traversed. During the traversal, the information of other module files that the entry file depends on is matched based on the syntax features of the module import, and the request information of the page is matched based on the syntax features of the request definition. After the traversal is completed, the dependency information of the entry file is parsed. The dependency files are recursively traversed to repeat the process of converting the dependency files into the abstract syntax tree and the dependency and request information of the matching files. After the dependency files and the dependencies of the dependency files are processed, all the request information of the single page dependency is obtained.

[0024] Furthermore, the structure of the parsed page in the routing data and the request information obtained from the parsing are preserved, and the routing information is traversed again using a depth-first traversal method until a permission tree containing the original routing structure and the obtained page request information is generated after the traversal is completed.

[0025] Preferably, in step 201, the conversion process from the page entry file content to the abstract syntax tree includes:

[0026] 1) Lexical analysis: The source program is read character by character in sequence, and then words are identified according to word formation rules to generate a token stream;

[0027] 2) Syntax analysis, which combines word sequences into various grammatical phrases based on lexical analysis; the dependencies and nesting relationships between these grammatical phrases constitute an abstract syntax tree.

[0028] Preferably, in step 203, while matching and obtaining dependency information, request-related information, including request name, request method, and request address, is matched based on request syntax. After the traversal is completed, the dependency information and request information of the entry file are obtained.

[0029] Preferably, in step 104, when the front-end page is initialized, it requests the permission tree interface, determines which modules and pages the user is allowed to access based on the modules, sub-routes, and page levels in the permission tree, and determines which interfaces the user is allowed to call, i.e. which functions in the page, based on the request interface level, thereby realizing the system's permission control.

[0030] The present invention also discloses an access control system based on abstract syntax trees, including a memory and a processor. The memory stores a program, which, when run by the processor, executes the steps of the access control method based on abstract syntax trees as described above.

[0031] Compared with the prior art, the advantages of the present invention are as follows:

[0032] This invention provides an access control method based on abstract syntax trees that can automatically generate the access control data required in the access control process based on the project source code information. The system server generates and stores access control data based on different roles, and the client obtains the corresponding access control data based on the logged-in user's role to control the system display. This realizes the generation, storage and use of access control data in the access control process, solves the problem of frequent updates of access control information during system development iteration, and improves the process of access control data generation, storage and use. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall process of the permission control method based on abstract syntax tree of the present invention in an embodiment.

[0034] Figure 2 This is a schematic diagram illustrating the page information parsing process of the access control method based on abstract syntax trees according to the present invention.

[0035] Figure 3 This is a schematic diagram of the abstract syntax tree construction process of the permission control method based on abstract syntax trees of the present invention.

[0036] Figure 4 This is a schematic diagram of the access control process of the access control method based on abstract syntax tree of the present invention. Detailed Implementation

[0037] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0038] like Figure 1 As shown, the access control method based on abstract syntax trees in this embodiment of the invention specifically includes the following steps:

[0039] Step 101: Based on the system front-end source code, obtain the routing information, as follows:

[0040] Based on the project's path mapping configuration, the path of the entry file for routing information configuration in the front-end source code is found and converted into an absolute path. The file content is read through the file path. Furthermore, the modular syntax in the routing entry file and its dependent files is converted into CommonJS syntax through compilation tools and corresponding plugins. Finally, the routing information is obtained through CommonJS import syntax.

[0041] The routing information is a tree-like JSON string containing the hierarchical structure of all pages in the system, page information, and page file paths. It's a tree structure describing which modules, pages, and page information are included in the system. Different systems use different front-end frameworks, resulting in variations in their routing configuration and structure. Before traversing to retrieve page information, the routing information must be standardized. Specifically, this involves: standardizing source code modularization rules (different modularization rules have different syntaxes, which are converted using compilation tools and corresponding plugins); and standardizing the routing structure by converting the fields on the route nodes to the same fields.

[0042] Step 102: Traverse the routing information. During the traversal, obtain the source code of the page entry point. Parse the source code of the page entry point and the source code of the page's dependent modules into an abstract syntax tree. Traverse the abstract syntax tree to obtain the information of the dependent modules of the page entry file. Recursively traverse the information of the dependent modules to obtain their dependent modules and request interface information. After completion, generate the permission tree.

[0043] An abstract syntax tree (AST) is a tree-like representation of the abstract syntactic structure of source code, where each node represents a structure within the source code. The permission tree, for example, contains system page hierarchy, page path information, and page request information. In other words, the permission tree is a complete dataset containing information about all system modules, pages, and interfaces. It requires further configuration through the permission configuration module to set different permission groups, configure different user roles based on these permission groups, and assign roles to different users, thereby generating different permission trees. The interface then returns the corresponding permission tree information based on the user's role.

[0044] The implementation of obtaining the page entry source code includes converting the page entry file path in the routing information with the path mapping configuration in the system to obtain the absolute path string of the page entry file, and then obtaining the page entry source code by reading the file content.

[0045] Specifically, the route traversal adopts a depth-first traversal. During the traversal, the path identifier of the parent node is passed to the child node and merged with the path identifier of the child node to represent the unique identifier of the current node. When the traversal reaches the leaf node, it pauses. The leaf node in the route information is generally a page configuration object. Whether to skip the current leaf node and continue the traversal is determined by whether the leaf node has child nodes and whether it contains the path information of the page entry file.

[0046] If the route contains layout components that use requests, their request information also needs to be matched. Depending on different business requirements, these requests can be divided into common modules or into individual pages. If divided into common requests, all layout component information needs to be collected during the traversal process and then parsed and processed separately after the traversal is complete. If divided into individual pages, the layout component information can be passed to the leaf nodes and merged with the page entry file information of the leaf nodes, and their dependencies and request information can be parsed together later.

[0047] The abstract syntax tree is traversed. During the traversal, the information of other module files that the entry file depends on is matched based on the syntax features of module imports, and the request information of the page is matched based on the syntax features of request definitions. After the traversal is completed, the dependency information of the entry file is parsed. The dependency files are recursively traversed to repeat the process of converting the dependency files into the abstract syntax tree and the dependency and request information of the matching files. After the dependency files and the dependencies of the dependency files are processed, all the request information of the single page dependency is obtained.

[0048] Furthermore, the structure of the parsed page in the routing data and the request information obtained from the parsing are preserved, and the routing information is traversed again using a depth-first traversal method until a permission tree containing the original routing structure and the obtained page request information is generated after the traversal is completed.

[0049] like Figure 2 As shown, the specific steps for parsing the dependency and request information of a single page are as follows:

[0050] Step 201: Read the page content and use the compilation tool to generate the page's abstract syntax tree.

[0051] Specifically, reading page content requires converting the page entry file path in the routing configuration to an absolute path through the system's path mapping configuration, and then obtaining the content string of the entry file through the file reading method.

[0052] Furthermore, different systems may choose different front-end frameworks, and different frameworks may use different custom syntaxes. Therefore, different plugins need to be configured for the compilation tools to adapt to each framework, and finally the source code is translated into an abstract syntax tree containing the same syntax information.

[0053] The process of transforming the content of the page entry file into an abstract syntax tree includes:

[0054] 1) Lexical analysis: Read the source program character by character from left to right, then identify words according to word formation rules and generate a token stream.

[0055] 2) Syntax analysis: Based on lexical analysis, word sequences are combined into various grammatical phrases, such as "program", "statement", "expression", etc. The dependencies and nesting relationships between numerous grammatical structures constitute a tree structure, namely the AST syntax tree.

[0056] The process of transforming the entry source code into an abstract syntax tree includes:

[0057] 1) Introduce compilation tools.

[0058] 2) Configure the compilation tool according to the framework and syntax used by the system. The compilation tool will first translate the framework-specific syntax in the source code into general syntax according to the configuration, and then further transform the general syntax into an abstract syntax tree.

[0059] Here, the compilation tool refers to the front-end compiler, such as Babel and SWC, whose working process is roughly parsing, transforming, and generating. First, the source code is parsed and an abstract syntax tree is built; then the abstract syntax tree is transformed, and the syntax tree is modified using specified transformation rules and plugins; finally, the target code is generated based on the modified abstract syntax tree.

[0060] Specifically, when compiling React framework code, a plugin needs to be configured for the compiler to convert React syntax into JavaScript syntax. If TypeScript is used, a plugin to convert TypeScript syntax into JavaScript syntax also needs to be configured. After configuring the plugin, the code string is passed in and converted into an abstract syntax tree. Figure 3 The process of converting a code string into an abstract syntax tree is described, and the specific steps are as follows:

[0061] Step 2011, Lexical Analysis: This step breaks down the input code string into lexical units, also known as tokens. The lexical analyzer identifies syntax elements such as keywords, identifiers, operators, and semicolons, and generates a token stream.

[0062] Specifically, for example, the function request(' / address') will be split into four parts during the syntax analysis process: request, (, ' / address', ) . Each part has a different meaning. The lexical analysis process can be imagined as a list or array of different types of tags. The final result is: [{type:'Identifier',value:'request'},{type:'Punctuator',value:'('},{type:'String',value:' / address'},{type:'Punctuator',value:')'}].

[0063] Step 2012: Syntax analysis. Based on lexical analysis, word sequences are combined into various grammatical phrases, such as "program," "statement," and "expression." The dependencies and nesting relationships among these grammatical structures form a tree-like structure, namely the AST (Abstract Syntax Tree).

[0064] Specifically, the function request(' / address') will be parsed into an ExpressionStatement, request will be parsed into a CallExpression function expression, and / address will be parsed into a variable Literal, etc. The final result is:

[0065] {"type":"Program","start":0,"end":19,"loc":{"start":{"line":1,"column":0},"end":{"line":1,"column":19}},"range":[0,19],"comments":[],"sourceType":"module","bo dy":[{"type":"ExpressionStatement","start":0,"end":19,"loc":{"start":{"line":1,"column":0},"end":{"line":1,"column":19}},"range":[0,19],"expression":{"type":"CallExpression","start":0,"end":19,"loc":{"start":{"line":1,"column":0},"end":{ "line":1,"column":19}},"range":[0,19],"callee":{"type":"Identifier","start":0,"end":7,"loc":{"start":{"line":1,"column ":0},"end":{"line":1,"column":7}},"range":[0,7],"name":"request"},"arguments":[{"type":"Literal","start":8,"end":18,"lo c":{"start":{"line":1,"column":8},"end":{"line":1,"column":18}},"range":[8,18],"value":" / address","raw":"' / address'"}],"optional":false}}]}.

[0066] Step 2013: Generate an abstract syntax tree.

[0067] Specifically, the information contained in the abstract syntax tree includes:

[0068] Syntax structure, the abstract syntax tree describes the syntax structure of the code, including variables, functions, loops, conditional statements, etc.

[0069] Hierarchical structure, abstract syntax tree is a tree-like structure in which each node represents a syntax structure, and there are parent-child relationships between nodes, used to represent the nested structure of code.

[0070] Identifiers, in the abstract syntax tree, contain identifiers (such as variable names and function names) and their scope information, which helps to understand the definition and use of variables and functions.

[0071] An expression, or abstract syntax tree, contains information about expressions, such as arithmetic expressions, logical expressions, etc., as well as their order of operations and precedence.

[0072] Control flow, or abstract syntax tree, also reflects the control flow structure of the code, including conditional branches and loop structures, helping to understand the execution path of the code.

[0073] Step 202: Traverse the abstract syntax tree to collect information about page dependency files. After obtaining the abstract syntax tree of the file in step 201, traverse it. During the traversal, determine whether the type of the current node and the corresponding node information match the code segment to be matched after it has been converted into an abstract syntax tree to obtain the required information. In this step, it is necessary to match the module import syntax and parse the imported file path string from the import syntax.

[0074] Specifically, the module import syntax includes import a from '. / filepath' and require('. / filepath'), where the string . / filepath is the path string of the file that depends on the module. To obtain this path string, it is necessary to match the structure of the module import syntax after it has been converted into an abstract syntax tree, and then specifically obtain the path string part after the match is found.

[0075] Step 203: Traverse the abstract syntax tree to collect page dependency request information. While matching and obtaining dependency information (including dependent module paths and variables used), match request-related information based on request syntax, including request name, request method, and request address. After traversal, obtain the dependency information and request information of the entry file.

[0076] Step 204: Recursively traverse the dependency file information and repeat the previous steps until all the dependency files of the page have been parsed.

[0077] Specifically, the page entry file depends on other files. Therefore, to obtain all request information in the page, it is necessary to parse and match the entry file, its dependent files, and the dependent files of those dependent files. This requires maintaining a list of files to be parsed and a list of page request information. The list of files to be parsed contains the page entry file information by default. When parsing begins, a piece of data is retrieved from the list of files to be parsed, its dependent information is parsed and matched, and the dependent information is added to the list of files to be parsed. Then, its request information is parsed and matched, and the request information is added to the list of page request information. This process is repeated until the list of files to be parsed is empty. At this point, the list of page request information contains all the request information of the page.

[0078] Specifically, page request information is typically defined as an object, containing the request method, request name, and request URL. In this case, simply matching the object definition syntax is sufficient to retrieve the request information. However, if the request is encapsulated within the component during component creation, and the request information is passed to the component via attributes, then matching the component's usage syntax is necessary to obtain the request information. Taking React components as an example, after the component is defined and compiled by the compiler, it is converted into JavaScript code in the form of functions. To match the component's usage syntax, the call information of the converted function must be matched, where the function's call parameters will contain the request information.

[0079] Specifically, different syntaxes may be used when defining request information in the page source code. For example, the request address may be defined using strings, template strings, or variables. Matching can target these three syntax forms to obtain the request address information. When matching variables, variable information in the source code needs to be collected beforehand, and the variable syntax further parsed to obtain the request address information. If the built-in matching rules ultimately fail to find the desired information, a fallback approach can be taken. Fixed placeholders for failed matches can be used to replace the matching information. After generating the XML file, a unified message will be displayed indicating where the matches failed. The specific placeholders for failed matches can be searched in the generated XML file, and the corresponding file can be located in the source code based on the path information to check the specific situation and manually replace the placeholders with the matching information.

[0080] Specifically, syntax matching is used when parsing file request information. Once a match is found, the request information is retrieved from the corresponding syntax structure. However, this request may only be written in the code but has not been used by any page. This will result in redundant requests in the final generated permission tree. To remove redundant request information, it is necessary to further analyze the variable information of the file import module, as follows:

[0081] Analyze the syntax of the file import module, collect import variable information, traverse the abstract syntax tree of the current file, analyze the usage of import variables, and if the dependent variables have not been used, filter out the current dependency and do not parse its file content later; otherwise, parse the dependent file content with the variable information used.

[0082] After parsing the request information of file dependencies, based on the variable information used in the parent file, further analysis is conducted to determine whether the code related to the variables uses the code related to the requests, thereby filtering out the request information that is not used.

[0083] Specifically, the variable-related code refers to the fact that the variable may be a constant or a function. Constants can be skipped to the next step. If it is a function, the variable information used in the function needs to be analyzed because the function may call the request interface and thus depend on the request. This indicates that the request is used. The request-related code refers to the request information we obtain, which may be defined in a function or module scope. All code related to the request information needs to be parsed to determine its reference status.

[0084] This process is similar to the TreeShaking function in front-end bundling tools, which marks variables based on their usage and removes unused code. Here, it filters out unused requests.

[0085] Step 205: Collect all dependency and request information for the page.

[0086] After traversing all the route information, the permission tree is obtained, which contains the original route's structure information, module information, page information, and page request information.

[0087] Specifically, different pages may depend on the same requests. When performing access control in the system, it may be necessary to extract the repeated interfaces as public interfaces. Public interfaces can be used without authorization, such as login and logout interfaces. Therefore, during the process of traversing the route and parsing page requests, a set of request interface usage information can be maintained. When the same interface is matched, its reference count is incremented. After the traversal is completed, the public requests are extracted based on the request reference count and special request addresses. Then, the permission tree is traversed again to remove the public requests contained in the page request information.

[0088] Step 103: Convert the permission tree into an XML file. The backend then parses this XML file into JSON via an API for use in the system. The XML file includes multiple layers: modules, pages, and request APIs. The module and page layers control whether a page is displayed, while the request API layer controls the requests and content display within the page.

[0089] Step 104: The system requests the permission tree interface to control page display based on the information in the permission tree. Specifically, during front-end page initialization, the system requests the permission tree interface to determine which modules and pages the user is authorized to access based on the modules, sub-routes, and page hierarchy in the permission tree. It also determines which interfaces the user is authorized to call (i.e., which functions on the page) based on the requested interface hierarchy, thereby achieving system access control.

[0090] The process of controlling page display based on information on the permission tree includes:

[0091] 1) After a user successfully logs in, the system requests the permission tree interface.

[0092] 2) Use the permission tree information as a basis to traverse the system routes and filter out routes that you do not have permission to access.

[0093] 3) Render the system's menu bar based on the filtered routing information.

[0094] 4) When the page starts rendering, a request is sent to the server. The request is intercepted, and the user is judged whether they have the right to call the interface according to the request interface layer in the permission tree. If not, the request is terminated and a corresponding prompt is given; otherwise, the request is allowed.

[0095] This invention provides an access control method based on abstract syntax trees that can automatically generate the access control data required in the access control process based on the project source code information. The system server generates and stores access control data based on different roles, and the client obtains the corresponding access control data based on the logged-in user's role to control the system display. This realizes the generation, storage and use of access control data in the access control process, solves the problem of frequent updates of access control information during system development iteration, and improves the process of access control data generation, storage and use.

[0096] Figure 4 The system permission control process based on the permission tree XML file is described in the following details:

[0097] Step S1: Integrate the permission tree XML file into the backend service.

[0098] Step S2: The backend service provides an interface to return full permission JSON information.

[0099] Step S3: Request the API in the front-end page permission management module to obtain the full set of permission JSON information.

[0100] Step S4: Configure different permission groups, configure different user roles, and assign user roles in the permission management module on the front-end page.

[0101] Specifically, different permission groups are used to control which modules, pages, and interfaces a permission group's role can access; different user roles are used to carry different permission groups, thus creating different permissions; assigning user roles is the process of assigning specific permissions to users.

[0102] Step S5: After step S4, different permission JSON strings will be generated.

[0103] Step S6: Save the different permission JSON strings generated in step S5 to the database.

[0104] Step S7: After a user successfully logs in, return the specific user's permission information to the user via an interface.

[0105] Step S8: After the user successfully logs in on the system page, a permission information request is initiated to obtain the user's permission JSON information.

[0106] Step S9: Traverse the system routes based on the permission tree information to filter out routes that you do not have permission to access.

[0107] Step S10: Render the system's menu bar based on the filtered routing information, and only display the menu bar that the user can access.

[0108] Furthermore, the logic for intercepting page redirects and URL changes is intercepted. Before execution, the system first checks the user's permission information to determine whether they have permission to access the redirected page path and the URL change path. If they do, the system executes the subsequent logic; otherwise, it provides a corresponding prompt.

[0109] Step S11: The page begins rendering and requests interface information.

[0110] Step S12: Intercept the request interface and determine whether the user has the right to call this interface based on the request interface layer in the permission tree JSON.

[0111] Step S13: Unauthorized to call the interface, terminate the request and provide a corresponding prompt.

[0112] Step S14: With permission to call the interface, continue the request, and re-render the page based on the response content.

[0113] Optionally, the display and hiding of components related to the invoked interface can be controlled based on whether the interface has the right to call it, thereby realizing the permission control of the content displayed on the page.

[0114] Step S15: Complete page rendering.

[0115] This invention also discloses an access control system based on an abstract syntax tree (AST), comprising a memory and a processor. The memory stores a program, which, when executed by the processor, performs the steps of the access control method based on the AST as described above. The control system of this invention corresponds to the aforementioned control method and also possesses the advantages described above.

[0116] The present invention can implement all or part of the processes in the methods of the above embodiments, or it can be implemented by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable storage medium includes: any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0117] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A permission control method based on abstract syntax trees, characterized in that, Including the following steps: Step 101: Obtain routing information based on the system front-end source code; Step 102: Traverse the route information, obtain the page entry source code during the traversal, parse it into an abstract syntax tree, traverse the abstract syntax tree to obtain the information of the page entry file's dependent modules, recursively traverse the dependent module information to obtain its dependent modules and request interface information, and generate the permission tree after completion. Step 103: Convert the permission tree into an XML file. The backend then uses an API to parse this XML file into JSON for use in the system. Step 104: The system requests the permission tree interface to control the display of the page based on the information on the permission tree.

2. The access control method based on abstract syntax trees according to claim 1, characterized in that, The specific process of step 102 is as follows: Step 201: Read the page content and use the compilation tool to generate the page's abstract syntax tree; Step 202: Traverse the abstract syntax tree to collect information about page dependency files; Step 203: Traverse the abstract syntax tree to collect request information about page dependencies; Step 204: Recursively traverse the dependency file information and repeat the previous steps until all the dependency files of the page have been parsed; Step 205: Collect all dependency and request information for the page.

3. The access control method based on abstract syntax trees according to claim 2, characterized in that, The specific process of step 201 is as follows: Step 2011: Lexical analysis, which decomposes the input code string into lexical units, also known as tokens; Step 2012: Syntax analysis, which combines word sequences into various grammatical phrases based on lexical analysis; Step 2013: Generate an abstract syntax tree.

4. The access control method based on abstract syntax trees according to claim 1, 2, or 3, characterized in that, In step 101, based on the project's path mapping configuration, the path of the routing information configuration entry file in the front-end source code is found and converted into an absolute path. The file content is read through the file path. Furthermore, the modular syntax in the routing entry file and its dependent files is converted into CommonJS syntax through compilation tools and corresponding plugins. Finally, the routing information is obtained through CommonJS import syntax.

5. The access control method based on abstract syntax trees according to claim 2 or 3, characterized in that, In step 102, the route is traversed using a depth-first traversal. During the traversal, the path identifier of the parent node is passed to the child node and merged with the path identifier of the child node to represent the unique identifier of the current node. When traversing to a leaf node, pause. Leaf nodes in the routing information are generally page configuration objects. Determine whether to skip the current leaf node and continue traversing by checking if the leaf node has child nodes and whether it contains the page entry file path information. If the route contains some layout components, and these layout components use requests, their request information also needs to be matched. These requests are then divided into common modules or pages according to different business requirements. If they are divided into common requests, all layout component information needs to be collected during the traversal, and then parsed and processed separately after the traversal is completed. If the layout is divided into pages, the layout component information is passed to the leaf nodes and merged with the page entry file information of the leaf nodes. Their dependencies and request information will be parsed together later.

6. The access control method based on abstract syntax trees according to claim 2 or 3, characterized in that, In step 102, the abstract syntax tree is traversed. During the traversal, the information of other module files that the entry file depends on is matched based on the syntax features of module imports, and the request information of the page is matched based on the syntax features of request definitions. After the traversal is completed, the dependency information of the entry file is parsed, the dependency files are recursively traversed, and the process of converting the dependency files into the abstract syntax tree and matching the dependency and request information of the file is repeated. After the dependency files and the dependencies of the dependency files are processed, all the request information of a single page dependency is obtained. Furthermore, the structure of the parsed page in the routing data and the request information obtained from the parsing are preserved, and the routing information is traversed again using a depth-first traversal method until a permission tree containing the original routing structure and the obtained page request information is generated after the traversal is completed.

7. The access control method based on abstract syntax trees according to claim 3, characterized in that, In step 201, the transformation process from the page entry file content to the abstract syntax tree includes: 1) Lexical analysis: The source program is read character by character in sequence, and then words are identified according to word formation rules to generate a token stream; 2) Syntax analysis, which combines word sequences into various grammatical phrases based on lexical analysis; the dependencies and nesting relationships between these grammatical phrases constitute an abstract syntax tree.

8. The access control method based on abstract syntax trees according to claim 3, characterized in that, In step 203, while matching and obtaining dependency information, request-related information, including request name, request method, and request address, is matched based on request syntax. After the traversal is completed, the dependency information and request information of the entry file are obtained.

9. The access control method based on abstract syntax trees according to claim 2 or 3, characterized in that, In step 104, when the front-end page is initialized, it requests the permission tree interface. Based on the modules, sub-routes, and page hierarchy in the permission tree, it determines which modules and pages the user is authorized to access. Based on the request interface hierarchy, it determines which interfaces the user is authorized to call, i.e., which functions on the page they are authorized to use, thereby realizing the system's permission control.

10. A permission control system based on an abstract syntax tree, comprising a memory and a processor, wherein the memory stores a program, characterized in that, When the program is run by the processor, it executes the steps of the access control method based on any one of claims 1-9.

Images