Permission system implementation method and system based on interface detection

Abstract

The invention discloses a permission system implementation method and system based on interface detection, and relates to the technical field of computer software security, and the method comprises the following steps: full-interface forced permission verification: all service interfaces are covered by a permission verification layer; centralized dynamic authority management and unified maintenance of authority configuration are realized, updating during operation and business customization expansion are supported, and authority rules are associated to an interface through annotations; front and back end authority processing is simplified, and the server side directly configures the authority through interface layer annotation. According to the method, all service interfaces are ensured to be verified by a unified permission verification layer without exception, security vulnerabilities caused by verification omission are thoroughly eliminated, the maintainability and the flexibility of a system are remarkably improved, permission rules are directly bound to the interfaces in an annotation-driven mode, and the permission rules are intercepted by a section to automatically execute verification, so that the verification efficiency is improved. Therefore, the server does not need to write redundant permission codes, the development complexity is greatly reduced, the development efficiency is improved, and meanwhile the consistency, integrity and safety of permission control are guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software security, and in particular to an interface detection-based permission system implementation method and system. BACKGROUND

[0002] With the accelerated promotion of social digital transformation, the demand for secure access control of various information systems and Internet services is increasing, and enterprise-level applications, government platforms and micro-service architectures generally rely on API interfaces for data interaction and business collaboration. How to ensure system openness while implementing fine and highly reliable permission management has become a key link in the software security system.

[0003] The current mainstream permission control scheme mostly adopts a decentralized verification mechanism, and the permission logic is often embedded in the business code, resulting in separation of the permission interface and the data interface, the need for a special interface to obtain the permission point, additional network requests and front-end and back-end coupling, and the need to modify the front-end interaction logic and back-end interface verification when the page content changes, which leads to inconsistent permission control risks, front-end control interaction logic, and back-end interfaces that may miss permission verification, resulting in unauthorized vulnerabilities (such as disabled buttons still calling APIs), high implementation costs, low code reuse rate due to hard-coded permission logic, serious dependence on developer proficiency, and the risk of missing verification, scattered permission configuration, and difficult maintenance. Although some systems have introduced annotations or interceptors, they lack the ability to forcibly cover all interfaces, leaving security vulnerabilities that can bypass verification. At the same time, permission configurations are usually static and fixed, making it difficult to support runtime dynamic adjustments, and front-end permission judgment logic often needs to be repeatedly implemented, resulting in tight coupling between front-end and back-end, low development efficiency, and an inability to meet the comprehensive requirements of flexibility, consistency and security for modern applications. SUMMARY

[0004] In view of the problems existing in the prior art, the present application is proposed.

[0005] Therefore, the problem to be solved by the present application is the security vulnerabilities caused by the dispersion of permission verification logic, incomplete interface coverage, static and fixed permission configuration that is difficult to dynamically adjust, and tight coupling between front-end and back-end, which results in low development efficiency in the prior art permission control system.

[0006] To solve the above technical problems, the present application provides the following technical solutions: In a first aspect, the present application provides a multi-source power grid information fusion method based on the Internet of Things, which includes a full interface mandatory permission verification, all business interfaces are covered by a permission verification layer, and the permission verification layer is a logic layer located before the business logic layer and dedicated to handling permission verification. Centralized dynamic permission management, unified maintenance of permission configuration, support for runtime update and business customization extension, association of permission rules to interfaces through annotations; Simplify front-end and back-end permission processing, configure permissions directly through interface layer annotations on the server side.

[0007] As a preferred scheme of the multi-source power grid information fusion method based on the Internet of Things, wherein: the full interface forced permission verification includes implementing permission verification for each business interface in the interface detection permission system, intercepting all requests through a unified permission verification layer, and comparing the declared permission annotations on the interface with the current user credentials, requests that do not pass the verification are denied access, and no interface is allowed to bypass permission control; The interface detection refers to the behavior of detecting the interface permission state by sending a request with a specific identifier before formally executing data interaction, and the permission annotation refers to declaring the required permissions of a certain interface through annotations in the code; The permission verification layer covers all business interfaces including interface detection, which forces the unified permission verification component to intercept and verify before the request reaches the specific business logic, and the access of each interface must pass through the verification layer, interfaces that are not configured or bypassed cannot be called, ensuring that there is no omission in permission control; The aspect interception refers to an aspect-oriented programming technology that inserts permission verification logic before method execution by intercepting method calls or requests.

