Interface authority level-to-level management method and system based on prefix tree
Through the prefix tree-based interface permission hierarchical management method, the problems of high maintenance costs and high resource consumption in interface permission management are solved, flexible expansion and efficient permission management are achieved, system performance is improved and memory usage is reduced.
Patent Information
- Application Number
- CN202510514218.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-23
- Publication Date
- 2025-08-05
AI Technical Summary
Existing interface permission management technologies such as RBAC and ACL are difficult to effectively manage when the interface changes frequently and the user scale is expanded.
The prefix tree-based interface permission hierarchical management method is adopted, and by configuring path templates, building prefix trees, binding permission policies, using wildcards and priority rules for path matching and permission verification, reducing configuration complexity and optimizing performance.
It improves the flexibility and scalability of path matching, reduces the complexity of configuration management, significantly improves system performance and request processing efficiency, and reduces memory resource consumption.
Smart Images
Figure CN120429879A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer security technology, and in particular to a prefix tree-based interface authority hierarchical management method and system. Background Art
[0002] The current mainstream interface permission management technologies are mainly role-based access control (RBAC) and access control list (ACL) solutions, which have significant limitations in practical applications.
[0003] The RBAC model enables batch allocation of permissions through role abstraction. For example, users can be associated with roles and then interface permissions can be bound to those roles. This significantly simplifies the complexity of permission configuration and is particularly suitable for scenarios with stable organizational structures, but is not suitable for external internet users. When adding or iterating interfaces, RBAC requires maintaining all associated roles, which is costly. Furthermore, the traditional RBAC model requires manual intervention to resolve conflicts between wildcard rules and precise paths, and the duplicate storage of role permissions increases memory usage.
[0004] The ACL model directly binds user and resource permissions, supporting fine-grained control. It's suitable for scenarios with highly personalized permission requirements (such as temporarily granting specific users access to sensitive interfaces) and is well-suited for small systems. As the number of users and interfaces increases, ACLs can become very complex, making management and maintenance more difficult. Furthermore, ACL checks consume system resources. Summary of the Invention
[0005] In order to help solve the above technical problems, the present application provides a prefix tree-based interface permission hierarchical management method and system.
[0006] In a first aspect, the present application provides a method for hierarchical management of interface permissions based on a prefix tree, which adopts the following technical solutions: A method for hierarchical management of interface permissions based on a prefix tree, wherein the method for hierarchical management of interface permissions based on a prefix tree comprises: Step S1: Configure the type, name, and path expression of the path template. The path template is set with wildcards. Step S2: Construct a prefix tree based on the path template type, name, and path expression. The wildcards include single-segment wildcards and multi-segment wildcards. For path templates containing single-segment wildcards, single-segment nodes are inserted at the corresponding level. Single-segment nodes are used to match a single path segment. For path templates containing multi-segment wildcards, multi-segment nodes are inserted at the corresponding level. Multi-segment nodes are used to match multiple consecutive path segments. In the process of constructing the prefix tree, similar interfaces are identified and merged according to the path expression. Step S3: Bind the permission policy of the path template to the user and configure the permission policy information of the permission policy, where the permission policy information includes a priority score; Step S4: The user sends an interface request, receives the interface request and processes the corresponding interface path into a path segment sequence according to the interface request, traverses the prefix tree in step S2 according to the path segment sequence, matches and obtains the path template in the prefix tree; Step S5: If the path template is not matched in step S4, the verification is returned as failed. If the path template is matched and obtained in step S4, the permission policy in step S3 is queried, and the permission policies are sorted according to the preset priority rules, and the permission policy information is verified to obtain the verification result. The preset priority rules are rules for sorting the priority scores in step S3 according to a preset order. Step S6: If the verification result is passed, it means that the user has the interface access authority, allowing the user to access the target interface corresponding to the interface request. If the verification result is failed, it means that the user does not have the interface access authority.
[0007] Preferably, the step S2 includes: reading the path templates configured in the step S1, separating each path template according to the path segments corresponding to the path expression, and inserting the templates into the prefix tree in sequence.
[0008] Preferably, the step S3 includes: the authority policy information includes: User ID, used to identify the user or user group that owns this permission policy; Permission policy path template, used to specify the path template applicable to the permission policy; Permission type, which is used to define the user's access type to the interface that matches the path template. Access types include allow access and deny access. Permission validity period, used to specify the validity period of the permission policy.
[0009] Preferably, step S3 includes: for a permission policy path template whose type is an interface group, if a permission policy path template whose type is a sub-interface under the permission policy path template is not configured with a permission policy, the permission policy path template whose type is a sub-interface inherits the permission policy of the permission policy path template whose type is an interface group; Preferably, step S3 includes: when multiple permission policies conflict, automatically selecting the permission policy with the highest priority score for application according to the priority scores.
[0010] Preferably, step S3 includes: the user ID and the permission policy path template form a Redis key and store it in Redis, and the permission policy is asynchronously and persistently stored in a MySQL database.
[0011] In a second aspect, the present application provides an interface authority hierarchical management system based on a prefix tree, which adopts the following technical solutions: A prefix tree-based hierarchical interface authority management system, wherein the prefix tree-based hierarchical interface authority management system adopts the prefix tree-based hierarchical interface authority management method as described in any one of the first aspects above, and the prefix tree-based hierarchical interface authority management system includes: The user end includes a sending module and a receiving module connected thereto, the sending module is used to send the interface request in step S3, and the receiving module is used to receive the verification result in step S5; The server includes an interface management module, a permission management module, a request processing module, a path matching module, a permission verification module and a result sending module connected in sequence. The interface management module is used to execute steps S1 and S2, the permission management module is used to execute step S3, the request processing module and the path matching module are used to execute step S4, the permission verification module is used to execute step S5, and the result sending module is used to execute step S6.
[0012] In summary, the method of the present application has the following beneficial effects: 1. Enhanced path matching flexibility and scalability Path templates containing wildcards allow single- or multi-layer dynamic matching rules to cover similar interfaces, enabling the system to automatically adapt to changes in path hierarchies or version iterations. This design effectively addresses the issue of delayed rule updates caused by frequent interface path changes, ensuring the dynamic adaptability of permission policies while leaving room for future interface expansion.
[0013] 2. Configuration management complexity is significantly reduced By merging discrete, precise path rules into wildcard templates, duplicate configuration entries can be reduced by over 90%. This not only simplifies the daily maintenance of interface permissions, but also reduces the risk of configuration errors caused by manual errors, while also improving the convenience of batch permission adjustments.
[0014] 3. Significant system performance optimization effect Combined with the data structure of the prefix tree, the real-time indexing capability of the in-memory prefix tree is used to optimize the path matching time complexity to a linear relationship with the number of path segments, significantly improving the request processing efficiency in high-concurrency scenarios while reducing memory resource consumption. Compared with traditional regular matching solutions, it significantly reduces computational complexity. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] Figure 1 It is a schematic block diagram related to background technology; Figure 2 This is a flowchart of an embodiment of a prefix tree-based interface authority hierarchical management method of the present application; Figure 3 This is a schematic block diagram of the path template in step S1 of this application; Figure 4 This is a schematic block diagram of the prefix tree in step S2 of the present application; Figure 5 This is a schematic block diagram of identifying and merging similar interfaces according to the path expression in step S2 of the present application; Figure 6 This is a flow chart of step S5 of this application; Figure 7 This is a flowchart of an embodiment of a prefix tree-based interface authority hierarchical management system of the present application; Figure 8 for Figure 7 A schematic block diagram of the storage and data synchronization mechanism of the illustrated embodiment. DETAILED DESCRIPTION
[0016] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention will be very clear to those skilled in the art. It should be understood that the specific embodiments described herein are only intended to explain the present invention and are not intended to limit the present invention.
[0017] Figure 1 As a schematic diagram related to background technology, the RBAC model implements batch allocation of permissions through role abstraction. For example, users are associated with roles, and then interface permissions are bound by roles. This significantly simplifies the complexity of permission configuration and is particularly suitable for scenarios with stable organizational structures, but is not suitable for external Internet users. When adding or iterating interfaces, RBAC needs to maintain all related roles, which is costly to maintain. In addition, the traditional RBAC model requires manual intervention to handle policy conflicts between wildcard rules and precise paths, and the repeated storage of role permissions will lead to increased memory usage.
[0018] The ACL model directly binds user and resource permissions, supporting fine-grained control. It's suitable for scenarios with highly personalized permission requirements (such as temporarily granting specific users access to sensitive interfaces) and is well-suited for small systems. As the number of users and interfaces increases, ACLs can become very complex, making management and maintenance more difficult. Furthermore, ACL checks consume system resources.
[0019] Figure 2 This is a flowchart of an embodiment of a prefix tree-based interface authority hierarchical management method of the present application. The prefix tree-based interface authority hierarchical management method includes: Step S1: Configure the type, name, and path expression of the path template. The path template is set with wildcards. Step S2: Construct a prefix tree based on the type, name and path expression of the path template. Wildcards include single-segment wildcards and multi-segment wildcards. For path templates containing single-segment wildcards, single-segment nodes are inserted at the corresponding level. Single-segment nodes are used to match a single path segment. For path templates containing multi-segment wildcards, multi-segment nodes are inserted at the corresponding level. Multi-segment nodes are used to match multiple continuous path segments. In the process of constructing the prefix tree, similar interfaces are identified and merged according to the path expression. Step S2 also includes reading the path templates configured in step S1. For each path template, it is separated according to the path segment corresponding to the path expression and inserted into the prefix tree in sequence.
[0020] Step S3: Bind the permission policy of the path template to the user and configure the permission policy information of the permission policy. The permission policy information includes a priority score. The permission policy information in step S3 includes: User ID, used to identify the user or user group that owns this permission policy; Permission policy path template, used to specify the path template applicable to the permission policy; Permission type, which is used to define the user's access type to the interface that matches the path template. Access types include allow access and deny access. Permission validity period, used to specify the validity period of the permission policy.
[0021] The user ID and permission policy path template form a Redis key and are stored in Redis. The permission policy is asynchronously and persistently stored in the MySQL database.
[0022] For a permission policy path template with an interface group type, if the sub-interface permission policy path template under the permission policy path template has no permission policies configured, the sub-interface permission policy path template inherits the permission policies of the interface group permission policy path template. If multiple permission policies conflict, the policy with the highest priority score is automatically selected and applied.
[0023] Step S4: The user sends an interface request, receives the interface request and processes the corresponding interface path into a path segment sequence according to the interface request, traverses the prefix tree in step S2 according to the path segment sequence, matches and obtains the path template in the prefix tree; Step S5: If the path template is not matched in step S4, the verification is returned as failed. If the path template is matched and obtained in step S4, the permission policy in step S3 is queried, and the permission policies are sorted according to the preset priority rules, and the permission policy information is verified to obtain the verification result. The preset priority rules are rules for sorting the priority scores in step S3 according to a preset order. Step S6: If the verification result is passed, it means that the user has the interface access authority, allowing the user to access the target interface corresponding to the interface request. If the verification result is failed, it means that the user does not have the interface access authority.
[0024] Specifically, Figure 3 This is a schematic diagram of the path template in step S1 of this application. Figure 4 This is a schematic block diagram of the prefix tree in step S2 of this application. Figure 5 This is a schematic diagram of identifying and merging similar interfaces according to the path expression in step S2 of this application. Figure 6 This is a flow chart of step S5 of this application. Figure 3 Chinese and Figure 4 、 Figure 5 The English in the text corresponds exactly to the WAL transaction log (Write-Ahead Logging). In the figure: REDIS Cluster is a distributed storage solution officially provided by Redis, used to address capacity and performance bottlenecks of a single Redis instance. AOF log (AppendOnly File). MySQL is a relational database management system (RDBMS) developed by the Swedish company MySQL AB.
[0025] Combine Figures 3 to 6 The following steps can be understood: Step S1 is used to configure a path template containing wildcards, and implement hierarchical management of interfaces through path templates. A path template is an interface path expression containing wildcards, which is used to match the rule description of a class of interface paths and can represent a single interface or an interface group. Wildcards include single-segment wildcards and multi-segment wildcards. The single-segment wildcard * represents matching a single path segment, and the multi-segment wildcard ** represents matching zero or more consecutive path segments and only appears at the end. Step S1 configures a path template containing wildcards, and implements the management of interface groups or single interfaces through path templates. Specifically, it refers to configuring a path template containing wildcards in the server-side interface management module. The path template type (interface group or single interface), name, and path expression can be configured. Example: The following path templates are configured in the system: Type: Interface Group, Name: V1 Interface Group, Path Expression: / api / V1 / **; Type: Interface Group, Name: Bulletin Interface Group, Path Expression: / api / V1 / bulletin / *; Type: Single interface, Name: Stock announcement interface, Path expression: / api / V1 / bulletin / stock; Type: Single interface, Name: Bond Announcement Interface, Path Expression: / api / V1 / bulletin / bond; Type: Interface Group, Name: Transaction Overview Interface Group, Path Expression: / api / V1 / trade / *; Type: Single interface, Name: Stock transaction overview interface, Path expression: / api / V1 / trade / stock; Type: Single interface, Name: Bond Transaction Overview Interface, Path Expression: / api / V1 / trade / bond; After the configuration is completed, the hierarchical relationship between the interfaces is as follows: Figure 3 shown.
[0026] Step S2 is used to build or update a prefix tree based on the path template. The prefix tree is a tree structure containing wildcards built from the path template, and each node represents a path segment. The prefix tree building or updating process is as follows: The path template is read, segmented, and inserted into the prefix tree. For path templates containing single-segment wildcard nodes, * nodes are inserted at the corresponding level. For path templates ending with multi-segment wildcard nodes, ** nodes are inserted at leaf nodes. The prefix tree construction or update process in step 2 enables automatic merging of interfaces. The prefix tree is cached in memory and supports dynamic updates. It uses an incremental synchronization mechanism, generating differential segments only when the tree structure changes and asynchronously persisting them to the database.
[0027] Step S2 builds or updates the prefix tree according to the path template. For example, according to the path template configured in step S1, the prefix tree is built, such as Figure 4 shown.
[0028] Step S2 builds or updates the prefix tree based on the path template, which can realize the automatic merging of new interfaces. For example, if a fund announcement interface is added, the path template is configured as follows: Type: Single interface, Name: Fund Announcement Interface, Path Expression: / api / V1 / bulletin / fund.
[0029] After adding this interface, the prefix tree is updated to Figure 5 , the interface is automatically merged into the announcement interface group.
[0030] Step S3 is used to bind permission policies of different path templates to users and configure priority rules. Permission policies of binding different path templates to users may include user ID, path template, permission type, permission expiration date, and priority score. Permission policies are stored in the Redis database, and the user ID and the corresponding path template form a Redis key. The Redis cluster adopts a sharding storage mode, and hashes the shards by user ID. Each shard stores a set of user permission policies, which improves the query speed and is suitable for permission verification requirements in high-concurrency scenarios. The priority rule to which step S3 belongs is a sorting method for permission policies when traversing the prefix tree to match multiple path templates. You can choose to sort by priority score from high to low or by priority score from low to high. Permission policies of binding different path templates to users may include user ID, path template, permission type, permission expiration date, and priority score. They can be configured according to actual business conditions. For example: user "user1" has access rights to the announcement interface group. The specific configuration can be: User ID: user1, Path template: / api / V1 / bulletin / *, Permission type: Allow access, Permission validity period: Permanent, Priority score: 80.
[0031] The permission policy for binding different path templates to users as described in step S3 can handle the interface permission management scenario under massive interfaces. For example, the announcement interface group actually contains 100 interfaces, and the user "user1" has access rights to the announcement interface group. It only needs to set the above permission policy. The permission policy for binding different path templates to users can automatically inherit the permission policy of the interface group. For example: after adding a fund announcement interface, the fund announcement interface automatically inherits the permission policy of the announcement interface group without additional configuration. "user1" also has access rights to the fund announcement interface. The permission policy for binding different path templates to users can also be configured for a single interface. Policy conflicts can be automatically handled by setting priority rules. For example: although the user "user1" has the permission of the announcement interface group, he is prohibited from accessing the stock announcement interface. In this case, the permission of the stock announcement interface can be set for him. A higher priority score is set for this permission policy than the permission policy of the announcement interface group, and priority rules are set. An example is: User ID: user1, Path template: / api / V1 / bulletin / stock, Permission type: Deny access, Permission validity period: Permanent, Priority score: 100, Priority rule: Priority score from high to low.
[0032] In the permission policy example above, the user ID and path template form a Redis key and are stored in Redis. Redis's TTL automatic expiration mechanism is used to automatically purge invalid permissions. The permission policy is also asynchronously persisted in a database, such as MySQL.
[0033] Step S4 is used to receive and process user requests, traverse the prefix tree to match the path template and return the result. Receiving user requests and processing specifically includes receiving the user's interface request, processing the interface path, including path standardization and segmentation operations. Traversing the prefix tree to match the path template is specifically: traversing the prefix tree from the root node, trying to match all path segments in order, and returning all matching path templates. In this embodiment, the method for traversing the prefix tree can adopt a depth-first search method or a breadth-first search method. The receiving and processing of user requests described in step S4 refers to the interface request sent by the interface user end, processing the interface path requested by the user, traversing the prefix tree to match the path template and returning the result. The prefix tree can be traversed by depth-first search or breadth-first search. For example: The user with the user ID "user1" uses the "GET" method to request " / api / V1 / / bulletin / stock". The interface path is standardized by converting " / / " to " / ", and the segment operation is performed to obtain the path segment sequence ["api","V1","bulletin","stock"]. Matching the prefix tree in step S2, the resulting path templates are / api / V1 / **, / api / V1 / bulletin / **, and / api / V1 / bulletin / stock.
[0034] Step S5 is used to find the corresponding permission policy and sort it according to the priority rules, and verify the permission policy. Step S5 is used to find the corresponding permission policy and sort it according to the priority policy. Verifying the permission first determines whether step 4 matches the path template. If the path template is not matched, the verification fails and the process ends. If the path template is matched, the permission policy is queried, and the permission policy is sorted according to the set priority rules. The permission type, validity period, etc. of the permission are verified to obtain the result of passing or failing the verification. In step S5, it is necessary to find the corresponding permission policy and sort it according to the priority rules, and select the first valid permission policy. For example: after matching the path template of the step 4 example, two permission policies are found: Article 1: User ID: user1, Path template: / api / V1 / bulletin / *, Permission type: Allow access, Permission validity period: Permanent, Priority score: 80; Article 2: User ID: user1, Path template: / api / V1 / bulletin / stock, Permission type: Deny access, Permission validity period: Permanent, Priority score: 100, Priority rule: Priority score from high to low; After sorting by priority score from high to low, policy 2 is selected. Verify permissions. The permission type is "Deny Access" and the permission validity period is permanent. The verification result is Failed.
[0035] Step S6 is used to return the verification result to the user.
[0036] Step S6 returns the verification result to the user, which means returning an interface response indicating whether the verification is passed or not. For example, if the verification fails in step S5, a result of "You do not have interface access rights, please contact the administrator for details!" will be returned to the user-side receiving module.
[0037] Figure 7 This is a flow chart of an embodiment of a prefix tree-based interface authority hierarchical management system of the present application. The prefix tree-based interface authority hierarchical management system of the present application adopts the above-mentioned prefix tree-based interface authority hierarchical management method, including: The user end includes a sending module and a receiving module connected thereto, the sending module is used to send the interface request in step S3, and the receiving module is used to receive the verification result in step S5; The server includes an interface management module, a permission management module, a request processing module, a path matching module, a permission verification module and a result sending module connected in sequence. The interface management module is used to execute steps S1 and S2, the permission management module is used to execute step S3, the request processing module and the path matching module are used to execute step S4, the permission verification module is used to execute step S5, and the result sending module is used to execute step S6.
[0038] Figure 8 for Figure 7 A schematic block diagram of the storage and data synchronization mechanism of the illustrated embodiment.
[0039] from Figure 8 As can be seen, the detailed working principle: Data changes in server memory are written to the WAL transaction log in real time. The WAL transaction log ensures the order and durability of data changes, preventing data loss even in the event of a system failure. A prefix tree structure is used for data storage and querying. A prefix tree is a tree-like data structure suitable for storing strings and enabling efficient prefix searches. Data in the prefix tree structure is cached and written back to server memory to maintain data consistency and real-time performance. Data changes in the prefix tree structure are synchronized to the database via asynchronous incremental synchronization. This reduces synchronization latency and improves system performance. Redis Cluster provides high-performance and highly available caching services. Nodes in the cluster can share the load, improving system scalability and reliability. When a policy needs to be updated, the new policy is pushed to all nodes through the Redis cluster, ensuring that each node can apply the new policy in real time. The database is used for persistent data storage, ensuring that data is not lost due to system failures. The AOF log records all database operations, and data can be recovered by replaying the AOF log. The AOF log ensures data persistence and consistency. Asynchronous policy snapshots achieve data persistence by periodically writing snapshots of data in the Redis cluster to the database.
[0040] In summary, this application demonstrates multi-dimensional advantages in interface permission management and routing control scenarios through path templates containing wildcards. Its core value lies in improving system adaptability and operational efficiency through abstract path expression while reducing maintenance costs.
Claims
1. A method for hierarchical management of interface permissions based on prefix tree, characterized in that: The interface authority hierarchical management method based on prefix tree includes: Step S1: Configure the type, name, and path expression of the path template. The path template is set with wildcards. Step S2: Construct a prefix tree based on the path template type, name, and path expression. The wildcards include single-segment wildcards and multi-segment wildcards. For path templates containing single-segment wildcards, single-segment nodes are inserted at the corresponding level. Single-segment nodes are used to match a single path segment. For path templates containing multi-segment wildcards, multi-segment nodes are inserted at the corresponding level. Multi-segment nodes are used to match multiple consecutive path segments. In the process of constructing the prefix tree, similar interfaces are identified and merged according to the path expression. Step S3: Bind the permission policy of the path template to the user and configure the permission policy information of the permission policy, where the permission policy information includes a priority score; Step S4: The user sends an interface request, receives the interface request and processes the corresponding interface path into a path segment sequence according to the interface request, traverses the prefix tree in step S2 according to the path segment sequence, matches and obtains the path template in the prefix tree; Step S5: If the path template is not matched in step S4, the verification is returned as failed. If the path template is matched and obtained in step S4, the permission policy in step S3 is queried, and the permission policies are sorted according to the preset priority rules, and the permission policy information is verified to obtain the verification result. The preset priority rules are rules for sorting the priority scores in step S3 according to a preset order. Step S6: If the verification result is passed, it means that the user has the interface access authority, allowing the user to access the target interface corresponding to the interface request. If the verification result is failed, it means that the user does not have the interface access authority.
2. The interface authority hierarchical management method based on prefix tree according to claim 1 is characterized in that: The step S2 includes: reading the path templates configured in the step S1, separating each path template according to the path segments corresponding to the path expression, and inserting the templates into the prefix tree in sequence.
3. The interface authority hierarchical management method based on prefix tree according to claim 1 is characterized in that: The step S3 includes: the authority policy information includes: User ID, used to identify the user or user group that owns this permission policy; Permission policy path template, used to specify the path template applicable to the permission policy; Permission type, which is used to define the user's access type to the interface that matches the path template. Access types include allow access and deny access. Permission validity period, used to specify the validity period of the permission policy.
4. The interface authority hierarchical management method based on prefix tree according to claim 3 is characterized in that: The step S3 includes: for a permission policy path template whose type is an interface group, if a permission policy path template whose type is a sub-interface under the permission policy path template is not configured with a permission policy, then the permission policy path template whose type is a sub-interface inherits the permission policy of the permission policy path template whose type is an interface group.
5. The interface authority hierarchical management method based on prefix tree according to claim 4 is characterized in that: The step S3 includes: when multiple permission policies conflict, automatically selecting the permission policy with the highest priority score for application according to the priority scores.
6. The interface authority hierarchical management method based on prefix tree according to claim 5 is characterized in that: The step S3 includes: the user ID and the permission policy path template form a Redis key and store it in Redis, and the permission policy is asynchronously and persistently stored in the MySQL database.
7. An interface authority hierarchical management system based on prefix tree, characterized in that: The interface authority hierarchical management system based on a prefix tree adopts the interface authority hierarchical management method based on a prefix tree according to any one of claims 1 to 6, and the interface authority hierarchical management system based on a prefix tree includes: The user end includes a sending module and a receiving module connected thereto, the sending module is used to send the interface request in step S3, and the receiving module is used to receive the verification result in step S5; The server includes an interface management module, a permission management module, a request processing module, a path matching module, a permission verification module and a result sending module connected in sequence. The interface management module is used to execute steps S1 and S2, the permission management module is used to execute step S3, the request processing module and the path matching module are used to execute step S4, the permission verification module is used to execute step S5, and the result sending module is used to execute step S6.