Access control method and system based on double system architecture decoupling of guard logic

Abstract

The application provides a kind of dual-system architecture access control method based on guard logic decoupling, method includes: based on the value boundary of the return value of middleware that three kinds of navigation intent of transparent transmission, terminal state and redirection are constructed, and the value of intermediate node is checked using function signature, three-state middleware communication protocol is obtained;With three-state middleware communication protocol as the running rule of pipeline, build responsibility chain execution engine;Based on user access route path, session hydration and authentication activation condition, three middleware nodes that meet function signature are sequentially constructed;Three middleware nodes are sequentially transmitted into responsibility chain execution engine, and the guard pipeline of logical decoupling is obtained by registration;When responding to user navigation request, the guard pipeline takes authentication activation condition as the basis for judgment, takes single sign-on authorization jump and degradation fallback as unified exit, and obtains authentication decision result.The application realizes the decoupling of guard logic and business route and unified access control under dual-system architecture.

Description

Technical Field

[0001] This application relates to the fields of front-end engineering and cloud platform web application technology, specifically to a dual-system architecture access control method and system based on guard logic decoupling. Background Technology

[0002] Currently, single-page application frameworks (such as Vue Router) typically provide only a single global pre-hook for their route guard mechanisms. Developers must cram all interception logic—including login state detection, user session recovery, single sign-on redirection, redirect deduplication, and differentiated access control for multiple subsystems—into a single callback function. As business complexity increases, the number of lines of code in this callback function grows dramatically. The execution order and termination conditions between logic blocks are deeply coupled in nested conditional branching structures, blurring the boundaries of responsibility. When new rules need to be added, developers must read through the entire guard function to locate the modification point, which easily introduces regression defects, resulting in severely compromised system maintainability and scalability.

[0003] Furthermore, in hybrid front-end systems that simultaneously target public and enterprise management users, user states typically span multiple levels, including guest, logged-in but unauthenticated, and logged-in and authenticated. The system also requires deep integration with third-party single sign-on services. Existing route guard solutions struggle to handle path-level mandatory authentication for the management console subsystem, declarative access control for the portal page, and cross-system silent login state synchronization when external systems are embedded within the same model. Rules for different authentication scenarios are scattered across different branches of the guard function, lacking a unified decision-making mechanism, making it difficult for the authentication logic to adapt to the complex access control requirements of multiple subsystems and authentication levels.

[0004] Therefore, there is an urgent need for an access control method that can decouple the guard logic into independently maintainable units and uniformly handle multiple authentication scenarios. Summary of the Invention

[0005] This application addresses the shortcomings of existing technologies by providing a dual-system architecture access control method and system based on guard logic decoupling.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] A dual-system architecture access control method based on guard logic decoupling, wherein the dual-system architecture includes a management console subsystem and a portal subsystem, comprising the following steps: The middleware return value boundary is constructed based on three navigation intentions: pass-through, final state, and redirection. The value of the middle node is verified by function signature, and the three-state middleware communication protocol is obtained. A responsibility chain execution engine is constructed based on the operating rules of the aforementioned three-state middleware communication protocol as the pipeline; Based on the user access routing path, session hydration status, and authentication activation conditions, three middleware nodes conforming to the function signature are constructed sequentially; wherein, the authentication activation conditions include: the current navigation is the management console subsystem and / or the current navigation is a protected page in the portal subsystem and / or the current navigation is a cross-system login intent; The three middleware nodes are sequentially passed to the chain of responsibility execution engine to register and obtain a logically decoupled guard pipeline; When responding to a user's navigation request, the guard pipeline uses the authentication activation conditions as the basis for judgment, and uses single sign-on authorization redirection and downgrade fallback as the unified exit point to obtain the authentication decision result.

[0008] As one possible implementation, the transparent navigation intent is encoded as a default value, indicating that the current intermediate node does not make navigation decisions and transfers control to the next intermediate node; The final navigation intent is encoded as a Boolean value, indicating that the current intermediate node has made a final decision. The execution engine immediately terminates the pipeline and reports the Boolean value to the routing framework. A true Boolean value indicates permission to proceed, while a false Boolean value indicates cancellation. The redirection navigation intent is encoded as a route descriptor object, indicating that the current intermediate node decides to forward this navigation to another target route. The execution engine immediately terminates the pipeline and reports the route descriptor to the routing framework to initiate a new navigation.

[0009] As one possible implementation, the operation rules that use the three-state middleware communication protocol as a pipeline to construct the chain of responsibility execution engine include the following steps: Execute the middleware nodes in the chain of responsibility pipeline one by one to obtain the navigation intent returned after each execution; If any of the returned navigation intents is a final state or a redirection, the execution engine immediately stops and reports the returned navigation intent to the framework as the final decision for this navigation. If all returned navigation intents from all nodes are transparent, the execution engine will make a pass decision.

[0010] As one possible implementation, the step of sequentially constructing three middleware nodes conforming to the function signature based on the user access routing path, session hydration status, and authentication activation conditions includes the following steps: Based on the user's access route, the first node is constructed. Specifically, if the user is detected to be logged in and the user attempts to enter the login page or the landing page after single sign-on, the node returns a redirect navigation intent; if the user accesses the single sign-on callback address, the node returns a true final navigation intent; otherwise, the node returns a pass-through navigation intent. Based on the session hydration status, a second node is constructed. Specifically, if the current session has been hydrated, the node returns a transparent navigation intent; if the user has logged in but the current session has not been hydrated, the node requests user information from the server. If the user information is successfully obtained, the node returns a transparent navigation intent; if the user information is not obtained, the node returns a false final state navigation intent. Based on the authentication activation conditions, a final node is constructed. Specifically: if authentication is not required, or if authentication is required but the user is already logged in, the node returns a transparent navigation intent; if authentication is required but the user is not logged in, it attempts to redirect to the single sign-on page. If the redirection is successful, the node returns a true final navigation intent; if the redirection fails, the node returns a redirect navigation intent; otherwise, the node returns a transparent navigation intent.