[0008] As a preferred scheme of the multi-source power grid information fusion method based on the Internet of Things, wherein: the centralized dynamic permission management includes loading and applying permission rule changes through a central control mechanism during the operation of the interface detection permission system, without the need to modify the code or restart the service, and the interface detection permission system is synchronized to all verification nodes, ensuring that the new rules take effect at the next request verification, and realizing instant adjustment and global consistent execution of permission policies; The unified maintenance of permission configuration includes storing all required permission rules of business interfaces in a single management module, and providing configuration operations such as adding, deleting, modifying and querying by the single management module, avoiding the dispersion of permission information in multiple locations, and ensuring consistent, traceable, and controllable permission definition; The single management module refers to the functional component in the system that is responsible for storing, managing, and providing permission configuration data.

[0009] As a preferred scheme of the multi-source power grid information fusion method based on Internet of Things, the support for runtime update and business customization extension includes a permission system with interface detection, which allows modification of permission rules through a management interface and immediate effect without service interruption or code redeployment, and meanwhile, each business module can register its own permission identifier and verification logic according to the unified permission framework to complete differentiated permission control without affecting the consistency and integrity of the global permission system. The permission identifier is a unique string label assigned to each business interface or operation, which is used to explicitly indicate the required access permission of the interface or operation.

[0010] As a preferred scheme of the multi-source power grid information fusion method based on Internet of Things, the association of the permission rules to the interface through annotation includes using a permission annotation with explicit semantics to explicitly declare the required permission identifier of the interface at the definition of each business interface method on the server, embedding the permission annotation as metadata in the code, reading the permission identifier in the permission annotation by the permission framework through the reflection mechanism at the startup or runtime of the interface detection permission system, and binding the permission identifier in the permission annotation to the access path of the corresponding interface for mandatory verification by the unified permission verification component before request processing, to ensure that only users with specified permissions can call the interface.

[0011] As a preferred scheme of the multi-source power grid information fusion method based on Internet of Things, the front-end and back-end permission processing simplification includes not needing to write any permission judgment or access control logic during front-end development, with the visibility and operation response of all interface elements determined according to the actual results returned by the server interface, the required permission identifier explicitly declared by the permission annotation on each business interface method on the server, and the matching verification of user credentials and permission identifiers automatically completed by the unified permission verification component before the request enters the business logic by the interface detection permission system, without the need for developers to manually insert permission check statements in the interface implementation code.

[0012] As a preferred scheme of the multi-source power grid information fusion method based on Internet of Things, the direct configuration of permissions by the server through interface layer annotation includes explicitly specifying the required permission identifier of the interface using a predefined permission annotation at the code declaration of the business interface method, reading the permission identifier in the permission annotation by the interface detection permission system through the reflection mechanism at runtime, and using the permission identifier as the verification basis for automatic comparison of the permissions held by the current user by the unified permission verification component before the request reaches the business logic, without the need for writing additional permission judgment code in the method body.

[0013] In a second aspect, the embodiment of the present application provides a permission system implementation system based on interface detection, which comprises: a forced verification interception module, full interface forced permission verification, all business interfaces are covered by a permission verification layer, the permission verification layer is a logic layer located before a business logic layer and specially processing permission verification; A centralized configuration management module, centralized dynamic permission management, unified maintenance of permission configuration, support for runtime update and business customization extension, and association of permission rules to interfaces through annotations; An annotation-driven integration module, simplified front-end and back-end permission processing, and direct configuration of permissions by the server through interface layer annotations.

