A dual configuration-based access permission control method, system, device and medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI QIANJIANG NETWORK TECHNOLOGY CO LTD
- Filing Date
- 2026-05-29
- Publication Date
- 2026-08-07
AI Technical Summary
然而,现有技术在实际应用中,采用静态配置在调整权限时必须重新部署系统,无法适应业务的动态变化;采用动态配置虽支持即时调整,但在开发阶段难以快速绑定权限,且缺乏代码级的版本管理
通过将底层的静态代码注解体系与上层的动态数据库配置体系进行深度解耦与协同设计,打破了传统业务系统中“代码维护便捷性”与“动态调整灵活性”难以兼顾的技术瓶颈。首先,从软件生命周期全局来看,本方案兼顾了开发期基础权限的敏捷绑定与运营期复杂权限的热更新需求,避免了因业务权限变更而引发的代码重构与系统重启,兼顾了开发效率与运维便捷性;其次,本申请在宏观架构上建立的优先级明确的权限校验规则,有效解决了现有技术中因多种配置耦合冲突导致的越权访问或禁止异常等底层安全漏洞;最后,这种高内聚低耦合的双重权限管控底座,使得大型企业级应用能够在面对复杂的业务功能扩张、组织架构变动或底层中间件异常等极端场景时,依然保持稳定的安全防御水位和连贯的用户访问体验,提升了整体网络系统的工程健壮性与商业可用性。
Smart Images