[0011] As one possible implementation, the authentication activation conditions include determining whether the current navigation is a management console subsystem based on the path string of the target route, including the following steps: The node retrieves the path string of the target route; If the prefix of the path string of the target route is consistent with the root path of the management console subsystem, the node determines that strong authentication is required for this navigation; otherwise, it continues to determine whether the current navigation belongs to the portal subsystem.

[0012] As one possible implementation, the authentication activation conditions include determining whether the current navigation is a protected page in the portal subsystem based on the metadata declaration field of the target route, including the following steps: The node reads the metadata declaration field from the target route configuration; If the value of the metadata declaration field is true, the node determines that this navigation is a protected page request in the portal subsystem and requires declarative authentication.

[0013] As one possible implementation, the authentication activation condition includes determining whether the current navigation is a cross-system login intent based on the cross-system login intent flag of the target route, including the following steps: The node retrieves the cross-system login intent flag from the query parameters of the target route; If the cross-system login intent flag is true, then this navigation is determined to be a cross-system login intent, which requires cross-system authentication.

[0014] As one possible implementation, the step of sequentially passing the three middleware nodes to the chain of responsibility execution engine and registering them to obtain the guard pipeline includes the following steps: Based on the business dependency order, the three middleware nodes are placed into an array in sequence to obtain an ordered middleware array; The ordered middleware array is passed as a parameter to the factory function of the chain of responsibility execution engine to construct the asynchronous pipeline function; The asynchronous pipeline function is registered as a callback parameter to the global pre-guard hook of the routing framework to take over route navigation, thus obtaining the guard pipeline.

[0015] A dual-system architecture access control system based on guard logic decoupling, used to implement the method described in any one of the above, wherein the dual-system architecture includes a management console subsystem and a portal subsystem, and the system includes: The communication protocol module is used to construct the value boundaries of the middleware return value based on three navigation intentions: transparent transmission, final state, and redirection, and to use function signatures to verify the values ​​of the middle nodes to obtain the three-state middleware communication protocol. The execution engine module is used to construct a chain-of-responsibility execution engine based on the operating rules of the three-state middleware communication protocol as a pipeline. The three-node construction module is used to sequentially construct three middleware nodes that conform to the function signature based on the user access routing path, session hydration status, and authentication activation conditions; wherein, the authentication activation conditions include: the current navigation is the management console subsystem and / or the current navigation is a protected page in the portal subsystem and / or the current navigation is a cross-system login intent; The guard pipeline registration module is used to sequentially pass the three middleware nodes to the chain of responsibility execution engine and register them to obtain logically decoupled guard pipelines. The decision result module is used to obtain the authentication decision result by using the authentication activation condition as the judgment basis and single sign-on authorization jump and downgrade fallback as the unified exit when responding to user navigation requests.

[0016] An apparatus includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the method described in any one of the preceding methods.

[0017] This application, by adopting the above technical solution, has significant technical effects: (1) Decoupling of guard logic and business routing is achieved. This application uses authentication activation conditions as dynamic judgment criteria, eliminating the need for hard-coding specific routing paths or subsystem identifiers at the code level in the guard pipeline. The guard pipeline runs as an independent general component, only dynamically intervening in specific navigation requests at runtime based on activation conditions. This means that when the routing structure of the two systems is adjusted or restructured, there is no need to modify the core code of the guard pipeline, greatly reducing the coupling between guard logic and business routing, and solving the maintenance difficulties caused by the strong binding of guard logic and business code in traditional architectures. It also shields the authentication differences of heterogeneous systems, achieving logical decoupling at the control level.

[0018] (2) Unified access control under the dual system architecture has been implemented.

[0019] This application uses path topology domains to enforce protection for all routes in the management console subsystem, uses route metadata declarations to flexibly control protected pages in the portal subsystem, and uses cross-system parameters to identify and handle external embedded call scenarios. The application combines these three dimensions of judgment conditions logically or in parallel into a unified authentication activation condition, enabling a single guard pipeline to simultaneously respond to different authentication requests from both subsystems. Regardless of whether a user attempts to access resources in the console, protected pages in the portal, or access via external system embedding, authentication is performed using the same set of decision logic, with a unified single sign-on authorization redirect as the exit point. This avoids the rule dispersion and inconsistency issues caused by maintaining independent guard logic for different subsystems, eliminates authentication blind spots caused by the separation of subsystem boundaries, and ensures unified and consistent access control policies across all scenarios for both systems. From an architectural perspective, this guarantees the integrity and consistency of the overall security policy for both systems. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating an embodiment of the method of this application; Figure 2 This is an overall schematic diagram of an embodiment of the system in this application. Detailed Implementation

[0022] The present application will be further described in detail below with reference to the embodiments. The following embodiments are explanations of the present application, but the present application is not limited to the following embodiments. Unless otherwise specified, the features in the following embodiments can be combined with each other.

[0023] Example 1: In one embodiment, an access control method for a dual-system architecture based on decoupling of guard logic is provided, wherein the dual-system architecture includes a management console subsystem and a portal subsystem, such as... Figure 1 As shown, it includes the following steps: S100: Based on three navigation intentions—transparent transmission, final state, and redirection—the middleware return value boundary is constructed, and the middleware value is verified using function signatures to obtain the three-state middleware communication protocol. S200: Construct a chain-of-responsibility execution engine based on the operating rules of the aforementioned three-state middleware communication protocol as the pipeline; S300: Based on the user access routing path, session hydration status, and authentication activation conditions, three middleware nodes conforming to the function signature are constructed sequentially; wherein, the authentication activation conditions include: the current navigation is the management console subsystem and / or the current navigation is a protected page in the portal subsystem and / or the current navigation is a cross-system login intent; S400: Pass the three middleware nodes into the chain of responsibility execution engine in sequence to register a logically decoupled guard pipeline; S500: When responding to a user navigation request, the guard pipe uses the authentication activation condition as the basis for judgment, and uses single sign-on authorization jump and downgrade fallback as the unified exit to obtain the authentication decision result.