[0014] In a third aspect, the embodiment of the present application provides a computer device comprising a memory and a processor, and the memory stores a computer program, wherein: the processor implements any step of the above-mentioned multi-source power grid information fusion method based on Internet of Things when executing the computer program.

[0015] In a fourth aspect, the embodiment of the present application provides a computer readable storage medium having a computer program stored thereon, wherein: the computer program is executed by a processor to implement any step of the above-mentioned multi-source power grid information fusion method based on Internet of Things.

[0016] The present application has the following beneficial effects: through full interface forced permission verification, all business interfaces are subjected to unified permission verification layer checking without exception, and security loopholes caused by missed checking are completely eliminated; through centralized dynamic permission management, unified maintenance of permission configuration, runtime real-time update and business customization extension are realized, the maintainability and flexibility of the system are significantly improved; through the annotation-driven mode, the permission rules are directly bound to the interfaces, and the checking is automatically executed by the aspect interception, so that the server does not need to write redundant permission code, and the front-end does not need to process permission logic, the development complexity is greatly reduced, the development efficiency is improved, and the consistency, integrity and security of permission control are guaranteed. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor. Among them: Figure 1 A flowchart of a permission system implementation method and system based on interface detection.

[0018] Figure 2 A schematic diagram of a permission system implementation method and system based on interface detection. DETAILED DESCRIPTION

[0019] In order to make the above objectives, features and advantages of the present application more clear and comprehensible, specific embodiments of the present application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work should fall within the protection scope of the present application.

[0020] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. The present application may, however, be practiced in a variety of ways beyond the specific details set forth herein without departing from the scope of the present application. It can be appreciated by those skilled in the art that the present application can be practiced without the specific details set forth in the following description. Accordingly, the present application is not limited in scope by the embodiments described, since the present application is compatible with other model of operation and equivalents at the time of filing.

[0021] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. "In one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or selective embodiment excluding other embodiments.

[0022] The present application is described in detail with reference to the accompanying drawings. In the detailed description of the embodiments of the present application, the sectional view of the device structure is partially enlarged without the general proportion for the convenience of description, and the schematic view is only an example, which should not limit the scope of protection of the present application herein. In addition, the three-dimensional spatial dimensions of length, width and depth should be included in actual manufacture.

[0023] Meanwhile, in the description of the present application, it should be noted that the terms "upper, lower, inner and outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first, second or third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0024] Unless otherwise specifically defined and limited, the terms "mounting, connecting, connection" in the present application should be understood broadly, for example: it can be fixed connection, detachable connection or integral connection; it can also be mechanical connection, electrical connection or direct connection, it can also be indirectly connected through intermediate medium, or it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0025] Embodiment 1 Reference Figure 1 and Figure 2For the first embodiment of the present application, the embodiment provides an interface detection-based permission system implementation method, comprising: S1: full interface mandatory permission verification, all business interfaces are covered by a permission verification layer, the permission verification layer refers to a logic layer located before the business logic layer and specially processing permission verification.

[0026] Among them, the full interface mandatory permission verification includes implementing permission verification for each business interface in the interface detection-based permission system, intercepting all requests through a unified permission verification layer, and comparing the declared permission annotations on the interface with the current user credentials. The request that does not pass the verification is denied access, ensuring that no interface bypasses the permission control; Interface detection refers to the behavior of detecting the interface permission state by sending a request with a specific identifier before formally executing data interaction. The permission annotation refers to declaring the required permissions of an interface through annotation in the code; All business interfaces are covered by the permission verification layer, including that the interface detection-based permission system forces to pass through the unified permission verification component for aspect interception and verification before the request reaches the specific business logic. The access of each interface must pass through the verification layer, and the interface that is not configured or bypasses the verification cannot be called, ensuring that there is no omission in permission control; Aspect interception refers to an aspect-oriented programming technology that inserts permission verification logic before method execution by intercepting method calls or requests.

[0027] Backend aspect interceptor: parse permission annotations, query the current user permission set from the user permission management system, and return 403 Forbidden (no permission) + specific prompt or 200 OK + permission identifier (permission).