Figure CN122528186A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security technology, and in particular to a dual-configuration-based access control method, system, device, and medium. Background Technology
[0002] As enterprise application systems and back-end management systems become increasingly complex, system business iterations and functional architecture evolutions are becoming more frequent. How to precisely control and flexibly adjust access permissions for pages and function buttons within the system based on user roles and permission levels has become a core requirement for ensuring system information security and standardizing user operations.
[0003] In existing technologies, page access control is typically implemented through annotation-based static configuration or database-based dynamic configuration. For example, during code development, permissions are bound by adding permission annotations to page routes or functional interfaces, or permissions are verified by querying role relationships stored in the database during system runtime. However, in practical applications, existing technologies have limitations. Static configuration requires system redeployment when adjusting permissions, making it unsuitable for dynamic business changes. While dynamic configuration supports immediate adjustments, it's difficult to quickly bind permissions during development and lacks code-level version management. When facing complex and frequent business changes, existing access control methods struggle to simultaneously balance code maintenance efficiency at the development level with the immediate effectiveness of permissions at the operational level. When the system updates or maintains permission rules, there are risks of delayed permission status synchronization, unauthorized users being allowed unauthorized access, or legitimate users being abnormally blocked from access. Summary of the Invention
[0004] In view of this, this application provides a dual-configuration-based access control method, system, device, and medium to solve the above problems.
[0005] Firstly, a dual-configuration-based access control method is provided, which includes: Obtain first configuration information and second configuration information. The first configuration information is preset static code annotation data, and the second configuration information is preset dynamic database table data. The first configuration information and the second configuration information are independent of each other. Both the first configuration information and the second configuration information contain resource identifiers and corresponding authorized role lists. The second configuration information also contains an effective status identifier. The first configuration information is independently written to a preset first cache, and the second configuration information is independently written to a preset second cache, wherein the first cache and the second cache are isolated from each other; Receive an access request, which carries the target resource identifier and user role information; In response to the access request, a retrieval is performed in the preset second cache based on the target resource identifier to query the second configuration information; If a second configuration information matching the target resource identifier is found, and the effective status identifier indicates that it is enabled, then the matching second configuration information is determined as the target configuration information. If no second configuration information matching the target resource identifier is found, or if the query for the second configuration information is abnormal, or if the effective status identifier of the found second configuration information indicates a disabled state, a degradation processing mechanism is triggered. The first configuration information is then queried based on the target resource identifier. Specifically, the degradation processing mechanism includes: capturing timeout exception events or null value return events generated when performing a search in a preset second cache, generating a degradation switching instruction based on the timeout exception event or null value return event, and routing the search to a preset first cache to perform a search to extract the matching first configuration information according to the degradation switching instruction. If the first configuration information that matches the target resource identifier is found, then the first configuration information that matches is determined as the target configuration information; After determining the target configuration information, check whether the user role information exists in the authorized role list corresponding to the target configuration information; If it exists, the access request is deemed to have passed the permission verification; If the first configuration information that matches the target resource identifier does not exist, or if the query for the first configuration information is abnormal, then the access request is determined to have failed the permission verification.
[0006] The above technical solution obtains independent first static configuration and second dynamic configuration, and prioritizes querying the dynamic configuration with status identifier when receiving access requests. If the dynamic configuration is missing, abnormal, or in a disabled state, it triggers a fallback to query the static configuration. Finally, it determines the role based on the determined configuration. This can establish a two-layer permission architecture with disaster recovery and proactive hot switching capabilities. While ensuring real-time dynamic control of permissions, it prevents the entire permission system from being paralyzed due to the loss of a single layer configuration or service failure.
[0007] Optionally, the preset static permission configuration data is specifically preset static code annotation data, and the permission configuration data that supports dynamic updates is specifically preset dynamic database table data. After obtaining the first configuration information and the second configuration information, the method further includes: Extract the resource identifier contained in the first configuration information and the resource identifier contained in the second configuration information and perform a consistency comparison operation. If the comparison result indicates that the first configuration information and the second configuration information contain the same resource identifier, it is determined that there is a duplicate configuration and a configuration conflict prompt message is generated.
[0008] The above technical solution, by independently writing static code annotation data and dynamic database table data into two isolated caches, and extracting the resource identifiers contained in both to perform consistency comparison to generate prompt information, can improve the speed of permission data reading and cut off the physical coupling between the two mechanisms. At the same time, it can proactively discover duplicate definition nodes generated under dual configuration mode and avoid configuration chaos in the later operation and maintenance process.
[0009] Optionally, after independently writing the second configuration information to a preset second cache, the method further includes: Establish a data node change monitoring task for preset dynamic database table data; Receive incremental configuration change data returned by the data node change monitoring task; Based on the incremental configuration change data, a synchronous overwrite operation is performed on the second configuration information in the preset second cache.
[0010] The above technical solution, by establishing a data node change monitoring task for the underlying dynamic database table data, and performing a synchronous overwrite operation on the second cache after obtaining the incremental data of the change, can achieve near real-time hot updates of dynamic permission rules from the database to the high-speed cache without restarting the entire computer business system, ensuring the immediate effectiveness of permission adjustments during business operation.
[0011] Optionally, the second configuration information can be queried based on the target resource identifier, specifically including: Parse the target resource identifier and extract the corresponding target page access identifier and target function node identifier; Perform string concatenation on the target page access identifier and the target function node identifier to generate the target query key value; Based on the target query key value, perform a key-value matching operation in the preset second cache to extract the matching second configuration information.
[0012] The above technical solution decomposes the target resource identifier into a page access identifier and a function node identifier, and performs string concatenation to generate a unique target query key value. Then, it performs key value matching in the dynamic cache, which can transform the complex "page-function" two-dimensional permission mapping into a flat one-dimensional key value retrieval at the computer's underlying level. This effectively reduces the system's query time complexity and improves the verification efficiency in high-concurrency scenarios.
[0013] Optionally, capture timeout exception events that occur when performing a retrieval in a preset second cache, specifically including: If the time for a single query to the second cache exceeds the preset time threshold, a single timeout exception event is determined to occur. Count the frequency of timeout exceptions that occur within a preset time window; If the frequency exceeds the preset safety level, the preset fuse state will be switched from closed to open, and all subsequent second configuration information query requests will be intercepted in the open state. A downgrade switching instruction will be directly generated to short-circuit the route to the preset first cache for retrieval.
[0014] The above technical solution captures timeout or null value return events generated at the underlying level in real time during the dynamic cache query process, and generates switching instructions based on these physical events to route the target query key value to the static cache for retrieval. This enables the abstract concept of "business degradation" to be implemented as a precise computer underlying fault transfer scheduling mechanism, ensuring the anti-interference and anti-blocking capabilities of the permission verification process.
[0015] Optionally, determine whether the user role information exists in the authorized role list corresponding to the target configuration information, specifically including: Parse the target configuration information and extract the legal role sequence corresponding to the authorized role list from the target configuration information; Extract the role code to be verified from the user role information; Traverse the valid role sequence, perform consistency matching comparison between the role code to be verified and the elements in the valid role sequence, and generate a matching status identifier based on the comparison result.
[0016] The above technical solution extracts a sequence of legitimate roles from the target configuration information and obtains the role code to be verified carried in the current request. Then, it performs consistency matching and comparison one by one by code traversal and generates underlying status identifiers. This can transform the macroscopic "permission existence determination" into a microscopic iterative comparison instruction stream that can be stably executed by the computer, and standardizes and closes the core algorithm steps of permission verification.
[0017] Optionally, a consistency matching comparison is performed between the role code to be verified and the elements in the legal role sequence, and a matching status identifier is generated based on the comparison result, specifically including: Perform a parsing operation on the character code to be verified, and extract the parent character attributes bound to the character code to be verified; The character code to be verified and the parent character attributes are combined to generate a target comparison character set; Determine whether there is a target role in the target comparison role set that matches an element in the legal role sequence, and generate a matching status identifier based on the determination result.
[0018] The above technical solution, by further parsing the code of the role to be verified to extract the attributes of its bound parent role before the comparison is executed, and combining its own code with the parent attributes to form a target comparison role set before judging it with the legal sequence, enables the permission comparison algorithm to be automatically compatible with the permission verification rules based on the role inheritance tree system, which greatly reduces the repetitive underlying configuration data caused by the nesting of role levels.
[0019] Secondly, a dual-configuration-based access control system is provided, the system comprising: The configuration acquisition module is used to acquire first configuration information and second configuration information. The first configuration information is preset static code annotation data, and the second configuration information is preset dynamic database table data. The first configuration information and the second configuration information are independent of each other. Both the first configuration information and the second configuration information contain resource identifiers and corresponding authorized role lists. The second configuration information also contains an effective status identifier. The module independently writes the first configuration information into a preset first cache and independently writes the second configuration information into a preset second cache. The first cache and the second cache are isolated from each other. The request receiving module is used to receive access requests, which carry the target resource identifier and user role information. A configuration query module is used to respond to access requests by performing a retrieval in a preset second cache based on the target resource identifier to query second configuration information. If second configuration information matching the target resource identifier is found and the effective status identifier indicates an enabled state, the matched second configuration information is determined as the target configuration information. If no second configuration information matching the target resource identifier is found, or an error occurs during the query for second configuration information, or the effective status identifier of the found second configuration information indicates a disabled state, a degradation processing mechanism is triggered. The module then queries first configuration information based on the target resource identifier. Specifically, triggering the degradation processing mechanism includes: capturing timeout exception events or null value return events generated during the retrieval in the preset second cache, generating a degradation switching instruction based on the timeout exception event or null value return event, and routing the retrieval to the preset first cache to extract the matching first configuration information according to the degradation switching instruction. If first configuration information matching the target resource identifier is found, the matched first configuration information is determined as the target configuration information. The permission verification module is used to determine whether the user role information exists in the authorized role list corresponding to the target configuration information after the target configuration information is determined. If it exists, the access request is determined to pass the permission verification. If it does not exist, or if the first configuration information matching the target resource identifier is not found, or if the query for the first configuration information is abnormal, the access request is determined to fail the permission verification.
[0020] Thirdly, an electronic device is provided, including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform any of the methods described above.
[0021] Fourthly, a computer-readable storage medium is provided, which stores instructions that, when executed, perform the method described in any of the above.
[0022] In summary, implementing one or more technical solutions provided in this application has at least the following technical effects or advantages: By deeply decoupling and collaboratively designing the underlying static code annotation system with the upper-level dynamic database configuration system, this solution breaks through the technical bottleneck of balancing "ease of code maintenance" and "flexibility of dynamic adjustment" in traditional business systems. First, from a global software lifecycle perspective, this solution balances the agile binding of basic permissions during development with the hot-update requirements of complex permissions during operation, avoiding code refactoring and system restarts caused by changes in business permissions, thus balancing development efficiency and ease of maintenance. Second, the clearly prioritized permission verification rules established at the macro-architecture level effectively address underlying security vulnerabilities such as unauthorized access or abnormal access restrictions caused by conflicts in multiple configuration couplings in existing technologies. Finally, this highly cohesive and loosely coupled dual permission control foundation enables large enterprise applications to maintain a stable level of security defense and a consistent user experience even in extreme scenarios such as complex business function expansion, organizational structure changes, or underlying middleware anomalies, improving the overall engineering robustness and commercial availability of the network system. Attached Figure Description
[0023] Figure 1 This is an exemplary system architecture diagram of an access control method or an access control system based on dual configuration according to this application; Figure 2 This is a flowchart illustrating a dual-configuration-based access control method disclosed in this application; Figure 3 This is a schematic diagram of a dual-configuration-based access control system disclosed in this application; Figure 4 This is a schematic diagram of the structure of an electronic device disclosed in this application.
[0024] Explanation of reference numerals in the attached figures: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Configuration acquisition module; 302, Request receiving module; 303, Configuration query module; 304, Permission verification module; 401, Processor; 402, Communication bus; 403, User interface; 404, Network interface; 405, Memory. Detailed Implementation
[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.
[0026] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.
[0027] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.
[0028] Figure 1 An exemplary system architecture diagram is shown, illustrating an embodiment of a dual-configuration-based access control method or a dual-configuration-based access control system to which this application can be applied.
[0029] like Figure 1 As shown, the system architecture 100 may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.
[0030] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.
[0031] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.
[0032] When terminals 101, 102, and 103 are hardware devices, video capture devices can also be installed on them. These video capture devices can be various devices capable of capturing video, such as cameras, sensors, etc. Users can use the video capture devices on terminals 101, 102, and 103 to capture video.
[0033] Server 105 can be a server that provides various services, such as a backend server for processing data displayed on terminal devices 101, 102, and 103. The backend server can analyze and process the received data and can feed back the processing results (such as recognition results) to the terminal devices.
[0034] It should be noted that a server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.
[0035] It should be understood that Figure 1The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included. In particular, if the target data does not need to be obtained remotely, the above system architecture may exclude the network and include only terminal devices or servers.
[0036] Figure 2 This is a flowchart illustrating a dual-configuration-based access control method according to an embodiment of this application. This method can be implemented using a computer program, a microcontroller, or run on a dual-configuration-based access control system. The computer program can be integrated into an application or run as a standalone utility application. The specific steps of a dual-configuration-based access control method are described in detail below.
[0037] S201: Obtain first configuration information and second configuration information. The first configuration information is preset static code annotation data, and the second configuration information is preset dynamic database table data. The first configuration information and the second configuration information are independent of each other. Both the first configuration information and the second configuration information contain resource identifiers and corresponding authorized role lists. The second configuration information also contains an effective status identifier. Write the first configuration information independently to a preset first cache and write the second configuration information independently to a preset second cache. The first cache and the second cache are isolated from each other.
[0038] For example, the first configuration information is implemented using the custom annotation `@PagePermission`, which is placed on the system page routing method. The annotation parameters include `pageId` (page identifier), `funcId` (function identifier), `roleList` (role list), `enable` (enabling identifier), and `remark` (remark). For instance, the annotation `@PagePermission(pageId="EMP_MANAGE",funcId="QUERY",roleList={"ADMIN","HR"},enable=true,remark="Employee management page query permission, only administrators and HR can access")` is added to the query route of the "Employee Management Page". The annotation configuration information takes effect with the system code deployment; modifying the annotation requires redeploying the system, reducing the risk of accidental tampering with the configuration during runtime and ensuring data stability. The second configuration information is implemented using a MySQL database, creating a permission configuration table `sys_permission`. Core fields include `id` (auto-incrementing primary key), `pageId`, `funcId`, `roleList` (JSON format), `enable` (1=enabled, 0=disabled), `updateTime`, `operator`, and `remark`. Administrators can perform data operations on this table through the system's backend permission management interface, enabling dynamic permission configuration without modifying code or restarting the system. For example, adding a new database configuration: pageId="EMP_MANAGE", funcId="QUERY", roleList=["ADMIN","HR","MANAGER"], enable=1, updateTime="2026-04-07 10:30:00", operator="admin", remark="Dynamically adjust employee management page query permissions; newly added manager roles can access".
[0039] Specifically, upon system startup, the annotation configuration module reads all configuration information annotated with `@PagePermission`, while the database configuration module reads all valid configurations (enable=1) from the `sys_permission` table. Both types of configurations undergo format validation, verifying that `pageId` and `funcId` are not empty, `roleList` is not empty and represents a valid role within the system, and that the `enable` value conforms to the specifications. After successful validation, the annotation configuration information is independently cached in the annotation configuration cache (i.e., the first cache, using Redis caching), and the database configuration information is independently cached in the database configuration cache (i.e., the second cache, using Redis caching). This independent caching design ensures physical isolation between the two configuration mechanisms, avoiding mutual interference.
[0040] In one possible implementation, after independently writing the first configuration information into a preset first cache and independently writing the second configuration information into a preset second cache, the method further includes: extracting the resource identifier contained in the first configuration information and performing a consistency comparison operation on the resource identifier contained in the second configuration information; if the comparison result indicates that the first configuration information and the second configuration information contain the same resource identifier, it is determined that there is a duplicate configuration and a configuration conflict prompt message is generated.
[0041] Specifically, during the aforementioned verification process, a preliminary consistency check is performed simultaneously. If pageId="EMP_MANAGE" and funcId="QUERY" are detected in both annotation configuration and database configuration, a duplicate configuration is determined, and a configuration conflict warning is output (this does not affect the configuration's effectiveness). This mechanism can proactively discover duplicate defined nodes through consistency comparison, avoiding configuration chaos during later operation and maintenance.
[0042] In practical engineering applications, the generated "configuration conflict alerts" are not only recorded as internal system logs but also proactively communicated through dedicated monitoring and early warning components. Specifically, the system encapsulates these alerts into standardized JSON format alarm messages and pushes them to an enterprise-level centralized log analysis platform (such as an ELK cluster) via the system's internal message publish / subscribe bus for categorization and visualization. Alternatively, the system can further utilize a pre-defined webhook mechanism to automatically trigger the robot interface of enterprise-level communication and collaboration software (such as DingTalk, WeChat Work, Lark, etc.) to send real-time alert cards containing conflict resource identifiers to designated operations and maintenance personnel or security team groups. This mechanism achieves a closed loop of proactive discovery and manual intervention for dual-source configuration conflicts, preventing potential configuration conflicts from being overlooked.
[0043] In one possible implementation, after independently writing the second configuration information into a preset second cache, the method further includes: establishing a data node change monitoring task for preset dynamic database table data; receiving configuration change incremental data returned by the data node change monitoring task; and performing a synchronous overwrite operation on the second configuration information in the preset second cache based on the configuration change incremental data.
[0044] Specifically, a database configuration cache monitoring mechanism is implemented. When data in the `sys_permission` table is added, modified, or deleted, the cache is updated immediately to ensure consistency between the cache and the database. This closed-loop "change-monitor-update" mechanism enables near real-time hot updates of dynamic permission rules from the database to the cache without restarting the entire computer business system, ensuring the immediate effectiveness of permission adjustments during business operation. In practical engineering, the aforementioned data node change monitoring task for preset dynamic database table data can be implemented by deploying database log parsing components (such as Canal, Debezium, etc.). This monitoring task subscribes to the MySQL database's Binlog file in real time. When administrators perform INSERT, UPDATE, or DELETE operations on the `sys_permission` table in the background, the monitoring task captures these row-level change events in real time and deserializes the data before and after the change into configuration change incremental data. Subsequently, this incremental data is pushed to the application layer through a message queue or direct connection mechanism. After receiving the data, the application layer accurately locates the corresponding target query key in Redis (secondary cache) and performs atomic overwrite or delete operations. This monitoring mechanism based on underlying logs effectively decouples business code from permission caching, achieving millisecond-level hot synchronization of permission rules.
[0045] S202: Receive an access request. The access request carries the target resource identifier and user role information.
[0046] For example, an access request can be a page access request, API call request, or function operation request initiated by a user through a client. The target resource identifier is used to uniquely identify the accessed resource object; for example, it can be a page identifier, API address, or index code of a function button. User role information is used to characterize the identity and permission level of the user initiating the request, such as administrator, regular user, or visitor. After receiving the request, the system parses and extracts the above key information as the basis for subsequent permission verification. For example, when a user (role MANAGER) initiates an access request for the "Employee Management Page" query function, the system extracts pageId="EMP_MANAGE", funcId="QUERY", and the user role MANAGER from the request. This information will serve as input parameters for subsequent permission verification.
[0047] S203: In response to the access request, perform a retrieval in the preset second cache based on the target resource identifier to query the second configuration information.
[0048] For example, after receiving an access request, the system first attempts to retrieve whether there is a permission rule matching the target resource identifier from the second configuration information. This "dynamic priority" design logic allows operations and maintenance personnel to flexibly adjust the permission policy according to actual business needs without restarting the system, thereby improving the system's business adaptability.
[0049] In one possible implementation, querying the second configuration information based on the target resource identifier specifically includes: parsing the target resource identifier and extracting the corresponding target page access identifier and target function node identifier; performing a string concatenation operation on the target page access identifier and target function node identifier to generate a target query key value; and performing a key-value matching operation in a preset second cache based on the target query key value to extract the matching second configuration information.
[0050] Specifically, the system breaks down the target resource identifier into a page access identifier and a function node identifier, and performs string concatenation to generate a unique target query key. For example, pageId="EMP_MANAGE" and funcId="QUERY" are concatenated into "EMP_MANAGE:QUERY", and then key-value matching is performed in the dynamic cache. This design transforms the complex two-dimensional "page-function" permission mapping into a flat, one-dimensional key-value retrieval at the computer's underlying level, effectively reducing the system's query time complexity and improving validation efficiency in high-concurrency scenarios.
[0051] S204: If a second configuration information matching the target resource identifier is found, and the effective status identifier indicates that it is enabled, then the matching second configuration information is determined as the target configuration information.
[0052] For example, if a configuration record for the target resource identifier is successfully retrieved in the second configuration information, and the enable field of that configuration record is 1 (enabled), the system will directly perform verification based on that configuration record. The verification process typically includes: parsing the list of allowed roles in the configuration record and determining whether the currently requested user role information is included in that list. If included, the verification passes, and access is allowed; if not included, the verification fails, and access is denied. This step establishes the highest priority for dynamic configurations in the verification logic, ensuring that the latest permission adjustment policies take effect immediately. For example, querying the database configuration cache finds a valid configuration (enable=1) with pageId="EMP_MANAGE" and funcId="QUERY", whose roleList includes ADMIN, HR, and MANAGER. In this case, even if the roleList in the annotation configuration only includes ADMIN and HR, the database configuration has a higher priority, so the database configuration takes precedence, thus achieving database configuration overriding annotation configuration.
[0053] S205: If no second configuration information matching the target resource identifier is found, or if the query for the second configuration information is abnormal, or if the effective status identifier of the found second configuration information indicates a disabled state, a degradation processing mechanism is triggered. The first configuration information is queried according to the target resource identifier. Specifically, triggering the degradation processing mechanism includes: capturing timeout exception events or null value return events generated when performing a search in a preset second cache, generating a degradation switching instruction based on the timeout exception event or null value return event, and routing the search to a preset first cache to perform a search to extract the matching first configuration information according to the degradation switching instruction.
[0054] For example, this step constructs a defensive fallback mechanism for the system. During the dynamic cache query phase, the system captures timeout or null value return events generated at the underlying level in real time (such as database connection timeouts for dynamically configured data, cache service crashes, etc.), and uses these physical events as trigger conditions to generate switching instructions, routing the retrieval to the static cache for execution. This design translates the abstract concept of "business degradation" into a precise underlying computer failover scheduling mechanism, ensuring the anti-interference and anti-blocking capabilities of the permission verification process. The first configuration information typically refers to a highly stable static configuration source packaged and deployed with the system code. This "static fallback" design enhances the system's high availability and integrity.
[0055] In one possible implementation, capturing timeout exceptions generated during retrieval in a preset second cache includes: if the time for a single query to the preset second cache exceeds a preset time threshold, a single timeout exception is determined; the frequency of timeout exceptions generated within a preset time window is counted; if the frequency exceeds a preset safety level, the preset fuse state is switched from closed to open, and all subsequent second configuration information query requests are intercepted in the open state, and a downgrade switching instruction is directly generated to short-circuit the route to the preset first cache for retrieval.
[0056] Specifically, to prevent a large number of access requests from exhausting the system thread pool due to timeouts in the event of a severe failure in the second cache (such as a Redis cluster), the aforementioned operation of capturing timeout exceptions can be combined with a circuit breaker mechanism. Specifically, the system can preset a time threshold (e.g., 50ms). When the time for a single query to the second cache exceeds this threshold, it is determined as a timeout exception and a single degradation is triggered. Simultaneously, the system counts the frequency of exception events within a preset time window (e.g., 10 seconds). When the frequency exceeds a preset safety level, the circuit breaker switches from closed to open. In the open state, the system intercepts all subsequent second configuration information query requests, directly generates a degradation switching instruction, and short-circuit all requests to the first cache for local high-speed retrieval. Once the second cache heartbeat is detected to be normal, the circuit breaker switches back to closed. This design effectively ensures the availability of the permission verification module in high-concurrency scenarios.
[0057] S206: If the first configuration information that matches the target resource identifier is found, then the matching first configuration information is determined as the target configuration information.
[0058] For example, if a configuration record for the target resource identifier is successfully retrieved in the first configuration information, the system will perform verification based on that configuration record. Since the first configuration information is packaged and deployed along with the system code, it resides in the application's local memory or class files and does not depend on any external storage services or network connections. Therefore, even in the extreme case of a complete failure of the caching service, the system can still maintain basic access control capabilities based on the first configuration information. For example, for core management pages, developers typically preset strict access permissions in code annotations (e.g., allowing only administrator access). In degraded mode, these core security policies remain effective, ensuring that the system can still perform basic permission interception during a failure, preventing unauthorized access. This design ensures the basic availability of the overall system control flow by shielding dynamic update features during failures. During degrade, although the system cannot perceive the latest dynamic permission adjustments (e.g., temporarily granted permissions will become invalid), it can still guarantee the basic operation and security baseline of the system. Simultaneously, when the system switches to degraded mode, it records corresponding fault logs and triggers alarms, prompting operations personnel to promptly repair the caching service, thereby achieving rapid fault detection and recovery.
[0059] S207: After determining the target configuration information, determine whether the user role information exists in the list of authorized roles corresponding to the target configuration information.
[0060] For example, the system parses the target configuration information, extracts a list of authorized roles, and then compares the user role information with this list. If the user role exists in the list of authorized roles, the verification is deemed successful, and access is allowed; otherwise, the verification is deemed unsuccessful, and access is denied.
[0061] In one possible implementation, determining whether user role information exists in the authorized role list corresponding to the target configuration information specifically includes: parsing the target configuration information and extracting the legal role sequence corresponding to the authorized role list from the target configuration information; extracting the role code to be verified from the user role information; traversing the legal role sequence, performing a consistency matching comparison between the role code to be verified and the elements in the legal role sequence, and generating a matching status identifier based on the comparison result.
[0062] Specifically, the system extracts a sequence of legitimate roles from the target configuration information and obtains the role code to be verified carried in the current request. Then, it performs consistency matching and comparison one by one through code traversal and generates underlying status identifiers. This design can transform the macroscopic "permission existence determination" into a microscopic iterative comparison instruction stream that can be stably executed by the computer, standardizing and closing the core algorithm steps of permission verification.
[0063] Furthermore, to address the performance challenges of high-concurrency access in enterprise systems, the system has undergone deep data structure optimization at the in-memory computing level for the consistency matching and comparison operation performed on the aforementioned "traversing the sequence of legal roles". Instead of using a linear traversal algorithm with a time complexity of O(n) for ordinary lists, the system preprocesses the sequence of legal roles and the generated set of target roles to be verified during in-memory processing, transforming them into hash sets or bitmap-based data structures. During matching and comparison, the system directly calls the intersection operation logic of the underlying sets; if the intersection of the two sets is not empty, it directly determines that a matching target role exists. This optimization significantly reduces the time complexity of permission comparison in high-concurrency scenarios to O(1), significantly reducing the CPU computational overhead of the fine-grained permission verification process and alleviating the system performance bottleneck.
[0064] In one possible implementation, a consistency matching comparison is performed between the role code to be verified and the elements in the legal role sequence, and a matching status identifier is generated based on the comparison result. Specifically, this includes: performing a parsing operation on the role code to be verified to extract the parent role attributes bound to the role code to be verified; combining the role code to be verified and the parent role attributes to generate a target comparison role set; determining whether there is a target role in the target comparison role set that matches the elements in the legal role sequence, and generating a matching status identifier based on the determination result.
[0065] Specifically, before the comparison is executed, the system further parses the code of the role to be verified to extract the attributes of its bound parent roles, and combines its own code with the parent attributes to form a target set of roles for comparison before comparing it with the valid sequences. This design enables the permission comparison algorithm to automatically be compatible with permission verification rules based on the role inheritance tree system, significantly reducing the repetitive underlying configuration data caused by role hierarchy nesting. For example, if the parent role of the MANAGER role is ADMIN, then when the valid role sequence contains ADMIN, the MANAGER role automatically obtains access permissions, without needing to explicitly add MANAGER in the configuration.
[0066] In the specific underlying architecture implementation, the system can physically store the inheritance relationship graph between roles by constructing a role association table (e.g., the `sys_role_relation` table) in a relational database or by pre-building a tree-like topology in the caching service. Furthermore, to avoid deep recursive query loops and performance degradation caused by multi-level nested inheritance (e.g., role A inherits from B, B inherits from C), the system employs a "pre-computation and flattened caching" strategy when extracting the parent role attributes bound to the role code to be verified: that is, when a role inheritance relationship is established or updated, the system pre-computes all ancestor nodes of the role in the background and directly stores them as a flattened one-dimensional set in a high-frequency cache. During the runtime verification phase, the system only needs to perform a cache hit once to obtain all bound parent role attributes, significantly shortening the tracing time of the inheritance chain.
[0067] S208: If it exists, the access request is deemed to have passed the permission verification.
[0068] For example, if the user role exists in the authorized role list, the system determines that the verification is successful and allows the user to access the function. The system will return a "allow" decision result, and can either return the result to the request receiving module or directly allow the request. At this time, the user can normally access the target resource and perform the corresponding operation. For example, when a user with the role of MANAGER initiates an access request for the "Employee Management Page" query function, the database configuration cache is queried to find a valid configuration (enable=1) with pageId="EMP_MANAGE" and funcId="QUERY", whose roleList includes ADMIN, HR, and MANAGER. After comparison, the current user role MANAGER exists in the list, the verification module determines that the verification is successful and allows the user to access the function. In this process, although the first configuration information (annotation) does not contain the MANAGER role, according to the priority adjudication mechanism set by this invention, the second configuration information covers the limitations of the first configuration information, realizing the dynamic expansion of permissions. Through the above logic, changes in business permissions can be implemented without modifying the code, improving the dynamic adaptability of the system.
[0069] S209: If the first configuration information matching the target resource identifier does not exist, or if the query for the first configuration information is abnormal, then the access request is determined to have failed the permission verification.
[0070] For example, there are three scenarios in which an access request fails permission verification: one is that the user role does not exist in the authorized role list, i.e., "does not exist"; another is that no first configuration information matching the target resource identifier is found, i.e., "not found"; and the third is that an error occurs when querying the first configuration information, i.e., "query failed". In any of these scenarios, the system determines that the verification has failed and denies the user access. The system will return a "deny" decision result, and may return the result to the request receiving module or directly intercept the request. At the same time, the system will record a permission verification exception log, including information such as the request pageId, funcId, user role, and verification time, for subsequent traceability. For example, if the user role is STAFF, querying the database configuration cache shows that its roleList does not contain STAFF, and further querying the annotation configuration cache also shows that its roleList does not contain STAFF, resulting in verification failure, denial of user access, and recording of the permission verification exception log. For example, if a Redis cache read fails during the permission verification process, the system automatically switches to a downgraded verification mode, querying only the annotation configuration cache and using the annotation configuration as the verification basis; if the annotation configuration cache also cannot be read, user access is denied and an alarm message is sent to the administrator.
[0071] Figure 3 This is a schematic diagram of a dual-configuration-based access control system according to an embodiment of this application. This system can be implemented as all or part of a system through software, hardware, or a combination of both. For example... Figure 3 As shown, the system includes: The configuration acquisition module 301 is used to acquire first configuration information and second configuration information. The first configuration information is preset static code annotation data, and the second configuration information is preset dynamic database table data. The first configuration information and the second configuration information are independent of each other. Both the first configuration information and the second configuration information contain resource identifiers and corresponding authorized role lists. The second configuration information also contains an effective status identifier. The first configuration information is independently written to a preset first cache, and the second configuration information is independently written to a preset second cache. The first cache and the second cache are isolated from each other. Request receiving module 302 is used to receive access requests, which carry the target resource identifier and user role information; The configuration query module 303 is used to respond to access requests by performing a retrieval in a preset second cache based on the target resource identifier to query second configuration information. If second configuration information matching the target resource identifier is found and the effective status identifier indicates an enabled state, the matched second configuration information is determined as the target configuration information. If no second configuration information matching the target resource identifier is found, or an error occurs during the query for second configuration information, or the effective status identifier of the found second configuration information indicates a disabled state, a degradation processing mechanism is triggered to query first configuration information based on the target resource identifier. Specifically, triggering the degradation processing mechanism includes: capturing timeout exception events or null value return events generated during the retrieval in the preset second cache, generating a degradation switching instruction based on the timeout exception event or null value return event, and routing the retrieval to the preset first cache to extract the matching first configuration information according to the degradation switching instruction. If first configuration information matching the target resource identifier is found, the matched first configuration information is determined as the target configuration information. The permission verification module 304 is used to determine whether the user role information exists in the authorized role list corresponding to the target configuration information after determining the target configuration information; if it exists, the access request is determined to pass the permission verification; if it does not exist, or the first configuration information matching the target resource identifier is not found, or the query of the first configuration information is abnormal, the access request is determined to fail the permission verification.
[0072] Based on the above embodiments, as an optional embodiment, the configuration acquisition module 301 is specifically used to: extract the resource identifier contained in the first configuration information and the resource identifier contained in the second configuration information and perform a consistency comparison operation; if the comparison result indicates that the first configuration information and the second configuration information contain the same resource identifier, it is determined that there is a duplicate configuration and a configuration conflict prompt message is generated.
[0073] Based on the above embodiments, as an optional embodiment, the configuration acquisition module 301 is specifically used for: establishing a data node change monitoring task for preset dynamic database table data; receiving configuration change incremental data returned by the data node change monitoring task; and performing a synchronous overwrite operation on the second configuration information in the preset second cache based on the configuration change incremental data.
[0074] Based on the above embodiments, as an optional embodiment, the configuration query module 303 is specifically used for: parsing the target resource identifier, extracting the corresponding target page access identifier and target function node identifier; performing a string concatenation operation on the target page access identifier and target function node identifier to generate a target query key value; and performing a key-value matching operation in a preset second cache according to the target query key value to extract the matching second configuration information.
[0075] Based on the above embodiments, as an optional embodiment, the configuration query module 303 is specifically used for: if the time of a single query to the preset second cache exceeds a preset time threshold, then determining that a single timeout exception event has occurred; counting the frequency of timeout exception events generated within a preset time window; if the frequency exceeds a preset safety level, then switching the preset fuse state from closed to open, and intercepting all subsequent second configuration information query requests in the open state, directly generating a downgrade switching instruction to short-circuit the route to the preset first cache for retrieval.
[0076] Based on the above embodiments, as an optional embodiment, the permission verification module 304 is specifically used to: parse the target configuration information, extract the legal role sequence corresponding to the authorized role list from the target configuration information; extract the role code to be verified from the user role information; traverse the legal role sequence, perform consistency matching comparison between the role code to be verified and the elements in the legal role sequence, and generate a matching status identifier based on the comparison result.
[0077] Based on the above embodiments, as an optional embodiment, the permission verification module 304 is specifically used for: performing a parsing operation on the role code to be verified, extracting the parent role attributes bound to the role code to be verified; combining the role code to be verified and the parent role attributes to generate a target comparison role set; determining whether there is a target role in the target comparison role set that matches the elements in the legal role sequence, and generating a matching status identifier based on the determination result.
[0078] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.
[0079] In actual enterprise-level microservice architecture deployments, the aforementioned request receiving module 302 is typically deployed in the system's API gateway layer or the global filter of the front controller. As a unified gateway for all inbound traffic, it is responsible for prioritizing the interception of requests during the inbound phase and parsing the user role information from the HTTP header or token. The configuration query module 303 and the permission verification module 304, based on Aspect-Oriented Programming (AOP) technology, can be encapsulated as a low-level global permission interceptor. When the business system's control layer receives a route assignment, this global permission interceptor will be executed first as pre-enhancement logic, calling the configuration data maintained in memory or Redis by the configuration retrieval module 301. This modular design allows business developers to focus solely on core business logic, effectively decoupling security verification logic from core business processing logic.
[0080] This embodiment also discloses an electronic device, as shown in the reference. Figure 4 The electronic device may include: at least one processor 401, at least one communication bus 402, user interface 403, network interface 404, and at least one memory 405.
[0081] The communication bus 402 is used to enable communication between these components.
[0082] The user interface 403 may include a display screen and a camera. Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.
[0083] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).
[0084] The processor 401 may include one or more processing cores. The processor 401 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 405, and by calling data stored in memory 405. Optionally, the processor 401 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 401 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 401.
[0085] The memory 405 may include random access memory (RAM) or read-only memory. Optionally, the memory 405 may include a non-transitory computer-readable storage medium. The memory 405 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 405 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 405 may also be at least one storage device located remotely from the aforementioned processor 401. Figure 4 As shown, the memory 405, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program based on a dual-configuration access control method.
[0086] exist Figure 4In the electronic device shown, the user interface 403 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 401 can be used to call an application stored in the memory 405 that is a dual-configuration access control method. When executed by one or more processors 401, the electronic device executes one or more methods as described in the above embodiments.
[0087] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0088] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0089] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.
[0090] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0091] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0092] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 405 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory 405 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.
[0093] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope of this application is defined by the claims.
Claims
1. A dual-configuration-based access control method, characterized in that, The method includes: Obtain first configuration information and second configuration information. The first configuration information is preset static code annotation data, and the second configuration information is preset dynamic database table data. The first configuration information and the second configuration information are independent of each other. Both the first configuration information and the second configuration information contain resource identifiers and corresponding authorized role lists. The second configuration information also contains an effective status identifier. The first configuration information is independently written to a preset first cache, and the second configuration information is independently written to a preset second cache, wherein the first cache and the second cache are isolated from each other; Receive an access request, the access request carrying the target resource identifier and user role information; In response to the access request, a retrieval is performed in the preset second cache based on the target resource identifier to query the second configuration information; If the second configuration information that matches the target resource identifier is found, and the effective status identifier indicates that it is enabled, then the matching second configuration information is determined as the target configuration information; If no matching second configuration information is found, or if an error occurs during the query of the second configuration information, or if the effective status identifier of the found second configuration information indicates a disabled state, a degradation processing mechanism is triggered. The first configuration information is then queried based on the target resource identifier. Specifically, the degradation processing mechanism includes: capturing timeout exception events or null value return events generated during the retrieval in the preset second cache, generating a degradation switching instruction based on the timeout exception event or the null value return event, and routing the retrieval to the preset first cache to extract the matching first configuration information based on the degradation switching instruction. If the first configuration information that matches the target resource identifier is found, the matching first configuration information is determined as the target configuration information; After determining the target configuration information, it is determined whether the user role information exists in the authorized role list corresponding to the target configuration information; If it exists, the access request is deemed to have passed the permission verification; If the first configuration information that does not exist, or does not match the target resource identifier, or if the query for the first configuration information is abnormal, then the access request is determined to have failed the permission verification.
2. The method according to claim 1, characterized in that, The preset static permission configuration data specifically refers to preset static code annotation data, and the dynamically updated permission configuration data specifically refers to preset dynamic database table data. After obtaining the first configuration information and the second configuration information, the method further includes: Extract the resource identifier contained in the first configuration information and the resource identifier contained in the second configuration information and perform a consistency comparison operation. If the comparison result indicates that the first configuration information and the second configuration information contain the same resource identifier, it is determined that there is a duplicate configuration and a configuration conflict prompt message is generated.
3. The method according to claim 2, characterized in that, After independently writing the second configuration information into a preset second cache, the method further includes: Establish a data node change monitoring task for the preset dynamic database table data; Receive incremental configuration change data returned by the data node change monitoring task; Based on the incremental configuration change data, a synchronous overwrite operation is performed on the second configuration information in the preset second cache.
4. The method according to claim 3, characterized in that, The step of querying the second configuration information based on the target resource identifier specifically includes: Parse the target resource identifier and extract the corresponding target page access identifier and target function node identifier; Perform a string concatenation operation on the target page access identifier and the target function node identifier to generate a target query key value; Based on the target query key value, a key-value matching operation is performed in the preset second cache to extract the matching second configuration information.
5. The method according to claim 1, characterized in that, The capture of timeout exception events generated during retrieval in the preset second cache specifically includes: If the time for a single query to the preset second cache exceeds a preset time threshold, a single timeout exception event is determined to occur. The frequency of the timeout exception events generated within a preset time window is counted; If the frequency exceeds the preset safety level, the preset fuse state will be switched from closed to open, and all subsequent second configuration information query requests will be intercepted in the open state. The downgrade switching instruction will be directly generated to short-circuit the route to the preset first cache for retrieval.
6. The method according to claim 1, characterized in that, The step of determining whether the user role information exists in the list of authorized roles corresponding to the target configuration information specifically includes: Parse the target configuration information and extract the legal role sequence corresponding to the authorized role list from the target configuration information; Extract the role code to be verified from the user role information; Traverse the sequence of legal roles, perform consistency matching comparison between the role code to be verified and the elements in the sequence of legal roles, and generate a matching status identifier based on the comparison result.
7. The method according to claim 6, characterized in that, The step of performing a consistency matching comparison between the role code to be verified and the elements in the legal role sequence, and generating a matching status identifier based on the comparison result, specifically includes: Perform a parsing operation on the character code to be verified, and extract the parent character attributes bound to the character code to be verified; The character code to be verified and the parent character attribute are combined to generate a target comparison character set; Determine whether there exists a target role in the target comparison role set that matches the element in the legal role sequence, and generate the matching status identifier based on the determination result.
8. A dual-configuration-based access control system, characterized in that, The system includes: A configuration acquisition module is used to acquire first configuration information and second configuration information. The first configuration information is preset static code annotation data, and the second configuration information is preset dynamic database table data. The first configuration information and the second configuration information are independent of each other. Both the first configuration information and the second configuration information contain resource identifiers and corresponding authorized role lists. The second configuration information also contains an effective status identifier. The module independently writes the first configuration information into a preset first cache and independently writes the second configuration information into a preset second cache, wherein the first cache and the second cache are isolated from each other. A request receiving module is used to receive access requests, the access requests carrying target resource identifiers and user role information; A configuration query module is configured to respond to the access request by performing a retrieval in a preset second cache based on the target resource identifier to query the second configuration information. If the second configuration information matching the target resource identifier is found and the effective status identifier indicates an enabled state, the matched second configuration information is determined as the target configuration information. If the second configuration information matching the target resource identifier is not found, or an error occurs during the query of the second configuration information, or the effective status identifier of the found second configuration information indicates a disabled state, a degradation processing mechanism is triggered to query the first configuration information based on the target resource identifier. Specifically, the degradation processing mechanism includes: capturing timeout exception events or null value return events generated during the retrieval in the preset second cache, generating a degradation switching instruction based on the timeout exception event or the null value return event, and routing the retrieval to the preset first cache to extract the matching first configuration information according to the degradation switching instruction. If the first configuration information matching the target resource identifier is found, the matched first configuration information is determined as the target configuration information. The permission verification module is used to determine whether the user role information exists in the authorized role list corresponding to the target configuration information after determining the target configuration information; if it exists, the access request is determined to pass the permission verification; if it does not exist, or the first configuration information matching the target resource identifier is not found, or the query of the first configuration information is abnormal, the access request is determined to fail the permission verification.
9. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.