[0024] In a multi-middleware chain of responsibility architecture, after each node completes its own business logic, it needs to convey a clear instruction to the execution engine: how to handle this navigation next. This instruction is the navigation intent.

[0025] Navigation intent is the communication unit between nodes and the execution engine. Based on the navigation intent returned by each node, the execution engine decides whether to continue passing control forward or immediately terminate the pipeline and report the processing result to the routing framework. In existing technologies, each interception unit relies on runtime means such as Boolean flags, global variables, or exception throwing to transmit intent, which lacks a unified semantic expression and static verifiability.

[0026] In another embodiment, this application abstracts navigation intents into a closed algebraic structure that can be enforced by a type system, converges navigation intents into three and only three semantic categories, and encodes them respectively using TypeScript native type values: (1) Pass through navigation intent. Pass through navigation intent is encoded as a default value, which means that the current intermediate node does not make navigation decisions and transfers control to the next intermediate node.

[0027] This node makes no decisions for this navigation; control is fully transferred to the next node in the chain of responsibility for further processing. The transparent navigation intent is encoded as a default value (undefined). The semantics of undefined have been explicitly redefined and no longer represent the vague absence of "no return value," but rather an explicit transparent declaration with definite business meaning. This redefinition is the semantic prerequisite for the subsequent short-circuit evaluation mechanism of the execution engine to hold true.

[0028] (2) Final state navigation intent. The final state navigation intent is encoded as a Boolean value, indicating that the current intermediate node has made a final decision, the execution engine immediately terminates the pipeline and reports the Boolean value to the routing framework; wherein, the Boolean value is true when it means to allow passage and false when it means to cancel.

[0029] The intention to terminate navigation is encoded as a boolean value. A true value indicates permission to proceed, while a false value indicates cancellation. Whether permission is granted or cancelled, it is a final decision that requires no further intervention from subsequent nodes. The execution engine should immediately terminate the pipeline and report this decision to the framework.

[0030] (3) Redirect navigation intent. The redirect navigation intent is encoded as a route descriptor object, indicating that the current intermediate node decides to forward this navigation to another target route. The execution engine immediately terminates the pipeline and reports the route descriptor to the routing framework to initiate a new navigation.

[0031] This node decides to forward this navigation to another target route, carrying the target route descriptor. The execution engine should immediately terminate the pipeline and report the redirection target to the framework to initiate new navigation. The redirection navigation intent is encoded as the framework's native route descriptor object, RouteLocationRaw.

[0032] In another embodiment, in S100, the value boundaries of the middleware return value are constructed based on three navigation intentions: transparent transmission, final state, and redirection. The middleware value is verified using function signatures to obtain the three-state middleware communication protocol, including the following steps: S110: Construct the value boundaries of the middleware return value based on three navigation intents: pass-through, final state, and redirection.

[0033] By mapping the three navigation intents to an exhaustively enclosed union type MiddlewareResult and completing the formal encoding, MiddlewareResult can be one of undefined, boolean, or RouteLocationRaw. The three values ​​are combined into an exhaustively enclosed union type MiddlewareResult, which serves as the legal value boundary for all middleware return values.

[0034] S120: Verify the values ​​of the middleware using function signatures to obtain the three-state middleware communication protocol.

[0035] By solidifying the middleware contract with function signatures, the compliance constraints of the three navigation intents are moved forward to the compile time. Based on the MiddlewareResult union type, this application defines the RouteMiddleware function signature, which simultaneously solidifies the input parameter forms and output value ranges of all middleware implementations at the type level.

[0036] The TypeScript compiler performs static compliance checks on all middleware implementations during the build phase. Any return value that does not belong to one of the three valid navigation intents will result in an error during the build phase, moving navigation behavior exceptions that would normally be exposed at runtime to the compile-time stage for elimination. The core code is as follows: export type RouteMiddleware = ( to: RouteLocationNormalized, from: RouteLocationNormalized, ) =>MiddlewareResult | Promise <middlewareresult> The existence of a protocol only describes what the rules look like; it cannot be executed automatically. An execution engine is still needed to call the nodes one by one according to the protocol rules and decide whether to continue or terminate based on the return value of the node, namely MiddlewareResult.

[0037] In another embodiment, in S200, the construction of the chain-of-responsibility execution engine based on the operating rules of the three-state middleware communication protocol includes the following steps: S210: Execute the middleware nodes in the chain of responsibility pipeline one by one to obtain the navigation intent returned after each execution.

[0038] This application employs the higher-order factory function `createMiddlewarePipeline()` to translate the semantics of the `MiddlewareResult` protocol into pipeline execution rules. The `createMiddlewarePipeline()` function is an ordered array of nodes that conform to its function signature, with a return type of `RouteMiddleware`. Therefore, the entire pipeline itself also satisfies the same signature and can be directly attached to the global hooks of the routing framework. Each node in the `createMiddlewarePipeline()` array is executed sequentially, and its return value is read after each execution, representing the navigation intent returned after each execution.

[0039] S220: If any of the returned navigation intents is a final state or a redirection, the execution engine immediately stops and reports the returned navigation intent to the framework as the final decision for this navigation; if all the returned navigation intents of all nodes are transparent, the execution engine executes a release decision.