[0028] S2: centralized dynamic permission management, unified maintenance of permission configuration, support for runtime update and business customization extension, associate the permission rules to the interface through annotations.

[0029] Among them, the centralized dynamic permission management includes loading and applying permission rule changes through a central control mechanism during the operation of the interface detection-based permission system, without modifying the code or restarting the service. The interface detection-based permission system is synchronized to all verification nodes, ensuring that the new rules take effect at the next request verification, realizing the instant adjustment and global consistent execution of permission strategy; Unified maintenance of permission configuration includes storing all required permission rules of business interfaces in a single management module, and providing configuration operations such as adding, deleting, modifying and querying by the single management module. This avoids the dispersion of permission information in multiple locations, ensuring consistent, traceable and controllable permission definition; The single management module refers to the functional component in the system that is responsible for storing, managing and providing permission configuration data.

[0030] S2.1: The permission system supporting runtime update and business customization extension includes interface detection. Without interrupting service and redeploying code, the permission rules can be modified through the management interface and take effect immediately. Meanwhile, each business module can register its own permission identifier and verification logic according to the unified permission framework to complete differentiated permission control without affecting the consistency and integrity of the global permission system. Permission identifier refers to a unique string label assigned to each business interface or operation, which is used to specify the required access permission of the interface or operation.

[0031] S2.2: The permission rules are associated with the interface through annotations. In the definition of each business interface method on the server side, a permission annotation with explicit semantics is used to explicitly declare the required permission identifier of the interface. The permission annotation is embedded in the code as metadata, which is read by the permission framework through the reflection mechanism at the startup or runtime of the interface detection permission system. The permission identifier in the permission annotation is bound to the access path of the corresponding interface, which is used for mandatory verification by the unified permission verification component before request processing, ensuring that only users with specified permissions can call the interface.

[0032] Data interaction process: the front end initiates a normal modification request (without detection header), the aspect executes permission verification, and the modification service is executed after the verification is passed.

[0033] S3: Simplification of front-end and back-end permission processing, the server directly configures permissions through interface layer annotations.

[0034] Among them, the simplification of front-end and back-end permission processing includes that during the front-end development process, no permission judgment or access control logic needs to be written, and the visibility and operation response of all interface elements are determined according to the actual results returned by the server interface. The server explicitly declares the required permission identifier through a permission annotation on each business interface method. The interface detection permission system automatically completes the matching verification of user credentials and permission identifiers by the unified permission verification component before the request enters the business logic, and the developer does not need to manually insert permission check statements in the interface implementation code.

[0035] S3.1: The server directly configures permissions through interface layer annotations, which includes explicitly specifying the required permission identifier of the interface using a predefined permission annotation at the code declaration of the business interface method. The interface detection permission system reads the permission identifier in the permission annotation through the reflection mechanism at runtime, and uses the permission identifier as the verification basis to automatically compare the permissions held by the current user by the unified permission verification component before the request reaches the business logic, without writing additional permission judgment code in the method body.

[0036] Front end initiates a modification request, Header adds X-Permission-Check: true (agreement Header uses X-Permission-Check), and the front end disables the button or shows a prompt according to the response.

[0037] Further, the embodiment also provides a multi-source power grid information fusion system based on Internet of Things, comprising: a forced verification interception module, a full-interface forced permission verification, all business interfaces are covered by a permission verification layer, the permission verification layer is a logic layer located before a business logic layer and specially processing permission verification; A centralized configuration management module, centralized dynamic permission management, unified maintenance of permission configuration, support for runtime update and business customization extension, and association of permission rules to interfaces through annotations; An annotation-driven integration module, simplifying front-end and back-end permission processing, and directly configuring permissions through interface layer annotations on the server side.

[0038] Interface probing (Interface Probing): refers to the behavior of probing the interface permission state by sending a request with a specific identifier before formally executing data interaction. The request does not execute business logic and only returns the permission verification result.

[0039] Custom Header: A field added in the HTTP request header to identify the purpose of the request. In this patent, it refers to the Header used to distinguish between probe requests and data requests (e.g., X-Permission-Check); Permission Verification Layer: A logic layer located before the business logic layer, specifically designed to handle permission verification. It is responsible for verifying whether the user has the permission to perform subsequent operations; Data Interaction Layer: The part that executes business logic and data processing, which is executed after permission verification; Aspect Interception: An Aspect-Oriented Programming (AOP) technique that inserts permission verification logic at a specific location (e.g., before method execution) by intercepting method calls or requests; Permission Point: A defined permission check point in the system, each point corresponds to a specific operation permission; Permission Annotation: A way to declare the required permissions for an interface in the code through annotations (e.g., @Permission). This annotation is used to configure the behavior of aspect interceptors; Probe Request: An HTTP request with a custom Header, used to trigger the permission probe mode of an interface. This request only performs permission verification, without executing business logic; Data Request: A normal business request, without the probe Header. This request will perform permission verification and business logic in sequence; Aspect-based Dynamic Routing: A process that dynamically decides whether to execute business logic based on the characteristics of the request (such as Header). In permission probing, the routing is to skip the business logic layer; Permission Consistency: The consistency between front-end interaction control and back-end interface permission verification, to avoid the situation where the front-end is prohibited but the back-end is not checked; Frontend-Backend Separation Architecture: A software architecture pattern where the front-end is responsible for display and user interaction, and the back-end provides API interfaces, and the two communicate through the network; Annotation-based Configuration: A way to configure program behavior by adding annotations in the code, with the characteristics of being declarative and low-invasive; This embodiment also provides a computer device applicable to the implementation method of a permission system based on interface probing, including a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the permission system implementation method based on interface probing as proposed in the above embodiment.

[0040] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0041] In summary, this invention provides a method and system for implementing a permission system based on interface detection. Through three core steps—S1 full-interface mandatory permission verification, S2 centralized dynamic permission management, and S3 simplified front-end and back-end permission processing—a highly secure, maintainable, and efficient permission control system is constructed. This method utilizes aspect-oriented interception technology to uniformly verify permissions before business logic execution, combines annotation-based declarative configuration to precisely bind permission rules to each interface, and relies on a single management module to achieve centralized storage and dynamic runtime updates of permission data. The front-end does not need to embed permission judgment logic; it only controls interface behavior based on the server-side return results. The back-end does not need to write redundant verification code, significantly reducing coupling and error risks. Simultaneously, the system supports business modules extending their own permission identifiers and verification strategies within a unified framework, balancing flexibility and consistency. The accompanying mandatory verification interception module, centralized configuration management module, and annotation-driven integration module, as well as the program implementation that can be deployed on general-purpose computer devices, further ensure the feasibility and engineering practicality of this solution in complex business scenarios such as the Internet of Things and power grid information fusion. In addition, the system has a built-in permission audit and tracing mechanism that automatically records the time, user, interface path, required permissions, and verification results of each permission verification, meeting the requirements of information security and compliance. It also supports multi-level caching strategies and circuit breaker degradation design, and can enable local snapshot mode to ensure the continuity of core business when the permission service is temporarily unavailable, thereby achieving dual protection of security and availability in high-concurrency and high-reliability industrial environments.

[0042] Example 2 Reference Figures 1-2 This is the second embodiment of the present invention, which provides a method for implementing a permission system based on interface detection. In order to verify the beneficial effects of the present invention, scientific demonstration is carried out through economic benefit calculation.