[0040] The core logic of the engine is a direct implementation of the MiddlewareResult protocol: if the return value is not equal to undefined, meaning the node has issued a termination navigation intent or a redirection navigation intent, the engine immediately stops and reports the return value to the framework as the final decision for this navigation. If all nodes return undefined, meaning all are passed through, the engine makes a fallback decision to allow navigation. Therefore, the prerequisite for the engine to work correctly is the semantic convention of redefining undefined to an explicit pass-through declaration. The core code is as follows: export function createMiddlewarePipeline(middlewares: RouteMiddleware[]): RouteMiddleware { return async (to, from) =>{ for (const middleware of middlewares) { const result = await middleware(to, from) / / result type is MiddlewareResult If (result !== undefined) return result / / If not undefined → terminate the pipeline and report the decision. } return true / / Pass all data through → Allow access } } The actual business logic needs to be broken down into several middleware nodes. The function form of each node strictly conforms to the RouteMiddleware signature, and the return value strictly belongs to one of the three possible values ​​of MiddlewareResult. In another embodiment, in S300, three middleware nodes conforming to the stated function signature are constructed sequentially based on the user access routing path, session hydration status, and authentication activation conditions, including the following steps: S310: Based on the user access routing path, construct the first node loginRedirectMiddleware.

[0041] The first node is responsible for pre-filtering, primarily handling redirection logic related to the login page and single sign-on callback page. This node executes before all authentication checks, prioritizing the determination of whether the user should remain on the login page. The function signature of the first node strictly adheres to the RouteMiddleware type defined in the first step, and its return value corresponds to different values ​​of MiddlewareResult depending on the scenario, specifically: (1) If the user is detected to be logged in and the user attempts to enter the login page or the landing page after single sign-on, the node returns a redirect navigation intent.

[0042] When a node detects that a user is already logged in but attempts to navigate to the login page or the landing page after a single sign-on callback, the node determines that such access is meaningless. Therefore, the node returns a redirect navigation intent, which the engine receives and immediately terminates the pipeline, automatically guiding the user to the system homepage. This avoids the unpleasant experience of logged-in users seeing the login page again. If the user is not logged in, the node returns true, allowing access to the SSO login page.

[0043] (2) If the user accesses the callback address of single sign-on, the node returns a true value for the final navigation intent.

[0044] When a user accesses the single sign-on callback address, this address is an internal part of the login process and must be allowed unconditionally. Therefore, upon receiving this, the engine immediately terminates the pipeline and allows the final navigation intent returned by the node to proceed, directly allowing the navigation without any further interception or redirection.

[0045] (3) In other cases, the node returns a transparent navigation intent.

[0046] For all other navigation elements that are neither the login page nor the single sign-on callback page, the node determines that they are irrelevant to its own responsibilities. Therefore, the node returns undefined, which means that the navigation intent is passed through. The engine continues to execute, completely transferring control to the next node in the pipeline to continue processing, without intervening in any way itself.

[0047] The construction of the first-line node embodies the Single Responsibility Principle: it only concerns itself with the redirection logic of login-related pages and does not handle user permissions, user information, or other issues. Through the clear distinction between the three scenarios, this node can intervene when appropriate and quickly yield when not needed. The core code for constructing the first-line node is as follows: export const loginRedirectMiddleware: RouteMiddleware = (to) =>{ const userStore = useUserStore() if (to.path === ' / loginSso') { return userStore.isLoggedIn ? { path: ' / '} : true / / RouteLocationRaw or boolean (final state) } if (isLoginPage(to.path)&&userStore.isLoggedIn) { return { path: ' / '} / / RouteLocationRaw (redirect navigation intent) } return undefined / / undefined (passes through navigation intent) } S320: Based on the session hydration status, construct the second node userInfoMiddleware.

[0048] When a user refreshes the page, the locally stored login credentials (token) remain valid, but the user information (username, permissions, etc.) in memory has been cleared. If this information is not restored before authentication, subsequent permission checks will be performed based on empty data, potentially leading to misjudgments.

[0049] The second node also follows the RouteMiddleware signature and is responsible for ensuring the integrity and reliability of the user state in memory before executing authentication decisions. To this end, the second node uses a module-level flag, `isUserInfoFetched`, to control the timing of the hydration operation. Leveraging the characteristic that ES module files are initialized only once when the application is first loaded, this flag is automatically reset to zero upon page refresh (re-triggering fetching) and remains hydrated during multiple route jumps within the session (avoiding duplicate requests). Hydration refers to converting user login credentials stored in persistent storage into complete user information in memory, such as username and permission list.

[0050] Based on the session hydration status, a second node is constructed, specifically as follows: (1) If the current session has been hydrated, the node returns the transparent navigation intent.

[0051] If the user is not logged in, or the user is logged in but the module-level flag is already true (indicating that hydration has been completed in this session), the node determines that no user information retrieval operation is needed at this time, skips all processing logic, and the node returns an undefined value, that is, passes through the navigation intent and transfers control to the next node.

[0052] (2) If the user has logged in but the current session has not been hydrated, request user information from the server. If the user information is successfully obtained, the node returns a transparent navigation intent; if the user information is not obtained, the node returns a false final state navigation intent.

[0053] If a user is logged in but the module-level flag is false (indicating the session has not yet been hydrated), the node initiates an asynchronous request to retrieve complete user information from the server. Upon successful retrieval, this information is stored in the user state store in memory. Subsequently, the module-level flag is set to true, marking hydration as complete, and the node returns a transparent navigation intent (undefined). Although the node performs the actual asynchronous request, from a navigation decision perspective, it does not make a final decision on whether to allow, cancel, or redirect the navigation. The hydration operation merely prepares necessary context information for subsequent authentication; therefore, a transparent navigation intent is still returned, transferring control to the next node.

[0054] If a node attempts to retrieve user information, but the server returns an unauthorized status code (usually 401), it indicates that the login credentials in local storage have expired or been revoked. Upon receiving the credential expiration response, the node determines that the current user's login state is invalid and should not be allowed to access any pages requiring login. The node does not perform any redirection operations, as the redirection logic is handled uniformly by other nodes; it only makes the decision to "cancel this navigation," i.e., a final navigation intent returning false. This indicates that this node has made the final cancellation decision, and no further intervention from subsequent nodes is required. Upon receiving false, the execution engine immediately terminates the entire chain of responsibility pipeline and reports the cancellation decision to the routing framework. This navigation is blocked, and the user remains on the current page.