[0043] The technical solution of this invention has been successfully implemented at AA Company. AA Company adopts a unified interface detection mechanism, which clearly distinguishes between permission detection requests and actual data interaction requests through a custom HTTP request header (e.g., X-Permission-Check: true). The naming of this header strictly follows HTTP standard specifications such as RFC 7230, and uses the "X-" prefix to identify non-standard but business-defined extended fields. The specific key names and values ​​are uniformly agreed upon internally by the system to ensure consistency and compatibility across team collaborations. In terms of operation, the system adopts a dual-mode processing logic: Probe mode: When the request contains the agreed X-Permission-Check: true header, the permission verification layer only executes the permission verification process—the aspect interceptor parses the permission identifier in the interface annotation, queries the authorization set of the current user in the single permission management module, and returns a structured response after comparison (such as {"code":200, "data":{"hasPermission":true}} or {"code":200, "data":{"hasPermission":false, "required":"device.restart"}}), without entering any business logic processing, avoiding resource waste and side effects; Data mode: When the request does not carry this header, the system executes permission verification + business logic processing in sequence according to the standard process. If the verification fails, it immediately terminates and returns an HTTP 403 Forbidden status code and error details to ensure that no unauthorized operation occurs. In the power IoT business platform, AA Company explicitly declares the required permission identifiers for all backend interfaces (including RESTful APIs and RPC interfaces) using standardized permission annotations (such as `@RequirePermission("grid.substation.config.update")`) in their method declarations. During service startup, the system automatically discovers and registers all annotated interfaces through classpath scanning, constructing a mapping table of "interface path ↔ permission identifier". At runtime, interceptors based on Spring AOP or similar aspect-oriented programming frameworks intervene before requests are dispatched to Controller methods to complete permission matching. Permission rules are centrally stored in a highly available, transaction-supporting single permission management module (based on a MySQL master-slave + Redis caching architecture). This module serves as the sole trusted source, providing a RESTful management interface for the operations and maintenance system to call. Operations and maintenance personnel can configure permissions for roles, users, or organizational units with fine-grained precision through a visual permission management backend.For example, during critical power outages, the authorization of the "Regional Operations Personnel" role for the `device.restart` permission can be revoked in real time. The system broadcasts the change event to all microservice instances through a publish / subscribe mechanism (such as Redis Pub / Sub or Kafka), and the local caches of each node are updated synchronously, ensuring that the new policy is applied on the next request. This process requires no code modification and no rolling service restarts, achieving true runtime dynamic management. During the page initialization phase, the front-end application automatically initiates corresponding probe requests for all sensitive operation buttons (such as "Remote Power Off," "Parameter Reset," and "Data Export"). For example, before clicking the "Device Restart" button, the front-end first sends a HEAD or GET request with `X-Permission-Check: true` to ` / api / device / restart`. Based on the returned `hasPermission` field value, it determines whether to enable the button or display a grayed-out disabled state and a prompt (such as "You do not have device restart permission, please contact the administrator"). This mechanism completely eliminates the hard-coded permission judgment logic on the front-end, making the interface behavior entirely driven by server-side authoritative judgment, effectively preventing clients from bypassing control. In addition, AA Company has also implemented automatic collection of permission audit logs based on this permission system: each permission verification result (whether it passes or fails) records the request path, user ID, permission identifier, verification result and timestamp for security traceability and compliance review; it also supports permission inheritance and combination strategies, such as using @RequireAnyPermission({"admin", "grid.super"}) to enable access as long as any one of the multiple permissions is satisfied, further improving business adaptability; the four-dimensional advantages system of this invention is shown in Table 1 below: Table 1. The Four-Dimensional Advantage System of the Invention

[0044] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for implementing a permission system based on interface detection, characterized in that: include, Full-interface mandatory permission verification is implemented. All business interfaces are covered by a permission verification layer, which is a logic layer located before the business logic layer and specifically handles permission verification. Centralized dynamic permission management, unified maintenance of permission configuration, support for runtime updates and business customization extensions, and permission rules can be associated with interfaces through annotations; The front-end and back-end permission handling is simplified, and the server can directly configure permissions through interface layer annotations.

2. The method for implementing a permission system based on interface detection as described in claim 1, characterized in that: The mandatory permission verification for all interfaces includes performing permission verification on each business interface in the permission system of interface probing. All requests are intercepted through a unified permission verification layer, and the current user credentials are compared with the permission annotations declared on the interface. Requests that fail the verification are denied access, ensuring that no interface bypasses permission control. The interface probing refers to the act of probing the interface permission status by sending a request with a specific identifier before formally executing data interaction. The permission annotation refers to declaring the permissions required for a certain interface in the code through annotations. All business interfaces are covered by the permission verification layer. The permission system, including interface probing, forces a unified permission verification component to intercept and verify the request before it reaches the specific business logic. Access to each interface must go through this verification layer. Interfaces that are not configured or bypassed cannot be called, ensuring that there are no omissions in permission control. Aspect interception refers to an aspect-oriented programming technique that intercepts method calls or requests and inserts permission verification logic before the method is executed.

3. The method for implementing a permission system based on interface detection as described in claim 2, characterized in that: The centralized dynamic permission management includes loading and applying permission rule changes through a central control mechanism during the operation of the interface detection permission system. Without modifying the code or restarting the service, the interface detection permission system is synchronized to all verification nodes, ensuring that the new rules take effect on the next verification request, realizing real-time adjustment of permission policies and consistent global execution. The unified maintenance of permission configuration includes storing the permission rules required by all business interfaces in a single management module. The single management module provides unified CRUD operations for the configuration, avoiding permission information being scattered in multiple locations and ensuring that permission definitions are consistent, traceable, and controllable. The single management module refers to the only functional component in the system responsible for storing, managing, and providing permission configuration data.

4. The method for implementing a permission system based on interface detection as described in claim 3, characterized in that: The aforementioned support for runtime updates and business customization extensions includes an interface-based permission system that allows modification of permission rules through the management interface without interrupting services or redeploying code, with the changes taking effect immediately. At the same time, each business module can register its own permission identifiers and verification logic according to the unified permission framework to achieve differentiated permission control without affecting the consistency and integrity of the global permission system. The permission identifier is a unique string label assigned to each business interface or operation, used to specify the access permissions required for that interface or operation.

5. The method for implementing a permission system based on interface detection as described in claim 4, characterized in that: The method of associating permission rules with interfaces through annotations includes defining each business interface method on the server side. Permission annotations with clear semantics are used to explicitly declare the permission identifiers required by the interface. These permission annotations are embedded as metadata code. When the permission system for interface detection starts or runs, the permission framework reads them through reflection and binds the permission identifiers in the permission annotations to the access paths of the corresponding interfaces. This allows the unified permission verification component to perform mandatory verification before request processing, ensuring that only users with the specified permissions can call the interface.

6. The method for implementing a permission system based on interface detection as described in claim 5, characterized in that: The simplified front-end and back-end permission processing includes the fact that no permission judgment or access control logic needs to be written during the front-end development process. The visibility and operation response of all interface elements are determined based on the actual results returned by the server interface. The server explicitly declares the required permission identifiers on the methods of each business interface through permission annotations. Before the request enters the business logic, the permission detection system automatically completes the matching and verification of user credentials and permission identifiers by a unified permission verification component. Developers do not need to manually insert permission check statements in the interface implementation code.

7. The method for implementing a permission system based on interface detection as described in claim 6, characterized in that: The server directly configures permissions through interface layer annotations. This includes explicitly specifying the required permission identifier for the interface using predefined permission annotations in the code declaration of the business interface method. The permission detection system reads the permission identifier in the permission annotation through reflection at runtime and uses the permission identifier as the basis for verification. The unified permission verification component automatically compares the current user's permissions before the request reaches the business logic, without the need to write additional permission judgment code in the method body.

8. A permission system implementation system based on interface detection, based on the permission system implementation method based on interface detection according to any one of claims 1 to 7, characterized in that: include, The mandatory verification interception module enforces mandatory permission verification across all interfaces. All business interfaces are covered by the permission verification layer, which is a logic layer located before the business logic layer and specifically handles permission verification. The centralized configuration management module enables centralized dynamic permission management, unified maintenance of permission configurations, and supports runtime updates and business customization extensions. Permission rules can be associated with interfaces through annotations. Annotation-driven integration module simplifies front-end and back-end permission handling, allowing the server to directly configure permissions through interface layer annotations.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the permission system implementation method based on interface detection as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the permission system implementation method based on interface detection as described in any one of claims 1 to 7.

Images