[0055] The second node is not responsible for determining whether a user has permission to access the target page; it only ensures that the user information in memory is complete and reliable before the authentication node executes. This node achieves performance optimization by using module-level flags to ensure only one request per session, and also guarantees proper blocking when credentials expire through exception handling. The core code is as follows: let isUserInfoFetched = false export const userInfoMiddleware: RouteMiddleware = async () =>{ const userStore = useUserStore() if (userStore.isLoggedIn&&!isUserInfoFetched) { try { await userStore.fetchUserInfo() isUserInfoFetched = true } catch { if (!userStore.isLoggedIn) return false / / boolean (final cancellation intention) } } return undefined / / undefined (passes through navigation intent) } S330: Construct the final node authMiddleware based on authentication activation conditions.

[0056] The final node, authMiddleware, also follows the RouteMiddleware signature and serves as the implementation carrier for the three-dimensional authentication activation conditions. To cover the full-scenario access control requirements under a dual-system architecture, this application designs three independent and non-interfering judgment dimensions, which are combined using a logical OR method to form a unified authentication activation condition, specifically including: Dimension 1: Determine whether the current navigation is the management console subsystem based on the path string of the target route.

[0057] (1) The node obtains the path string of the target route.

[0058] The last node authMiddleware first extracts the path string of the target route from the routing framework. The path string of the target route is directly passed in by the routing framework when executing the global pre-guard.

[0059] (2) If the prefix of the path string of the target route is consistent with the root path of the management console subsystem, the node determines that strong authentication is required for this navigation; otherwise, it continues to determine whether the current navigation belongs to the portal subsystem.

[0060] After extracting the path string "path" from the target route, it checks if it begins with a specific prefix. This prefix corresponds to the root path of the management console subsystem; for example, the prefix " / console" might be used as a boundary condition for the console subsystem's topology domain. Once authMiddleware detects that the target path belongs to this prefix domain, regardless of whether the routing configuration layer attaches any access control metadata, it determines that this navigation is a request to the management console subsystem and classifies it as a strong authentication request. If no match is found, this navigation may be a request to the portal subsystem, and the process proceeds to the next dimension of judgment.

[0061] The console subsystem is an enterprise-level management tool, and all its pages should be protected by login; no public pages should exist. The traditional approach is to manually add authentication markers to each route configuration, but this method is prone to security vulnerabilities due to omissions. Dimension One elevates the authentication semantics of the console subsystem from per-route distributed declarations to system-level architectural constraints. System-level mandatory authentication is performed through path prefixes. The console subsystem is forcibly protected by architectural rules, eliminating the risk of unauthorized access due to missed markers and eradicating unauthorized access vulnerabilities caused by missing route metadata at the root.

[0062] Dimension 2: Determine whether the current navigation is a protected page in the portal subsystem based on the metadata declaration fields of the target route.

[0063] (1) The node reads the metadata declaration field in the target route configuration.

[0064] The portal subsystem includes both public e-commerce pages (such as product browsing and event display) and private user pages (such as personal center and order management). For navigation requests that do not match the console path prefix, which belong to the portal subsystem, authMiddleware further reads the metadata declaration field of the target route's meta.requiresAuth. This metadata declaration field originates from the static configuration pre-declared by the developer in the route table during the route configuration phase. For example, when using routing frameworks like VueRouter, each route record can contain a meta field, where developers can define custom key-value pairs (e.g., { requiresAuth: true}). When the final node executes, it reads this meta field from the current navigation target route object and extracts the specific value of requiresAuth to determine whether the page requires login to access.

[0065] (2) If the value of the metadata declaration field is true, the node determines that the current navigation is a protected page request in the portal subsystem and requires declarative authentication.

[0066] When the `meta.requiresAuth` field is declared as `true`, authentication is required. `authMiddleware` classifies this navigation as a protected page request within the portal subsystem. Public pages should allow direct access by guests, while private pages require login. By declaring route metadata, developers can specify the access policy for each page at the route configuration level. The business rendering component itself does not need to concern itself with the authentication logic, achieving separation of concerns.

[0067] The conditional sub-item corresponding to dimension two is as follows: to.meta.requiresAuth === true Dimension 3: Determine whether the current navigation is a cross-system login intent based on the cross-system login intent flag of the target route.

[0068] (1) The node obtains the cross-system login intent flag in the query parameters of the target route.

[0069] In actual business scenarios, external systems may have already completed user authentication. When a user is redirected from an external system to this system, requiring them to re-enter their username and password would result in a poor user experience. Therefore, a pre-defined URL parameter is used to convey the intention to be logged in. The system checks whether the query parameters of the target navigation address contain a specific flag, which is actively added by the external system (such as the operations backend or a third-party platform) when redirecting to this system.

[0070] (2) If the cross-system login intent flag is true, then the navigation is determined to be a cross-system login intent and cross-system authentication is required.

[0071] authMiddleware checks the query parameter state of the current navigation target URL. When it detects that state=true, the node parses it as a cross-system login intent signal passed by the upper-level caller. Even if the target path itself is not a console path and does not declare protected attributes, this signal is sufficient to trigger the authentication process.

[0072] Dimension 3 achieves declarative propagation of login state across systems using a single agreed-upon parameter. No server-side interface modifications are required; the declarative propagation of login state across systems can be completed solely through front-end parameter conventions. This directly triggers the silent authorization process of single sign-on without user intervention. This design requires no server-side interface modifications. The corresponding conditional item for Dimension 3 is as follows: to.query.state === 'true'.

[0073] If the current navigation is to the management console subsystem, or if the current navigation is to a protected page in the portal subsystem, or if the current navigation is a cross-system login intent, authentication is required to unify the authentication control of the two systems. Meeting any one of these three dimensions constitutes an authentication activation condition. When this condition is met and the node detects that the user is currently not logged in, the node calls the single sign-on authorization redirection function, guiding the user to a unified authentication center to complete the login process.

[0074] The final node is the last middleware node to be executed and serves as the implementation vehicle for the three-dimensional authentication activation conditions. The execution of the final node depends on the work already completed by the first two nodes: the first node has handled the redirection logic for the login page and the single sign-on callback page, ensuring that the current navigation no longer stays on the login page; the second node has completed the hydration of user information, meaning that if the user is already logged in, the user information in memory has been fully restored; if hydration fails and the credentials expire, the pipeline has been terminated prematurely.

[0075] When the last-mile node executes, the system operates within a context where user status is clear and user information is complete. The sole task of the last-mile node is to handle authentication decisions: based on the characteristics of the target route, it determines whether the current user has permission to access the site; if not, it triggers a unified single sign-on authorization process. In S330, the last-mile node is constructed based on authentication activation conditions, specifically as follows: (1) If authentication is not required, or if authentication is required but the user is already logged in, the node returns a pass-through navigation intent.

[0076] If no authentication is required (meaning none of the three conditions are met), it indicates that the page the user wants to access is a public page that does not require permissions, and therefore no authentication is needed for this access. If the user wants to access a protected private page, authentication is required. However, if the user is already logged in, and since the user has proven their identity and the target page requires authentication, then the user's access request is completely legitimate.

[0077] By returning undefined to pass through the navigation intent, the last node ensures both the security of the protected page and the smooth access of legitimate users and public pages, avoiding page blanking or infinite loops caused by excessive interception.

[0078] (2) If authentication is required but the user is not logged in, try to redirect to the single sign-on page. If the redirection is successful, the node returns a true final navigation intent. If the redirection fails, the node returns a redirection navigation intent.

[0079] When the authentication activation condition is true, that is, when authentication is required, the last node needs to further check the current user's login status. Since the preceding hydration nodes have already ensured the reliability of the user information status, the last node can directly read the user login flag in memory.

[0080] If the user is not logged in, the final node triggers a unified single sign-on authorization redirection process, including: First, saving the original navigation intent. Before redirecting to the single sign-on authorization center, the node completely saves the target path (including the path and query parameters) that the current user wants to access to the session storage medium. This way, when the user logs in, the system can accurately take the user back to the page they originally wanted to access, rather than simply the homepage. Second, obtaining the authorization address and redirecting. The node calls the backend interface to obtain the redirection address of the single sign-on authorization center, and then redirects the browser window to that address. If the redirection is successful, the user will complete identity authentication in the authorization center. Finally, fallback processing. If the call to the authorization address interface fails, i.e., the redirection fails, the final node will not leave the page blank or canceled, but will execute a fallback strategy: displaying an error message to the user and redirecting the navigation to the portal homepage as a fallback exit, ensuring that the user can at least access the public parts of the system.

[0081] (3) In other cases, the node returns the transparent navigation intent.

[0082] Since this is the final node, there are no subsequent nodes in the pipeline. The execution engine reports the decision to allow the user to enter the target page normally.

[0083] authMiddleware combines the above three dimensions of judgment items into a unified authentication activation condition, needAuth, using logical OR and parallel combinations. A match in any dimension activates the subsequent SSO authorization redirection decision. The core code for merging the three-dimensional parallel processing and the final decision exit is as follows: export const authMiddleware: RouteMiddleware = async (to) =>{ const userStore = useUserStore() const hasThirdPartyFlag = to.query.state === 'true' const needAuth = to.path.startsWith(' / console') || to.meta.requiresAuth === true ||hasThirdPartyFlag if (needAuth&&!userStore.isLoggedIn) { const success = await redirectToSso(to.fullPath) if (!success) return { path: ' / '} return false } return undefined } The final node does not care which dimension triggered the authentication requirement, nor does it care how the user reached the authentication state. Instead, it unifies all different authentication scenarios into the standard decision of "whether to trigger single sign-on" and uses unified authorization redirection and fallback as the exit point to achieve unified processing of access control for all scenarios under the dual system architecture.

[0084] All three nodes have been implemented and conform to the RouteMiddleware signature. The return values ​​are all valid values ​​of MiddlewareResult, which satisfies all the prerequisites for RouteMiddleware[] to be passed to the execution engine.

[0085] In another embodiment, in S400, the step of sequentially passing the three middleware nodes to the chain of responsibility execution engine and registering the guarded pipeline includes the following steps: S410: Based on the business dependency order, the three middleware nodes are placed into an array in sequence to obtain an ordered middleware array.

[0086] The first node, the second node, and the last node are placed into an array in sequence. The order of the array directly determines the execution order of the chain of responsibility pipeline.

[0087] S420: Pass the ordered middleware array as a parameter to the factory function of the chain of responsibility execution engine to construct the asynchronous pipeline function.

[0088] After passing the ordered array above as a parameter to the factory function createMiddlewarePipeline of the execution engine, the factory function returns a function representing the entire pipeline. This pipeline function itself also conforms to the function signature of middleware, so it can be used like a single middleware.

[0089] Inside the pipeline function, the execution engine encapsulates the logic for sequentially traversing and executing each node. When the pipeline function is called, it sequentially calls the first node, the second node, and the last node in the array. After each call, it checks if the return value is a pass-through navigation intent. If it is, it continues to the next node; otherwise, it immediately stops executing all subsequent nodes and returns the value as the output of the entire pipeline. If all nodes return a pass-through navigation intent, the execution engine returns a default allow decision as the final output of the entire pipeline.

[0090] The execution engine can correctly handle the asynchronous results returned by each node, and only performs return value judgment after the asynchronous operation is completed. This ensures that the node can contain asynchronous operations, such as requesting user information interfaces.

[0091] S430: The asynchronous pipeline function is registered as a callback parameter to the global pre-guard hook of the routing framework to take over the route navigation, thus obtaining the guard pipeline.

[0092] Obtain the global before guard hook of the routing framework, such as `beforeEach` in Vue Router, and register the generated pipeline function as the callback function of that hook. After registration, whenever a user triggers any route navigation, the routing framework will automatically call the pipeline function, passing the target route and the source route as parameters.

[0093] The pipeline returned by the execution engine is essentially a route guard function that conforms to the routing framework's requirements. This function can be directly registered to the routing framework's global pre-guard hooks. After registration, when a user triggers any route jump in the application, the routing framework automatically calls the registered pipeline function, passing the target route and source route as parameters. The pipeline function executes three middleware nodes sequentially according to its internally encapsulated logic, ultimately returning a decision result to the routing framework. Based on this decision result, the routing framework decides whether to allow navigation, cancel navigation, or redirect to another address.

[0094] This way, once the preceding node returns a termination or redirection decision, subsequent nodes will not execute, avoiding unnecessary computational overhead. If new processing logic needs to be added, simply implement the new middleware node and insert it sequentially into the array; no modification to the execution engine or other node code is required. The core code is as follows: const pipeline = createMiddlewarePipeline([ loginRedirectMiddleware, / / RouteMiddleware: returns undefined / boolean / RouteLocationRaw userInfoMiddleware, / / RouteMiddleware: Returns undefined / false (when 401 error) authMiddleware, / / RouteMiddleware: 3D authentication, see step 3 for details. ]) router.beforeEach(async (to, from) =>{ return await pipeline(to, from) / / pipeline itself is also RouteMiddleware }) In another embodiment, in S500, when responding to a user navigation request, the guard pipe uses the authentication activation condition as the basis for judgment, and uses single sign-on authorization jump and downgrade fallback as a unified exit to obtain the authentication decision result in order to realize full-scenario access control under the dual-system architecture.

[0095] Thus, all authentication actions are not completed in a single, large function, but rather rely on a constructed chain-of-responsibility pipeline. This demonstrates that the authentication logic is modularized and pluggable, with the pipeline handling scheduling and the middleware handling the actual work. This architecture ensures the clarity and high maintainability of the authentication logic.

[0096] When a real user clicks a link or enters a URL in their browser, the user's click triggers the routing framework, which then invokes the previously mounted guard pipeline. The guard pipeline begins running, and when it reaches the final node, it evaluates the authentication activation conditions and outputs an authentication decision: if the decision indicates authentication is required but the user is not logged in, a redirect (such as single sign-on) is executed; if the decision indicates authentication is not required or the user is already logged in, the process is allowed, permitting the user to access the target page normally.

[0097] Regardless of whether a user is blocked from accessing the management console subsystem, the protected page of the portal subsystem, or due to cross-system parameter triggering, as long as the system determines that the user is not logged in, it will eventually redirect the user to the single sign-on authorization page. If the SSO redirection fails, the user will be downgraded to the portal homepage as a fallback, thereby greatly improving the stability of the system and the user experience.

[0098] Example 2: A dual-system architecture access control system based on guard logic decoupling, used to implement any of the above-described method embodiments, wherein the dual-system architecture includes a management console subsystem and a portal subsystem, such as... Figure 2 As shown, the system includes: The communication protocol module 100 is used to construct the value boundaries of the middleware return value based on three navigation intentions: transparent transmission, final state, and redirection, and to use function signatures to verify the value of the middle node to obtain the three-state middleware communication protocol. The execution engine module 200 is used to construct a chain-of-responsibility execution engine based on the operating rules of the three-state middleware communication protocol as a pipeline. The three-node construction module 300 is used to sequentially construct three middleware nodes that conform to the function signature based on the user access routing path, session hydration status, and authentication activation conditions. The authentication activation conditions include: if the current navigation is the management console subsystem, or if the current navigation is a protected page in the portal subsystem, or if the current navigation is a cross-system login intent, then authentication is required to uniformly control the authentication of the two systems. The guard pipeline registration module 400 is used to sequentially pass the three middleware nodes into the chain of responsibility execution engine to register a logically decoupled guard pipeline. The decision result module 500 is used to obtain the authentication decision result by using the authentication activation condition as the judgment basis and single sign-on authorization jump and downgrade fallback as the unified exit when responding to user navigation requests, so as to realize full-scenario access control under the dual system architecture.

[0099] Any changes and modifications made without departing from the spirit and scope of this application, and all equivalent technical solutions, also fall within the scope of this application.

[0100] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0101] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0102] This application is described with reference to flowchart illustrations and / or block diagrams of the method, terminal device (system), and computer program product according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0103] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0104] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0105] It should be noted that: The phrase "an embodiment" or "an embodiment" used in the specification means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of this application. Therefore, the phrase "an embodiment" or "an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0106] Furthermore, it should be noted that the shapes and names of the parts and components described in the specific embodiments described in this specification may differ. All equivalent or simple variations made to the structure, features, and principles described in this application are included within the scope of protection of this application. Those skilled in the art to which this application pertains may make various modifications or additions to the described specific embodiments or use similar methods to substitute them, as long as they do not deviate from the structure of this application or exceed the scope defined by the claims, all of which should fall within the scope of protection of this application.< / middlewareresult>

Claims

1. A dual-system architecture access control method based on guard logic decoupling, wherein the dual-system architecture includes a management console subsystem and a portal subsystem, characterized in that, Includes the following steps: The middleware return value boundary is constructed based on three navigation intentions: pass-through, final state, and redirection. The value of the middle node is verified by function signature, and the three-state middleware communication protocol is obtained. A responsibility chain execution engine is constructed based on the operating rules of the aforementioned three-state middleware communication protocol as the pipeline; Based on the user access routing path, session hydration status, and authentication activation conditions, three middleware nodes conforming to the function signature are constructed sequentially; wherein, the authentication activation conditions include: the current navigation is the management console subsystem and / or the current navigation is a protected page in the portal subsystem and / or the current navigation is a cross-system login intent; the hydration means converting the user login credentials stored in persistent storage into complete user information in memory; The three middleware nodes are sequentially passed to the chain of responsibility execution engine to register and obtain a logically decoupled guard pipeline; When responding to a user's navigation request, the guard pipeline uses the authentication activation conditions as the basis for judgment, and uses single sign-on authorization redirection and downgrade fallback as the unified exit point to obtain the authentication decision result.

2. The method according to claim 1, characterized in that: The transparent navigation intent is encoded as a default value, indicating that the current intermediate node does not make navigation decisions and transfers control to the next intermediate node; The final navigation intent is encoded as a Boolean value, indicating that the current intermediate node has made a final decision. The execution engine immediately terminates the pipeline and reports the Boolean value to the routing framework. A true Boolean value indicates permission to proceed, while a false Boolean value indicates cancellation. The redirection navigation intent is encoded as a route descriptor object, indicating that the current intermediate node decides to forward this navigation to another target route. The execution engine immediately terminates the pipeline and reports the route descriptor to the routing framework to initiate a new navigation.

3. The method according to claim 1, characterized in that, The operation rules that use the three-state middleware communication protocol as a pipeline to construct the chain of responsibility execution engine include the following steps: Execute the middleware nodes in the chain of responsibility pipeline one by one to obtain the navigation intent returned after each execution; If any of the returned navigation intents is a final state or a redirection, the execution engine immediately stops and reports the returned navigation intent to the framework as the final decision for this navigation. If all returned navigation intents from all nodes are transparent, the execution engine will make a pass decision.

4. The method according to claim 1, characterized in that, The process of constructing three middleware nodes that conform to the function signature based on the user access routing path, session hydration status, and authentication activation conditions includes the following steps: Based on the user's access route, the first node is constructed as follows: if the user is detected to be logged in and the user attempts to enter the login page or the landing page after single sign-on, the node returns a redirect navigation intent; if the user accesses the single sign-on callback address, the node returns a final navigation intent with a true value; otherwise, the node returns a pass-through navigation intent. Based on the session hydration status, a second node is constructed. Specifically, if the current session has been hydrated, the node returns a transparent navigation intent; if the user has logged in but the current session has not been hydrated, the node requests user information from the server. If the user information is successfully obtained, the node returns a transparent navigation intent; if the user information is not obtained, the node returns a false final state navigation intent. Based on the authentication activation conditions, a final node is constructed. Specifically: if authentication is not required, or if authentication is required but the user is already logged in, the node returns a transparent navigation intent; if authentication is required but the user is not logged in, it attempts to redirect to the single sign-on page. If the redirection is successful, the node returns a true final navigation intent; if the redirection fails, the node returns a redirect navigation intent; otherwise, the node returns a transparent navigation intent.

5. The method according to claim 1, characterized in that, The authentication activation conditions include determining whether the current navigation is the management console subsystem based on the path string of the target route, including the following steps: The node retrieves the path string of the target route; If the prefix of the path string of the target route is consistent with the root path of the management console subsystem, the node determines that strong authentication is required for this navigation; otherwise, it continues to determine whether the current navigation belongs to the portal subsystem.

6. The method according to claim 1, characterized in that, The authentication activation conditions include determining whether the current navigation is a protected page in the portal subsystem based on the metadata declaration field of the target route, and include the following steps: The node reads the metadata declaration field from the target route configuration; If the value of the metadata declaration field is true, the node determines that this navigation is a protected page request in the portal subsystem and requires declarative authentication.

7. The method according to claim 1, characterized in that, The authentication activation conditions include determining whether the current navigation is a cross-system login intent based on the cross-system login intent flag of the target route, including the following steps: The node retrieves the cross-system login intent flag from the query parameters of the target route; If the cross-system login intent flag is true, then this navigation is determined to be a cross-system login intent, which requires cross-system authentication.

8. The method according to claim 1, characterized in that, The step of sequentially passing the three middleware nodes into the chain of responsibility execution engine and registering them to obtain the guardian pipeline includes the following steps: Based on the business dependency order, the three middleware nodes are placed into an array in sequence to obtain an ordered middleware array; The ordered middleware array is passed as a parameter to the factory function of the chain of responsibility execution engine to construct the asynchronous pipeline function; The asynchronous pipeline function is registered as a callback parameter to the global pre-guard hook of the routing framework to take over route navigation, thus obtaining the guard pipeline.

9. A dual-system architecture access control system based on guard logic decoupling, used to implement the method as described in any one of claims 1 to 8, wherein the dual-system architecture includes a management console subsystem and a portal subsystem, characterized in that, The system includes: The communication protocol module is used to construct the value boundaries of the middleware return value based on three navigation intentions: transparent transmission, final state, and redirection, and to use function signatures to verify the values ​​of the middle nodes to obtain the three-state middleware communication protocol. The execution engine module is used to construct a chain-of-responsibility execution engine based on the operating rules of the three-state middleware communication protocol as a pipeline. The three-node construction module is used to sequentially construct three middleware nodes that conform to the function signature based on the user access routing path, session hydration status, and authentication activation conditions; wherein, the authentication activation conditions include: the current navigation is the management console subsystem and / or the current navigation is a protected page in the portal subsystem and / or the current navigation is a cross-system login intent; the hydration means converting the user login credentials stored in persistent storage into complete user information in memory; The guard pipeline registration module is used to sequentially pass the three middleware nodes to the chain of responsibility execution engine and register them to obtain logically decoupled guard pipelines. The decision result module is used to obtain the authentication decision result by using the authentication activation condition as the judgment basis and single sign-on authorization jump and downgrade fallback as the unified exit when responding to user navigation requests.

10. A dual-system architecture access control device based on guard logic decoupling, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

Images