Isomeric permission data conversion, dynamic routing security registration and degradation fallback method

Abstract

The application discloses a heterogeneous permission data conversion, dynamic routing security registration and degradation backup method, constructs a unified front-end UI component and a business page, adapts to multiple heterogeneous backends, sets a heterogeneous data adaptation layer between the heterogeneous backends and a unified front-end running support mechanism, converts the permissions, routes, capabilities and layout data of different backends into a unified data model, establishes a unified permission model and a unified capability model, divides common capabilities and business-specific capabilities, generates dynamic routing candidates according to a capability matrix, sequentially executes path normalization, permission association verification, component whitelist verification and joint verification, generates routing keys and registration keys for the verified candidates, realizes idempotent registration through a registration state machine, establishes a degradation route for recoverable exceptions, performs runtime authorization verification on static business routes, and cleanses in a reverse order of dependency relationship when a session is invalid or context switching is performed, so that multiple heterogeneous backends share the same front end.

Description

Technical Field

[0001] This invention belongs to the field of computer digital data processing technology, and specifically relates to a method for heterogeneous permission data conversion, dynamic routing security registration, and fallback mechanism. Background Technology

[0002] With the development of front-end and back-end separation in management systems, the same front-end application needs to connect to multiple back-end services built by different technical systems, business departments, or development teams. These different back-end services vary significantly in terms of authentication methods, interface protocols, data structures, menu models, permission encoding, resource identification, and business capability descriptions.

[0003] In existing technologies, front-end systems typically adapt to multiple heterogeneous back-end services using the following two methods: The first approach involves developing separate front-end pages and routing systems for different back-ends. However, common functions such as login pages, management interface frameworks, user management, role management, department management, menu management, and error / exception pages need to be implemented repeatedly in different front-end projects, resulting in code duplication, high maintenance costs, and gradual differences between implementations.

[0004] The second approach dynamically generates front-end routes based on the menu, permission, and routing data returned by different backends, reducing redundant page development. However, because the permission, menu, routing, and component identifiers returned by different backends are inconsistent, the frontend still needs to write a lot of adaptation logic for different backends. As the number of backends increases, the differentiated adaptation logic implemented by the frontend for different backends also increases, making frontend route generation, permission handling, and other functions strongly coupled with the specific backend data structures and implementation methods, thereby reducing the system's scalability and maintainability.

[0005] Existing dynamic routing implementations typically include methods such as the backend directly returning component paths and the frontend dynamically importing them, the backend returning component identifiers and mapping them through the frontend component registry, establishing component module mappings based on a batch module import mechanism, and the frontend predefining routes and controlling access through backend permission data. These methods present the following technical problems: First, there is insufficient security constraint: When the backend directly returns the component path (e.g., pagePath="@ / views / order / list.vue"), backend data directly participates in the loading of the frontend module. There is a lack of correlation validation between route data, component data, and permission data, leading to unauthorized routes being registered, unexpected components being loaded, or existing components being incorrectly exposed due to route configuration errors. Even if a component registry is used to map the component identifiers returned by the backend, if only the component identifier is validated without simultaneously validating whether the backend has the corresponding business capabilities, whether the user has the corresponding permissions, and whether the route path conforms to the rules, the problem of permissions, capabilities, routes, and components being disconnected will still occur.

[0006] Second, there is a coupling between public capabilities and backend-specific capabilities: different backends differ in authentication methods, security capabilities, and operational capabilities. If the frontend handles these differences by determining the specific backend type, as the number of backend services increases, the frontend needs to continuously add processing logic related to specific backend types. This causes public pages, public components, and public functions to gradually rely on the backend-specific implementation methods, increasing the adaptation complexity of the public frontend and reducing the reusability and maintainability of public capabilities.

[0007] Third, runtime state is difficult to manage reliably: Dependencies exist between dynamic menus, permission snapshots, capability states, dynamic routes, and component registration states during user login, permission changes, backend switching, or session expiration. Without a unified state identifier and lifecycle management mechanism, issues such as duplicate dynamic route registration, residual old session routes, inconsistencies between menus and actual routes, and state crosstalk between different users arise in scenarios like concurrent initialization, repeated logins, repeated registrations, or login exits.

[0008] Fourth, exception handling leads to inconsistent states: For exceptions such as failure of dynamic route registration, failure of component loading, or failure of permission verification, the existing implementation usually terminates route registration directly or redirects to a general error page, resulting in the menu being displayed but the corresponding route being inaccessible, and no confirmation page response after the user clicks, and the front-end navigation state is inconsistent with the actual running state.

[0009] In summary, how to enable multiple heterogeneous backend services to securely access the same frontend application without modifying the original business implementation of each heterogeneous backend, and how to solve problems such as unified heterogeneous data conversion, backend capability identification and separation of common capabilities, dynamic route secure registration, idempotency guarantee, anomaly degradation, and lifecycle state consistency, have become urgent technical problems to be solved. Summary of the Invention

[0010] The purpose of this invention is to provide a method for heterogeneous permission data conversion, dynamic routing security registration, and fallback, which overcomes the problems of inconsistent permission and capability data structures, insufficient security constraints for loading dynamic routing components, coupling between common capabilities and backend-specific capabilities, and difficulty in reliably managing the frontend's running status when multiple heterogeneous backends are connected to a unified frontend.

[0011] To achieve the above objectives, this application provides a method for heterogeneous permission data conversion, dynamic routing security registration, and fallback, comprising the following steps: S1. Heterogeneous Data Adaptation: A heterogeneous data adaptation layer is set up between heterogeneous backend services and a unified frontend operation support mechanism. The unified frontend operation support mechanism provides at least unified permission processing, capability management, dynamic routing management, controlled component registration, operation status management, and lifecycle cleanup functions. The heterogeneous data adaptation layer contains multiple adaptation instances registered according to backend identifiers. The heterogeneous data adaptation layer selects an adaptation instance through the current backend identifier, obtains the original data of the current backend, and converts the original data into a unified data model. The original data includes user, role, department, menu, resource, permission, route, capability, and layout data. S2. Establish a unified permission model: Build a unified permission model based on a unified data model, and create permission access snapshots based on the current backend identifier, user identifier, and session identifier; the permission access snapshot should at least include the context generation, snapshot version, and configuration snapshot identifier, which will serve as a unified basis for menu display, route generation, capability judgment, and authorization verification. S3. Establish a unified capability model: Based on the unified permission model, build a unified capability model, assign a unique capability identifier to each capability, and divide the front-end functions into public capabilities, business-specific capabilities, and extended capabilities; for business-specific capabilities, establish a heterogeneous back-end capability matrix, using the back-end identifier and capability identifier as matrix dimensions, and record whether each back-end provides each business-specific capability. S4. Dynamic route candidate generation: Obtain the functional availability result based on the heterogeneous backend capability matrix, and associate the business route with the functional availability result; for business routes where the capability is available and the current user meets the corresponding access permission conditions, extract the path, component identifier, capability identifier and menu identifier from the unified routing data to generate dynamic route candidates; S5. Path Normalization: Normalize the paths of dynamic route candidates, separate the path from the additional information, unify the path format, and generate normalized paths; candidates that have not been normalized are prohibited from entering subsequent verification. S6. Permission association verification: For candidates that pass normalization, establish the association between the normalized path, capability identifier, permission identifier and permission access snapshot, verify that the snapshot version and context generation are consistent with the access context, and call the unified permission evaluator to complete the permission association verification. S7. Component whitelist verification: Query the controlled component registry based on the component identifier, and verify that the component record is enabled and matches the current backend identifier and capability identifier; S8. Joint verification: Confirm that the verification results of steps S5-S6 belong to the same backend identifier, user identifier, session identifier, context generation and dynamic route candidate. Query the capability matrix and related records and confirm that the capabilities, permissions and component associations corresponding to the dynamic route candidates are in a valid state. S9. Dynamic route idempotent registration: Generates route keys and registration keys for candidates that pass joint verification; manages the registration process through a registration state machine, reuses existing registration tasks for repeated or concurrent requests in the same access context, and ensures that the route table is written only once for the same route. S10. Runtime authorization for static business routes: For static business routes that have been pre-existing in the front-end routing table, when a user accesses the route, runtime authorization verification is performed based on the current back-end capabilities, user permissions, and access snapshot, and the verification result is used to determine whether access is allowed. S11, Fallback Route: When the target route fails to load a component or fails to recover a write operation, and the current capabilities, user permissions, and context are still valid, the target route will be mapped to a pre-configured fixed fallback component and a fallback route will be established; fallback route mapping will not be executed in case of exceptions such as permission denial, unavailable backend capabilities, or invalid access context. S12, Lifecycle Reverse Cleanup: Establish a lifecycle state list bound to the session, recording the dependencies of permission snapshots, capability states, menu nodes, and route registrations; when a session expires or a context switches, perform cleanup according to the reverse dependency of page, route, menu, and permission snapshots, and prohibit the asynchronous task results of the old context from being written to the new access context.

[0012] Furthermore, in step S1, the adaptation instance adopts the following conversion rules: The backend identifier is fixedly written by the currently selected adaptation instance and is not inferred from user data, path or other business fields; Between users and roles, menus and routes, routes and permissions, and routes and capabilities, only full-value equality connections are performed based on the original identifier; Original permissions, capabilities, components, and route types are only transformed through precise mapping items pre-registered under the current backend identifier; if no mapping item exists, the data mapping is recorded as not found. If the parsing process identifies duplicate identifiers, it records the identifier conflict. If it finds that a referenced record is missing, it records the missing relationship and stops forming the corresponding unified record. Boolean values, root node values, and null values ​​on each backend are converted according to their own parsing rules, and parsing conversion logic is not mixed between different backends.

[0013] Furthermore, in step S3, the distinction between public capabilities and business-specific capabilities includes: Obtain the set of functions to be provided by the unified front end, and determine the business meaning, page, component and operation scope of each function; Functions that share common basic semantics across all heterogeneous backends, can reuse unified pages or layout components, and whose backend differences can be eliminated through adaptation rules will be identified as common capabilities, and a unified common capability identifier will be set for these common capabilities. Functions provided by a single or partial heterogeneous backend and whose business implementation depends on the corresponding heterogeneous backend are defined as business-specific capabilities, and a unified business capability identifier is configured.

[0014] Furthermore, in step S3, constructing the unified capability model includes the following steps: S3.1 Define the capability identifier, capability name, and capability type for public capabilities, business-specific capabilities, and extended capabilities; S3.2. Associate common capabilities with unified front-end pages, components, and optional default paths; S3.3. Through the heterogeneous data adaptation layer, the original capabilities representing the same business meaning in different backends are mapped to the same capability identifier; S3.4 Associate capability records with unified routing data through capability identifiers, and retain backend custom paths; S3.5 Output a unified capability record for use in capability matrix creation and joint capability permission judgment.

[0015] Furthermore, in step S5, the normalization process includes the following steps: S5.1 Verify that the backend identifier, user identifier, session identifier, and context generation of the dynamic route candidate are consistent with the current access context; S5.2 Determine whether the original path is a non-empty string, and verify the length of the original path and the preset path level limit; S5.3 Parse the original path and separate the original path, query parameters and fragment identifiers. If the original path contains external address information, the processing is deemed to have failed. S5.4, unify the format of forward slashes, repeating separators, current level identifiers, and starting root paths; S5.5 Validate the parent directory identifier, encoded characters, control characters, ordinary path fragments, dynamic parameters, and wildcards; S5.6 Generate a normalized path and verify its length, level, and conflicts with restricted paths; S5.7 Write the original path, normalized path, and processing result into the processing record, and only submit the candidates that pass the normalization to the subsequent verification.

[0016] Furthermore, during the verification process in step S7, a controlled component registry is pre-configured. The controlled component registry stores the component identifier, the corresponding component loader, the applicable scope of the backend, and the associated capability identifier. Heterogeneous backends are only allowed to output the component identifier and are prohibited from directly outputting the frontend component file path. During verification, the controlled component registry is precisely searched based on the component identifier of the dynamic route candidate. The system sequentially verifies whether the component record is in the enabled state, whether the component adapts to the current backend identifier, and whether the component's associated capability identifier matches the capability identifier of the dynamic route candidate. If any verification condition is not met, the dynamic route candidate is rejected from entering the next processing step.

[0017] Furthermore, in step S9, the dynamic route idempotent registration includes: S9.1 Generate a routing key based on the normalized path, component identifier, capability identifier, and permission identifier of the dynamic route candidate; generate a registration key by overlaying the backend identifier, user identifier, session identifier, and context generation on the routing key; S9.2. The registration status is maintained using the registration key as the key. The registration status includes unregistered, registering, registered, failed, and removed. The status transition rule is as follows: the unregistered status or the failed status that meets the retry conditions is switched to the registering status. The registering status is then switched to the registered status or the failed status. The registered status is switched to the removed status during the lifecycle cleanup. S9.3 The first request changes the status to "Registering" and performs route writing. Subsequent requests with the same key reuse the task and processing result of the first request. If the request is already registered, the existing result is returned directly without repeating the writing. Temporary failures are allowed to be retried, but retry is not performed in cases of path conflict or permission denial. S9.4 Parent and child routes generate corresponding keys respectively. The child route reuses the registration task of the parent route. If the parent route fails to register, the child route will not write the key. Different front-end tabs maintain their registration status and route handles independently.

[0018] Furthermore, in step S10, the runtime authorization verification includes the following steps: S10.1 Receive route access request, and read the backend identifier, user identifier and session identifier in the current access context before the target route is activated; S10.2. Query the static business route authorization registration table based on the current backend identifier, normalized path, or route name to obtain the corresponding authorization record; S10.3 Determine whether the authorization record exists, whether it is enabled, and whether the authorization method can be determined; S10.4 Obtain the current access snapshot and record the context generation and snapshot version used in this verification; S10.5 When the authorization method requires capability judgment, query the capability matrix to confirm the corresponding capability and whether it is in the enabled state; S10.6 When the authorization method requires permission judgment, call the unified permission evaluator to perform permission verification; S10.7 Verify that the normalized path matches the path or path pattern in the authorization record; S10.8. Query the component registry based on the component identifier to confirm that the component record exists and is in an enabled state; S10.9. Route navigation is allowed when all conditions are met; the target component is not activated when any condition is not met.

[0019] Furthermore, in step S11, the fallback route specifically includes the following steps: S11.1 Receive abnormal events and corresponding candidates, registration records or runtime authorization records; S11.2. Based on the tracking identifier, backend identifier, user identifier, session identifier, and context, confirm that the exception belongs to the current valid context; S11.3. Based on the exception cause code, query the enabled matching strategy to confirm that the exception belongs to the set of exceptions that are allowed to be downgraded; S11.4 Confirm that the original route has met the prerequisites of path normalization and permission verification; S11.5 Confirm that the target capability identifier is still provided by the current backend identifier and that permission evaluation is still allowed; S11.6. Query the downgrade component registry based on the fixed downgrade component identifier and obtain the controlled downgrade component loader; S11.7 Generate a unique identifier for the downgraded registration and establish a downgraded route; S11.8 If the downgraded route is successfully established, the downgraded status will be set to active; if the establishment fails, the downgraded status will be set to failed.

[0020] Furthermore, in step S12, the lifecycle reverse cleanup includes the following steps: S12.1 Receive exit, session expiration or backend switch, snapshot revocation or application reset events, and locate the lifecycle state list; S12.2 Generate a cleanup identifier based on the lifecycle identifier and context generation, and set the lifecycle state to frozen through atomic state change; S12.3 Save the current context generation as an invalid generation, and add a generation or unbind the old session identifier from the current context generation; S12.4. Verify the lifecycle status and context generation at the write entry points for candidate generation, route registration, degradation establishment, and page activation. If the lifecycle is in an invalid generation or inactive, the write operation will be rejected. S12.5 Cancel unfinished tasks that can be canceled, and mark non-cancellable tasks as invalid in their original generation; S12.6 Terminate unfinished business navigation, remove the association between the activity page and the authorization context, and prohibit the old page from continuing to perform restricted operations; S12.7 Remove degraded routes, dynamic routes, menu nodes, capability status, access permission snapshots, and session bindings in reverse order of dependency; S12.8 After the resource is cleared, set its lifecycle status to cleared.

[0021] After adopting the above solution, the beneficial effects of the present invention are as follows: 1. This invention establishes a heterogeneous data adaptation layer between heterogeneous backend services and a unified frontend runtime support mechanism. This layer transforms heterogeneous data such as permissions, routes, and capabilities from different backends into a unified data model and a unified permission model. This allows multiple heterogeneous backends to share the same set of frontend pages, components, and runtime. Adding a new backend only requires supplementing the adaptation mapping rules, eliminating the need to repeatedly develop common frontend pages for different backends. Furthermore, using permission access snapshots as the unified data basis for menu display, route generation, capability judgment, and authorization verification avoids inconsistencies in data interpretation and permission judgment caused by different pages parsing data from different backends.

[0022] 2. This invention establishes a unified capability model and a heterogeneous backend capability matrix, separating common capabilities such as login, user management, and role management from the unique business capabilities of each backend. Common capabilities are provided uniformly, while backend-specific capabilities can be extended independently. This reduces the impact of differences in backend business on the runtime of the common frontend, reduces coupling caused by writing conditional branching logic for specific backend types, and improves the system's scalability.

[0023] 3. This invention establishes a continuous security verification process: path normalization → permission association verification → component whitelist verification → joint verification → idempotent registration. Unnormalized original paths are prohibited from entering subsequent processes; components can only query trusted loaders through the controlled component registry, prohibiting the backend from directly specifying file paths; registration is only allowed when backend capabilities, user permissions, normalized paths, and component identifiers all match. This multi-condition joint constraint effectively avoids the security risks of unauthorized route registration and unexpected component loading.

[0024] 4. This invention identifies the routing service identity through routing keys and registration keys, and manages the registration process through a registration state machine. In the same access context, repeated or concurrent requests reuse existing registration tasks, ensuring that the routing table is written only once for the same route, thus avoiding runtime state abnormalities caused by repeated registration and concurrent competition.

[0025] 5. This invention performs runtime authorization verification on pre-compiled front-end business components. The physical existence state of the component or route is not used as the basis for judging whether the user has access rights. This makes "the front-end has the ability to load components" and "the current user has business access rights" independent judgment conditions, preventing the bypassing of permission control through the static existence state of components.

[0026] 6. This invention establishes a fallback routing mechanism. In the event of a recoverable anomaly, the target route is mapped to a fixed fallback page, forming a correspondence of "menu → route → fixed page," avoiding the problem of the menu being displayed but the page being unresponsive. Security anomalies such as permission denial prohibit fallback, preventing the use of the fallback mechanism to bypass security controls. Simultaneously, a structured auditing mechanism records key events at each stage of processing, facilitating anomaly tracking and problem localization.

[0027] 7. This invention establishes a lifecycle state list bound to the session. When the session expires or the context switches, cleanup is performed in reverse order of page, route, menu, and permission snapshot. The asynchronous task results of the old context are prohibited from being written to the new access context, effectively avoiding state crosstalk and residual problems between different users, different backends, or different permission contexts. Attached Figure Description

[0028] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is a flowchart of the method of the present invention; Figure 3 This is an end-to-end timing diagram according to an embodiment of the present invention. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0030] Key references Figures 1-3 This invention provides a method for heterogeneous permission data conversion, dynamic routing security registration, and fallback, which is implemented by a system.

[0031] like Figure 1 As shown, the system includes client devices, a unified front-end application, a unified front-end operation support mechanism, a heterogeneous data adaptation layer, and heterogeneous back-end services.

[0032] The client device is used to receive user login, menu selection, route access, backend switching, and logout operations, and to display the unified frontend application's pages. The client device can be a personal computer, smartphone, tablet, or other electronic device with a browser or frontend runtime container. Users interact with the unified frontend application through the client device, initiating various business operation requests.

[0033] The unified front-end application runs in the browser or other front-end runtime container of the client device, and creates a unified front-end runtime support mechanism and a heterogeneous data adaptation layer within the same application process.

[0034] The unified front-end operation support mechanism is used to maintain the current access context, load configuration data, establish permission access snapshots and capability status, generate menus and route candidates, and perform route verification, component query, route registration, runtime authorization, degradation processing and lifecycle cleanup.

[0035] The access context is defined by at least the backendId (backend identifier), userId (user identifier), sessionId (session identifier), and contextGeneration (the lifecycle generation of the current access context, hereinafter referred to as context generation). The loaded configuration data includes common capability route mappings, heterogeneous backend capability matrices, component registry, route capability component association tables, static route authorization tables, and degradation policy tables, all loaded from the configuration management storage. The established permission access snapshots and capability states serve as the unified basis for menu display, route generation, capability judgment, page access, and business operation authorization. The generated menus and route candidates are used to perform route verification, component query, route registration, runtime authorization, degradation processing, and lifecycle cleanup.

[0036] The heterogeneous data adaptation layer is a collection of logical functions for heterogeneous data conversion. This layer runs in an adaptation environment provided by a unified front-end support mechanism, and internally pre-configures adapter templates corresponding to each heterogeneous backend. The heterogeneous data adaptation layer calls various basic support components provided by itself, selects the corresponding adaptation instance based on the current backend identifier, obtains the raw data output by the heterogeneous backend service, completes raw data parsing, field mapping, and validity verification, and transforms the raw data of users, roles, departments, menus, resources, permissions, routes, capabilities, and layouts into a unified data model.

[0037] The configuration management storage is located on the service side accessible by the unified front-end application. It is used to centrally store the configuration data required by the unified front-end application for back-end capability judgment, route mapping, component query, joint verification, static authorization, and abnormal degradation handling. It establishes the correspondence between common capabilities, heterogeneous back-end capabilities, routes, components, and authorization rules through configuration tables. The configuration tables include at least a common capability route mapping table, a heterogeneous back-end capability matrix table, a component registry, a route capability component association table, a static route authorization table, and a degradation policy table.

[0038] The heterogeneous backend services are deployed within the same service process or service cluster to perform the original authentication and business processing within a single deployment unit, and return the authentication results, permission data, menu data, routing data, capability data and business processing results in the original format to the heterogeneous data adaptation layer.

[0039] In one embodiment, the overall architecture of the system is as follows: The heterogeneous backend services retain the original heterogeneous business modules, data sources, or interface implementations within a service process or a service cluster, and use Backend-A (backend service A), Backend-B (backend service B), and Backend-C (backend service C) as backend identifiers. Backend-A, Backend-B, and Backend-C are no longer deployed as independently, but are routed and isolated by the same heterogeneous backend service according to backendId (backend identifier).

[0040] When the unified front-end runtime support mechanism starts, it creates a heterogeneous adaptation runtime environment. This runtime environment includes at least an adapter registry, a raw response parser, a unified model converter, a session context, a capability matrix, and a configuration snapshot. The adapter registry registers the field mappings and request conversion rules for Backend-A, Backend-B, and Backend-C according to their backendIds. The adaptation layer only changes the data reading, field mapping, and request orchestration methods; it does not change the original interface paths, request parameters, success / failure return envelopes, login authentication, permission calculation, menu generation, or basic business processing of the heterogeneous backend services.

[0041] like Figure 1 As shown, the deployment relationships and data flow between the system components are as follows: The data returned by the heterogeneous backend service first enters the corresponding backend adapter according to the currently selected backendId. The backend adapter processes the data according to preset field mapping rules and structure transformation rules to form a unified data model for processing by the unified frontend application. The unified frontend application does not directly read the original permission, menu, route, or capability fields returned by the heterogeneous backend service, but obtains the transformed unified data through the corresponding backend adapter. During the data transformation process, the original response envelope of the heterogeneous backend service remains unchanged. For example, the success response continues to retain the original successCode, data, and message fields, and the failure response continues to retain the original successCode, errorCode, message, and data fields. The backend adapter only establishes the association between rawResponse and normalizedData within the unified frontend application. The rawResponse is used to retain the original response of the heterogeneous backend service, and the normalizedData is used to provide the standardized data required for processing by the unified frontend application. Thus, the response structure of the original interface of the heterogeneous backend service is not changed, and the original interface users are not required to modify it synchronously. After a business operation request generated by a client device enters the unified front-end application, the unified front-end application determines the corresponding back-end adapter based on the current access context. The back-end adapter then converts the unified request into a request format that the corresponding heterogeneous back-end service can recognize according to preset request conversion rules and sends it to the heterogeneous back-end service. After the heterogeneous back-end service completes the business processing, it returns the original response. This response is then parsed and normalized by the corresponding back-end adapter before being used by the unified front-end application. This forms a bidirectional adaptation link for converting heterogeneous back-end responses to a unified data model and for converting unified business requests to heterogeneous back-end request formats.

[0042] At any given time, an access context is bound to only one current backend identifier. This access context is defined by at least `backendId`, `userId`, `sessionId`, and `contextGeneration`. The unified frontend application only activates the backend adapter corresponding to the current `backendId` within the access context and only writes the data obtained and transformed by the backend adapter into the current permission snapshot, capability status, menu set, and route set. When access to other backend services is required, the current access context is first terminated, and the permission snapshot, capability status, menu set, and route set corresponding to the current access context are cleared. Then, a new access context corresponding to the target `backendId` is established, and the corresponding backend adapter is activated. Multiple backend adapters are not activated simultaneously within the same access context, nor are multiple backend services mixed and written to.

[0043] like Figure 3 As shown, the system's workflow is as follows: During the initialization of the unified front-end application, a unified front-end runtime support mechanism and heterogeneous adaptation layer are first created, and configuration tables, adapter registry, and component registration information are loaded from the configuration management storage. Then, the initialization context of unbound modules is established and the login entry or module selection entry is displayed. Before the current backendId and valid session are determined, business menus, business capability status, or dynamic business routes are not established based on residual data from any backend.

[0044] When a user logs in, the unified front-end runtime support mechanism first determines the current backendId based on the user's selection, access point, or pre-determined module location information. Figure 3 (Backend-A) Then, select the heterogeneous data adaptation layer corresponding to the backendId, and call the original authentication interface of the unified heterogeneous backend service through the adaptation layer; after successful authentication, return the authentication result, and continue to obtain the original data of the current user, such as user, role, department, menu, resources, permissions, routes, capabilities, and layout data; the adaptation runtime environment converts the original data into a unified data model; the unified front-end runtime support mechanism then sequentially establishes permission access snapshot, capability status, layout selection result, menu set, public route, and dynamic route status, and finally sets the access context to an accessible state. When authentication fails or data conversion fails, the corresponding business route set is not activated, and the backend failure status and error information are retained as is for display on the login page.

[0045] When a user requests to switch backend modules within the same heterogeneous backend service, the unified frontend runtime support mechanism first freezes the access context corresponding to the old backendId, invalidating the old contextGeneration. Then, it cleans up old pages, caches, routes, menus, capability states, and permission snapshots. Only after the old lifecycle reaches a state that allows the creation of a new context is achieved is a new BackendId determined, a new adaptation layer selected, and authentication or session confirmation, raw data acquisition, unified data transformation, permission snapshot creation, capability judgment, and route establishment re-executed. During the switching process, delayed results returned by the old module adapter must not be written to the new access context.

[0046] When a session needs to be rebuilt due to session expiration, permission access snapshot revocation, user switching, or application runtime context reinitialization, the unified frontend runtime support mechanism first invalidates the original sessionId or original contextGeneration and completes the cleanup of the old state. Then, based on the rebuilt backendId, userId, and sessionId, it selects the corresponding backend adaptation instance, re-acquires data, and establishes a new permission access snapshot and routing state. Session reconstruction does not reuse permission judgment results, capability judgment results, dynamic route instances, degraded route instances, or page caches from the old access context.

[0047] like Figure 2 As shown, the registration method includes the following steps: S1, Heterogeneous Data Adaptation A unified set of front-end UI components and business pages is constructed, enabling these components and pages to adapt to multiple heterogeneous back-end services with different permission data structures, routing organization methods, business capabilities, and interface protocols. A heterogeneous data adaptation layer is set up between the heterogeneous back-end services and the unified front-end operation support mechanism. This layer contains multiple adaptation instances registered according to back-end identifiers. The layer selects an adaptation instance based on the current back-end identifier, obtains the original data from the current back-end, and converts the original data into a unified data model. The original data includes user, role, department, menu, resource, permission, route, capability, and layout data.

[0048] The unified data model includes at least user, roles, departments, menus, resources, permissions, routes, capabilities, and layoutConfig. The unified front-end runtime support mechanism only performs menu processing, permission and capability judgment, route generation, registration, and component loading on this model, and does not directly depend on the original fields.

[0049] For unified routing data, the following fields are mandatory: backendId, routeType, capabilityId, sourcePath, path, name, and componentId. Child routes also require parentPath, business-authorized routes require permissionIds, and menuId is required when creating menus. Mandatory fields must not be missing or null; the default set is empty. If a field is missing, it will not be inferred from the name, path, or similar fields; the record will be set to INVALID and recorded as FIELD_MISSING.

[0050] The adaptation instance adopts the following conversion rules: the backend identifier is fixedly written by the currently selected adaptation instance and is not inferred from user data, paths or other business fields; between users and roles, menus and routes, routes and permissions, and routes and capabilities, only full value equality joins are performed based on the original identifier; the original permissions, capabilities, components and route types are only converted through the pre-registered precise mapping items under the current backend identifier. If no mapping item exists, the data mapping is not found and no approximate identifier is used for mapping; if duplicate identifiers are identified during the parsing process, identifier conflicts are recorded. If a missing referenced record is found, the record relationship is missing and the formation of the corresponding unified record is stopped; the boolean values, root node values ​​and null values ​​of each backend are converted according to the backend's own parsing rules, and parsing conversion logic is not mixed between different backends.

[0051] The same common capability can retain custom paths from different backends. For example, if the department management capability uses / dept, / deptmanager, and / dept / main in Backend-A, Backend-B, and Backend-C respectively, after adaptation, each backendId and sourcePath will still be retained, but the capabilityId and componentId will be uniformly set to DepartmentManagement, thus reusing the same common page.

[0052] Specifically, the heterogeneous data adaptation includes the following steps: S1.1 Obtain the original user, role, department, menu, resource, permission, route, capability and layout data of the current backend; S1.2 Select a unique adapter instance based on the current backendId; S1.3 Check if the original identifiers are duplicated, and perform exact equi-joins on users and roles, menus and routes, routes and permissions, and routes and capabilities; if duplicate identifiers or missing references are found, output data identifier conflicts or missing data relationships respectively. S1.4 Copy the fields according to the field-by-field mapping rules of the current adaptation instance, convert boolean values, root node values ​​and null values, and query the mapping of permissions, capabilities, components and route types; output "data mapping not found" if no exact mapping exists. S1.5 After all checks and mappings are successful, output unified user, role, department, menu, resource, permission, route, capability, and layout data for use in subsequent permission model, capability model, and route processing flow.

[0053] This restricts the differences in data structure between backends to the adaptation layer, decoupling the unified frontend operation support mechanism from the specific backend data implementation method.

[0054] S2. Establish a unified permission model A unified permission model is established on the basis of a unified data model to convert users, roles, departments, menus, resources, permissions and routes from different backends into consistent access control data. User identifiers represent access subjects, roles and departments represent subject relationships, menu identifiers represent function entry points, resources and permissions represent protected objects and allowed operations, and routes associate actual paths, capabilities, menus, permissions and frontend components.

[0055] The unified front-end operation support mechanism establishes permission access snapshots based on the current back-end identifier, user identifier, and session identifier. Permission access snapshots must at least bind the context generation, snapshot version, matrix version, configuration snapshot identifier, and creation time, and save a non-null set of permissions, menus, routes, and capabilities. Snapshots will be refused if any required fields are missing.

[0056] In this invention, the same permission evaluator is used for function availability determination, route candidate generation, permission association verification, joint verification, pre-registration review, static route authorization, and page operation authorization. The input to the unified permission evaluator includes at least the current context, version information, permission identifier set, permissionMatchMode (permission matching mode), and permission access snapshot. The output result is: permission granted, no permission, or invalid permission rule. Page entry permissions and page operation permissions are evaluated separately; subsequent stages must not change an existing no-permission verification result to allowed access.

[0057] The capability dictionary, original capability mapping, route mapping, heterogeneous backend capability matrix, component registration configuration, route association configuration, static authorization configuration, and degradation strategy configuration all use monotonically increasing and non-reusable version numbers for version control. At runtime, only the unique, already effective ACTIVE version within the same configuration type is loaded, and all effective versions are combined into a read-only configSnapshotId (configuration snapshot identifier). New and old configurations must not be mixed within the same access context. If multiple ACTIVE versions are detected, version rollback occurs, or configuration references are missing, configuration loading fails. If a recently available valid snapshot exists, that snapshot will continue to be used for business operations; if no recently available valid snapshot exists, business routes dependent on that type of configuration will not be created.

[0058] The routes within the access snapshot only contain the public routes and business routes corresponding to the current backendId. Public routes retain the current backend's sourcePath, path, and unified capabilityId, while business routes retain the capabilityId, componentId, and permissionIds required to generate candidates. Access snapshots corresponding to different backend identifiers, user identifiers, session identifiers, or contextGenerations are isolated from each other; data that does not belong to the current backendId, userId, or sessionId is prohibited from being written to the current access snapshot.

[0059] Specifically, the process for building a permission access snapshot is as follows: S2.1. Obtain the backendId, userId, and sessionId from the current access context; S2.2 Filter out the user, role, department, menu, resource, permission, route and capability data corresponding to the current backendId from the unified data model; S2.3. Verify that the user identifier matches the current userId, and write the role, department, and permissions associated with the current user. S2.4 Write the current backend's public and business routes, and retain the capabilityId, sourcePath, path, componentId, and permissionIds; S2.5 Write the current backend capability data and associate the capability with the route using capabilityId; S2.6. Generate snapshotVersion, write contextGeneration, matrixVersion and configSnapshotId into the snapshot, form a versioned permission access basis bound to the backend, user and session, and provide it to the capability judgment and routing process.

[0060] Furthermore, when the backend capability provision changes, a new capability matrix version (matrixVersion) is generated; when user roles, permissions, menus, routes, or permission validity periods change, a new snapshot version (snapshotVersion) is generated; and when user login, backend switching, user switching, session reconstruction, snapshot revocation, or application reset events occur, a new context generation (contextGeneration) is generated. Permission access snapshots and various processing results derived from snapshots are bound to backendId, userId, sessionId, contextGeneration, snapshotVersion, matrixVersion, and configSnapshotId. When any of these identifier fields does not match the current access context, the old snapshot derivation result must not continue to perform data writing, route registration, component activation, or be used for runtime authorization verification.

[0061] S3. Establish a unified capability model A unified capability model is established based on a unified permission model to describe common capabilities, backend business-specific capabilities, and extended capabilities that affect frontend operation. The unified capability model assigns a unique capability identifier to each frontend function's corresponding capability and categorizes these capabilities into common capabilities, business-specific capabilities, and extended capabilities based on their applicable scope. For business-specific capabilities, a heterogeneous backend capability matrix is ​​established, using backend identifiers and capability identifiers as matrix dimensions. This matrix records whether each heterogeneous backend service provides the corresponding business-specific capability. Based on the heterogeneous backend capability matrix, the available business capabilities of the current backend service are determined. This allows the unified frontend operation support mechanism to no longer directly determine business functions based on backend type, but instead to rely on capability identifiers to construct a heterogeneous backend capability matrix, routing mapping relationships, and the association between capabilities and permissions.

[0062] Common capabilities are shared by multiple backends or pre-provided with pages, layouts, and components by a unified frontend. Typical common capability identifiers include login, management interface layout, user management, role management, department management, menu resource management, and exception handling. Business-specific capabilities are provided by one or more backends, or rely on backend-specific business objects, interfaces, or processing flows. Typical business-specific capability identifiers include parameter management, rule models, strategy flows, data dictionary management, sensitive word filters, and log auditing. Extended capabilities operate on authentication logic, page themes, or frontend runtime mechanisms and generally do not generate independent business operation pages.

[0063] Public capabilities can be associated with custom paths from different backends, selecting the corresponding layout component or default path at runtime under the current backendId. Business-specific capabilities are associated with page components and permissions through componentId and permissionIds. Extended capabilities are controlled by influencing the frontend's operation through capability parameters. The capabilityId, capabilityName, capabilityType, dictionaryVersion, and status fields in a capability record are mandatory. If any field is missing, the capability record is set to INVALID (invalid state), and FIELD_MISSING (field missing exception) is recorded.

[0064] When different backends possess capabilities representing the same business function, capability merging must be determined by combining the business object, business purpose, core operation, input / output semantics, and pre-configured precise mapping items. Merging should not be based solely on the similarity of name, path, or page title. Capability records are associated with unified routing data through capabilityId, enabling the mapping of custom paths from heterogeneous backends to common capabilities or business-specific capabilities.

[0065] The establishment of a unified capability model includes the following steps: S3.1.1 Define the capabilityId, capabilityName (capability name), and capabilityType (capability type) for public capabilities, business-specific capabilities, and extended capabilities. S3.1.2. Associate common capabilities with unified front-end pages, components, and the optional defaultPath. S3.1.3 Through the heterogeneous data adaptation layer, the original capabilities with the same business meaning in each heterogeneous backend are mapped to the same capabilityId; S3.1.4 Associate capability records with unified routing data using capabilityId, and retain custom paths on the backend side; S3.1.5 Output standardized unified capability records for use in capability matrix establishment and joint capability permission judgment.

[0066] The distinction between public capabilities and business-specific capabilities may include the following steps: S3.2.1 Obtain the set of functions to be provided by the unified front-end operation support mechanism, and determine the business meaning, page, component and operation scope of each function; S3.2.2. Functions that have common basic semantics, can reuse unified page or layout components, and whose backend differences can be eliminated by determining adaptation rules among all heterogeneous backends included in the system are identified as common capabilities, and a unified common capability identifier is set for the common capabilities. S3.2.3. Define functions that are provided by only one or some heterogeneous backends and whose business implementation depends on the corresponding heterogeneous backends as business-specific capabilities, and set a unified business capability identifier for the business-specific capabilities. S3.2.4 Provide public capability identifiers, public pages, and public components to the heterogeneous data adaptation process and the public capability routing mapping process, and provide business-specific capability identifiers to the unified capability model and the heterogeneous backend capability matrix.

[0067] S4. Dynamic Route Candidate Generation A heterogeneous backend capability matrix is ​​established based on a unified capability model, using capabilityId as the capability dimension and backendId as the backend dimension to record whether each backend provides business-specific capabilities. The capability matrix only determines whether a backend provides the target function, without directly granting user permissions. Whether a user can ultimately use the function must also be determined by considering the current user, access snapshot, contextGeneration, snapshotVersion, and matrixVersion.

[0068] A unified front-end runtime support mechanism performs business function availability determination as a prerequisite for dynamic route generation, thereby decoupling back-end function provisioning from user access permission determination. The determination process is as follows: The system retrieves the backend identifier, user identifier, session identifier, and access permission snapshot of the current access context. It then queries the capability matrix based on the target capability identifier, reads the capability record of the current backend, and determines the function is unavailable if the capability record is missing or not enabled. If the capability is valid, it calculates the page entry permission based on the page permission identifier set and matching pattern, and calculates the value for each operation permission separately. It verifies that the backend, user, session, context generation, snapshot version, and capability matrix version in the access permission snapshot are consistent with the current context. If the capability is valid, the version matches, and the page permission is granted, the function status is set to available and the allowed operation permissions are recorded. If page permission is denied, it is set to unavailable. If the permission rule is invalid, it is marked as INVALID. The determination results are provided to the page and routing processing flow.

[0069] The above mechanism uses a unified capability identifier and a unified permission evaluator to separate the two judgments of whether the backend provides business functions and whether the user has the right to use them, thus forming the pre-verification logic for dynamic route generation.

[0070] After completing the unified permission model, unified capability model, heterogeneous backend capability matrix, and functional availability assessment, the unified frontend operation support mechanism distinguishes between common capabilities and heterogeneous backend-specific capabilities for routing processing.

[0071] Public capabilities are pre-configured with public capability identifiers, default paths, and public components by a unified front-end runtime support mechanism. These are stored via public capability route mapping, storing the backendId, capabilityId, custom path, route name, componentId, and menuId. At runtime, only the mapping corresponding to the current backendId is read. If a custom path is valid, it is used first; otherwise, the default path is used if no custom path is configured and default paths are allowed. Public pages can be reused by multiple heterogeneous backends, but are subject to current access snapshot constraints and are not automatically opened to any user simply because they belong to a public route.

[0072] Heterogeneous backend-specific business routes are not all pre-registered. At runtime, the availability of each business function in the current backend service is determined based on the capabilities of the heterogeneous backend, and the business routes are associated with the functional availability results. For business routes that are functionally available and for which the current user meets the corresponding access permission conditions, the path, component identifier, capability identifier, and menu identifier are extracted from the unified routing data to generate dynamic route candidates. Candidates only represent data to be processed and must undergo path normalization, permission association verification, component whitelist verification, and joint verification before they can be registered. Layout-type parent routes that only carry child routes are not retained if there are no accessible child routes.

[0073] Specifically, the registration of public pages and the dynamic registration of heterogeneous backend-specific pages include the following steps: S4.1 During the initialization of the unified front-end support mechanism, the corresponding ADMIN_LAYOUT layout mapping is read according to the current backendId; if a valid custom layout component identifier exists, the component is selected; otherwise, the default AdminLayout (management layout) is selected, forming a unique layout selection result associated with the current backendId. S4.2 Read the public capability route mapping based on the current backendId; use the custom path if a valid custom path exists, and use the default path if no path is configured and the default path is allowed; establish the public route set of the current heterogeneous backend based on the selected path, public capability identifier, and public component identifier, and associate it with the layout component selected in step S4.1; S4.3 Obtain the unified menu data, unified routing data, and functional availability results corresponding to the current access context; S4.4. Based on the capabilityId in the unified routing data, associate each unique service route with the corresponding functional availability result; S4.5 When enabled is true in the functionality availability result, the unified permission evaluator is used to determine whether the current user meets the access conditions based on permissionIds and permissionMatchMode (permission matching mode). When permissionMatchMode is ALL, all permissions are required to be valid; when ANY, at least one permission is required to be valid; NONE is only applicable to routes that explicitly do not require business permissions. When permissionIds is not empty and permissionMatchMode is the default, ALL is used. When the evaluation result is "no permission, access denied", no candidate is generated; when the result is "permission rule invalid", the candidate is marked as "permission rule invalid". S4.6 When both capability and permission conditions are met, extract path, name, parentRouteId, parentPath, componentId, capabilityId, menuId, and meta from the unified routing data to generate dynamic route candidates that have not yet been registered; the path, componentId, and capabilityId in the candidates are derived from the unified routing data, and the permissionIds are the intersection of the permissions allowed by the unified routing data and the functional availability results. S4.7 Establish parent-child relationships between candidates based on parentRouteId or parentPath, associate candidates with corresponding menu nodes, and associate candidates that need to be carried by the management interface with the layout component selected in step S4.1.

[0074] Parent routes are identified in the following order: if parentRouteId exists, a precise search is performed only within the current backendId and contextGeneration; if parentRouteId is empty and parentPath is not empty, a precise search is performed after path normalization of parentPath; if both are empty, only candidates with routeType of LAYOUT and configured as the root node of the current layout can be used as root routes; if parentRouteId and parentPath point to different parent routes, a parent reference conflict is recorded; if no route is found, multiple routes are found, the parent route does not belong to the current context or its capabilities are unavailable, records are recorded as parent route not found, parent route ambiguous, parent context mismatch, or parent route function limited, respectively, and such candidates must not be included in subsequent registration.

[0075] S4.8 Within the routing context defined by the current backendId and contextGeneration, perform normalized path, route name, and sub-path conflicts under the same parent route on public routes, static service routes, and dynamic route candidates. Candidates with unresolved conflicts are marked as unregisterable. Conflict checking uses the current backendId and contextGeneration as boundaries, prioritizing basic public routes, static service routes, and dynamic service routes in that order. For routes with the same priority, selection is based on decreasing priority. If priorities are the same but the substantive content differs, rejection is allowed and ROUTE_PRIORITY_TIE is recorded. If a dynamic candidate shares the same normalized path with a higher-priority route, path conflict is recorded. Deterministic renaming is allowed when only the name conflicts and normalized paths differ. Candidates are sorted in descending priority order and ascending normalized path and candidateId order. The first item retains the original name, and the remaining items use the format "original name__backendId__capabilityId". If conflicts still occur, a stable short digest is appended. If a unique name cannot be obtained, route name conflict is recorded and the route is rejected.

[0076] S4.9 Submit candidates without unresolved conflicts to the subsequent security registration process, and after successful registration, form a dynamic route set associated with the current backendId, userId, sessionId, and contextGeneration and carried by the selected layout component.

[0077] S5, Path Normalization Before registering dynamic route candidates, path normalization is performed to obtain a normalizedPath that does not contain query parameters and fragment identifiers, forming pathState and failureReason. This process applies to public routes, custom business routes, and parent path references, ensuring that conflict detection, permission association, and joint verification use the same normalized path.

[0078] The path normalization includes the following steps: S5.1 Verify that the backend identifier, user identifier, session identifier, and context generation of the dynamic route candidate are consistent with the current access context; S5.2 Determine whether the original path is a non-empty string, and verify the length of the original path and the preset path level limit; S5.3 Parse the original path and separate the original path, query parameters and fragment identifiers. If the original path contains external address information, the processing is deemed to have failed. S5.4, unify the format of forward slashes, repeating separators, current level identifiers, and starting root paths; S5.5 Validate the parent directory identifier, encoded characters, control characters, ordinary path fragments, dynamic parameters, and wildcards; S5.6 Generate a normalized path and verify its length, level, and conflicts with restricted paths; S5.7 Write the original path, normalized path, and processing result into the processing record, and only submit the candidates that pass the normalization to the subsequent verification.

[0079] In addition, path normalization performs the following checks in a fixed order, stopping if any one of them fails: Format and length validation: Parse the path and separate query parameters and fragment identifiers, reject external URLs and dangerous characters, validate length and hierarchy limits, and unify forward slashes and repeating delimiters.

[0080] Security checks: Decode path fragments, reject illegal encodings and path traversals, and only allow letters, numbers, hyphens, underscores, periods, and tildes as ordinary fragment characters; dynamic parameters and wildcards must conform to the preset format and must not be repeated.

[0081] Normalized output: Generates normalized paths and verifies that they do not conflict with restricted paths; only candidates that pass the verification are submitted to subsequent processes.

[0082] S6. Permission Association Verification For candidates that pass normalization, establish the association between the normalized path, capability identifier, permission identifier and permission access snapshot, verify that the snapshot version, context generation and access context are consistent, and call the unified permission evaluator to complete the permission association verification.

[0083] Specifically, permission association verification includes the following steps: S6.1 Receive pathState as standardized dynamic route candidates and their processing records; S6.2. Obtain the current access snapshot based on backendId, userId, and sessionId, and verify that the snapshot exists and is valid; S6.3 Verify that the backendId, userId, sessionId, contextGeneration, snapshotVersion, and matrixVersion in the snapshot are consistent with the candidate capabilityContextKey, and confirm that configSnapshotId is the configuration snapshot bound to the current access context; S6.4. Obtain the routing permission association record based on normalizedPath and capabilityId, and determine whether the permissionIds in the record are consistent with the candidate permission identifier or satisfy the inclusion relationship. S6.5 Call the unified permission evaluator to perform permission evaluation based on the current permission access snapshot, permissionIds, and permissionMatchMode, and obtain the result of permission being granted, no permission, or invalid permission rule, without changing the established role merging and empty permission interpretation; S6.6 When the access context and version are consistent, the associated record is valid, and the evaluation value is that the permission is allowed, set permissionState to VALIDATED; set it to DENIED when the rule is complete but the evaluation value is that the permission is not allowed; set it to INVALID when the snapshot is missing, the version is inconsistent, the association is invalid, or the rule is invalid, and record the unique reason for failure. S6.7 Only submit candidates with permissionState of VALIDATED to the component whitelist verification in step S7.

[0084] If a candidate lacks necessary permission fields, the permission matching method is uncertain, the snapshot is missing or expired, the session or version has changed, or the normalizedPath cannot be associated with permissions, the validity of permissions should not be presumed based on the existence of the menu, the existence of the component, or previous judgment results. LAYOUT type parent routes may not be directly associated with business operation permissions, but they are only retained if at least one child route passes the permission association verification. Page entry permissions are verified at this stage; page operation permissions (create, edit, delete, etc.) are still determined by the permission access snapshot during the specific operation.

[0085] S7, Component Whitelist Verification A unified front-end runtime support mechanism pre-establishes a controlled component registry, ensuring that heterogeneous backends can only reference registered components via componentId, and are prohibited from directly providing arbitrary file paths, import expressions, or module scan results automatically added to the registry. The controlled component registry is queried based on the component identifier, verifying that the component record is enabled and matches the current backend identifier and capability identifier.

[0086] The component whitelist verification includes the following steps: S7.1 Receive candidates whose permissionState is VALIDATED, and read componentId, capabilityId, and routeType; S7.2 Determine if componentId is empty and if it conforms to the identifier format; except for layout routes that allow the use of fixed layout components, if componentId is empty, it is considered a failure; S7.3. Query the component registry precisely based on componentId; failure is determined if no corresponding record is found. S7.4 Validate whether the enabled, backendScope, version, routeType, capabilityType, componentType, and authorizationMode recorded by the validation component belong to the allowed combinations; if any item is not satisfied, it is determined as a failure, and the corresponding failure reason is recorded; S7.5 Determine whether the candidate capabilityId belongs to the capabilityIds recorded by the component, and confirm that routeTypes contains the candidate routeType; S7.6 When all the above checks pass, set componentState to VALIDATED and write the componentLoader reference of the record to the processing record; when the check fails, set componentState to REJECTED or INVALID and record the unique reason for failure. S7.7 Only submit candidates with componentState of VALIDATED to subsequent joint validation.

[0087] The records in the component registry must contain at least the following: componentId, componentLoader, componentType, version, enabled, backendScope, capabilityIds, and routeTypes. The componentLoader can only come from a controlled lazy-loading function that uses a fixed import or literal path from the unified frontend; it cannot come from a file path returned by the backend or a dynamic import expression. The default AdminLayout and heterogeneous backend custom layouts must also pass registry validation and must satisfy the following conditions: componentType is LAYOUT, capabilityIds includes ADMIN_LAYOUT, and backendScope allows the current backendId.

[0088] Set a timeout when calling componentLoader; if loading times out, fails, has no default export, or the exported value cannot be recognized as a component, the corresponding candidate should not proceed to the next step. After a loading failure, do not retry using the backend file path, and do not write the component to the routing record.

[0089] S8, Joint Verification Consistency checks are performed on the path normalization, permission association verification, and component whitelist verification results of dynamic route candidates to confirm that each verification result corresponds to the same backend identifier, user identifier, session identifier, context generation, and dynamic route candidate. The overall matching of capabilityId, permissionIds, normalizedPath, componentId, and routeType is achieved through pre-published routing capability component association records. These association records are established by the configuration management entity during the configuration release phase based on the capability dictionary, ACTIVE component registry, backend adaptation mapping or public capability route mapping, and permission mapping. After path normalization, permission deduplication and sorting, and consistency checks of capabilities, components, backend scope, and route type, they are released with the configVersion (configuration version) and are not inferred temporarily from arbitrary backend fields at runtime.

[0090] Specifically, the joint verification includes the following steps: S8.1 Receive candidate and processing records with pathState set to NORMALIZED, permissionState set to VALIDATED, and componentState set to VALIDATED; S8.2 Query the heterogeneous backend capability matrix based on the current backendId to confirm that the capability record corresponding to the candidate capabilityId exists and enabled is true; S8.3 Re-verify the backendId, userId, sessionId, contextGeneration, snapshotVersion, matrixVersion, and configSnapshotId in the current permission access snapshot to ensure they are consistent with the capabilityContextKey and configuration snapshot used during the permission association phase; S8.4 Recalculate permissionIds and permissionMatchMode using the unified permission evaluator, and confirm that the permission identifier belongs to the permission scope of the target capabilityId; S8.5 Verify that the normalizedPath matches the route template, exact path, or pathPattern corresponding to the target capabilityId, and belongs to the routing context of the current backendId; S8.6 Verify that the componentId and the componentLoader obtained from the component whitelist verification come from the same component registration record, and confirm that the component is allowed to associate with the target capabilityId, normalizedPath and routeType; S8.7 Query the routing capability component associated records based on backendId, capabilityId, permissionIds, normalizedPath, componentId, and routeType, and confirm that the records exist, enabled is true, and configVersion belongs to the current configSnapshotId; If steps S8.8 and S8.2-S8.7 all pass the verification, set jointValidationState to VALIDATED and generate the joint validation result; if the field, enumeration, version or rule itself is invalid, set it to INVALID; if the associated record or admission policy does not allow it, set it to REJECTED and record a unique failureReason, and do not enter the dynamic route registration.

[0091] The matching of related records determines the unique highest priority record in the following order: First, records that are not enabled, have mismatched configuration versions, do not contain the current backendId in the backendScope, have mismatched capability / component / route types, do not meet permission set requirements, or have mismatched paths are excluded; then, records are compared item by item in the following order: precise range of backendId, exact match of normalizedPath, number of static fragments of pathPattern, exact equality of permissionIds, and priority. Candidates are rejected if no matching record is found; if multiple substantially identical records exist, the first one is selected; if multiple substantially different records exist, all conflicting records are rejected.

[0092] Candidates will only proceed to the subsequent dynamic route registration steps if the capability is valid, the permission evaluation is successful, the path is within the allowed range, the component and loader are controlled, the associated record is unique and the context is consistent with each version, jointValidationState is VALIDATED and componentLoaderRef exists.

[0093] S9, Dynamic Router Idempotent Registration For candidates that pass the joint verification, generate routing keys and registration keys; and manage the registration process through a registration state machine. In the same access context, repeated or concurrent requests reuse existing registration tasks, ensuring that the routing table is written only once for the same route.

[0094] Specifically, the dynamic route idempotent registration includes: S9.1 Receive the candidate that passed the joint verification, and confirm again that the backendId, userId, sessionId, contextGeneration, snapshotVersion, matrixVersion and configSnapshotId in the candidate have not changed; S9.2 Generate a routing key based on the normalized path, component identifier, capability identifier, and permission identifier of the dynamic route candidate; generate a registration key by overlaying the backend identifier, user identifier, session identifier, and context generation on the routing key; S9.2. Using the registration key as the key, maintain the route registration status within a single front-end running container. The registration status includes unregistered, registering, registered, failed, and removed. The state transition rules are as follows: the unregistered state or the failed state that meets the retry conditions is switched to the registering state, the registering state is then switched to the registered state or the failed state, and the registered state is switched to the removed state during the lifecycle cleanup. S9.3 The first request changes the status to "Registering" and performs route writing. Subsequent requests with the same key reuse the task and processing result of the first request. If the request is already registered, the existing result is returned directly without repeating the writing. Temporary failures are allowed to be retried, but retry is not performed in cases of path conflict or permission denial. S9.4 Parent and child routes generate corresponding keys respectively. The child route reuses the registration task of the parent route. When the parent route has been registered, the normalized path, route name, component loader, metadata and parent-child relationship are assembled into a route record. The parent route reuses its registration task when registering. If the parent route fails to register, the child route will not be written. Different front-end tabs maintain their registration status and route handles independently.

[0095] Furthermore, parent and child routes are registered according to their dependencies, with each child route under the same parent route generating its own routeKey and registrationKey. Synchronization placeholders, state changes, and registration task writing for registration records must be completed before the first asynchronous operation, ensuring that concurrent requests can share the same task and route handle.

[0096] Failure status will only automatically retry if the failure is due to temporary unavailability or write interruption, with the number of retries not exceeding a preset limit. Before each retry, the context generation, snapshot version, and joint verification status will be re-verified. Path conflicts, name conflicts, permission denials, unregistered components, and invalid configurations will not automatically retry. A removed status can only re-enter registration after passing joint verification again.

[0097] Idempotent registration is limited to a single browser tab or route instance within the front-end runtime container. Different tabs maintain their own registration records, route instances, and registration tasks; cross-tab broadcasts are only used to notify sessions, generations, or configuration changes and must not replace the actual registration of this tab with the registered status of other tabs.

[0098] S10, Static Service Routing Runtime Authorization For business page components and business routes that have been compiled, packaged, or initialized and registered with the unified front-end application, this invention establishes a static business route runtime permission control mechanism, so that whether a component exists in the front-end resources, whether a route exists in the front-end routing table, and whether a page has been loaded are not used as the basis for judging whether a user has access rights.

[0099] Static business routes refer to business routes that are written into the frontend routing configuration during the build phase or runtime initialization phase and can be recognized without dynamic addition based on user permissions. This differs from public basic routes that do not require business permissions, and also from dynamic routes that are generated and registered based on backend capabilities and user permissions. The pre-existence of static business routes only indicates that the unified frontend runtime support mechanism has the technical conditions to identify the target path and load the target component; it does not mean that the current backend has the target business capabilities, nor does it mean that the current user has access permissions.

[0100] The unified front-end operation support mechanism sets up an authorization interceptor at the front-end route navigation processing entry point. Located before the target business page is confirmed for activation, it is used to intercept static business route access requests initiated through menu clicks, address bar input, browser history navigation, programmatic navigation, route redirection, route aliases, and cache restoration. All access methods are converted into a unified route access request, and the authorization interceptor performs authorization verification, without omitting verification because the access request originates from an internal front-end menu or an already opened page.

[0101] For static business routes pre-configured in the front-end routing table, when a user accesses the static business route, runtime authorization verification is performed based on the current back-end capabilities, user permissions, and access snapshot. Access is then determined based on the verification result. Even if the static business route and its corresponding components already exist in the front-end, their pre-configured state is not used as the basis for determining whether the user has the corresponding access permissions, to avoid permission verification failing due to pre-configuration of static routes. Specifically, the runtime authorization verification includes the following steps: S10.1 Receive route access request, and read the backend identifier, user identifier and session identifier in the current access context before the target route is activated; refuse access if the record does not exist, is disabled or the authorization rules are incomplete; S10.2. Query the static business route authorization registration table based on the current backend identifier, normalized path, or route name to obtain the corresponding authorization record; S10.3 Determine whether the authorization record exists, whether it is enabled, and whether the authorization method can be determined; S10.4 Obtain the current access snapshot and record the context generation and snapshot version used in this verification; S10.5 When the authorization method requires capability judgment, query the capability matrix to confirm the corresponding capability and whether it is in the enabled state; S10.6 When the authorization method requires permission judgment, call the unified permission evaluator to perform permission verification; S10.7 Verify that the normalized path matches the path or path pattern in the authorization record; S10.8. Query the component registry based on the component identifier to confirm that the component record exists and is in an enabled state; S10.9. Route navigation is allowed when all conditions are met; the target component is not activated when any condition is not met.

[0102] The unified front-end operation support mechanism uses route access verification and operation permission review to control the scope of front-end pages and front-end interactions; when receiving business requests, heterogeneous back-ends can still independently perform interface permission judgment based on the corresponding user and session, and the front-end route authorization result is not used as a substitute for the automatic authorization of back-end business interfaces.

[0103] When access to a static business route is denied, hiding the menu is not the only solution. Even if the user accesses the target path by directly entering it in the address bar, through browser history, programmatic navigation, or route aliases, the runtime authorization interceptor will still perform the same authorization check.

[0104] S11, downgraded router as a backup To handle recoverable anomalies during dynamic route registration or component loading, this invention establishes a fallback routing mechanism. This mechanism maps the target route to a pre-configured fixed fallback page when the target service route has passed capability, permission, path, and joint verification, but component loading fails or recoverable route writing fails, and the backend capabilities, user permissions, and access context are still valid. This maintains a controllable consistency between menu nodes, route nodes, and the actual page response, and establishes a corresponding fallback route to ensure the accessibility of the target function in the event of a recoverable anomaly. For non-recoverable anomalies such as permission verification rejection, backend capability unavailability, or access context failure, fallback route mapping is not executed.

[0105] The fallback routing mechanism requires the pre-establishment of a fallback component registry and a fallback policy table. The fallback component record must include at least a fixed fallback component identifier, a fallback component loader, a fallback type, allowed route types, and its enabled status. The fallback component loader must originate from a unified frontend-controlled registry and must not use backend string paths or temporary component loaders. The fallback policy record must include at least a policy identifier, applicable exception reason codes, applicable processing stages, required preconditions, a fixed fallback component identifier, whether to retain the menu, whether to retain routes, retry mode, maximum number of retries, backend applicability, enabled status, and priority.

[0106] Exceptions that allow for degradation include component loading failure, recoverable route writing failure, and temporary page initialization failure; security exceptions such as permission denial, capability unavailability, invalid path, missing or expired snapshot, invalid context, unregistered component, invalid component association, and invalid authorization rules prohibit degradation.

[0107] Specifically, the fallback routing includes the following steps: S11.1 Receive abnormal events and corresponding candidates, registration records or runtime authorization records; S11.2. Based on the tracking identifier, backend identifier, user identifier, session identifier, and context, confirm that the exception belongs to the current valid context; S11.3. Based on the exception reason code (including reasonCode, stage, backendScope and priority), query the enabled matching strategy to confirm that the exception belongs to the set of exceptions that are allowed to be downgraded; S11.4. Confirm that the original route has met the prerequisites for path normalization and permission verification based on requiredPriorStates; if not, set REJECTED and record FALLBACK_PRECONDITION_NOT_MET. S11.5. Reconfirm that the target capabilityId is still provided by the current backendId, the unified permission evaluator still allows permissionIds, and contextGeneration, snapshotVersion, and matrixVersion are consistent with capabilityContextKey; if any of them are inconsistent, downgrade is refused and the original business entry is not retained. S11.6. Query the fallback component registry based on the fixed fallback component identifier, confirm that the record exists, enabled is true, fallbackType and allowedRouteTypes match, and obtain the controlled fallback component loader; S11.7 Generate a unique degradation registration identifier and establish a degradation route based on the backend identifier, user identifier, session identifier, context generation, routing key, normalized path, fixed degradation component identifier, and policy identifier; old degradation instances are not reused in different context generations; S11.8 When all conditions are met, set the degradation status to "in application" and establish or replace the corresponding degradation route; if the degradation route is successfully established, set the degradation status to "active"; if the establishment fails, set the degradation status to "failed".

[0108] S12, Lifecycle Reverse Cleanup For state cleanup in scenarios such as session failure, backend switching, user switching, permission snapshot revocation, and application reset, this invention establishes a lifecycle state list bound to the session and a reverse cleanup mechanism. When a session fails or a context switches, cleanup is performed according to the reverse dependency relationship of page, route, menu, and permission snapshot, and the results of asynchronous tasks in the old context are prohibited from being written to the new access context.

[0109] The lifecycle state list records the backendId, userId, sessionId, contextGeneration, and lifecycleState of the current access context, and maintains resource dependencies such as permission snapshot references, capability state references, menu node references, route registration key sets, downgrade registration key sets, page authorization context references, page cache references, and incomplete task references.

[0110] Specifically, lifecycle reverse cleanup includes the following steps: S12.1 Receive exit, session expiration or backend switch, snapshot revocation or application reset events, and locate the lifecycle state list; S12.2 Generate a cleanup identifier based on the lifecycle identifier and context generation, and set the lifecycle state to frozen through atomic state change; S12.3 Save the current context generation as an invalid generation, and add a generation or unbind the old session identifier from the current context generation; S12.4. Verify the lifecycle status and context generation at the write entry points for candidate generation, route registration, degradation establishment, and page activation. If the lifecycle is in an invalid generation or inactive, the write operation will be rejected. S12.5 Cancel unfinished tasks that can be canceled, mark the original generation of uncancellable tasks as invalid, discard the result of their completion callback, and do not write back to the routing, cache or permission status; S12.6 Terminate unfinished business navigation, remove the association between the activity page and the authorization context, and prohibit the old page from continuing to perform restricted operations; S12.7 Remove degraded routes, dynamic routes, menu nodes, capability status, access permission snapshots, and session bindings in reverse order of dependency; S12.8 After the resource is cleared, the lifecycle status is set to cleared and the termination or reconstruction process is initiated. For logout or session expiration, the old session binding is removed and the user is redirected to the not logged-in page. For backend switching or user switching, after the old lifecycle has been cleared, a new lifecycleId (lifecycle identifier) ​​and contextGeneration are created, and data transformation, permission snapshot creation, capability judgment and route creation are re-executed. The old snapshot, route, authorization context or cache is not reused.

[0111] Each asynchronous task compares backendId, userId, sessionId, and contextGeneration upon submission and completion. Even if an old generation task successfully returns after cleanup, it can only record audit events and cannot write back to the new context. A single cleanup failure does not prevent other independent steps from continuing. Dynamic parent routes can only be removed after their related child routes have been removed or marked for removal. Switching or rebuilding only occurs after the old lifecycle has reached a cleared state; if rebuilding fails, old permissions, menus, routes, and page caches are not restored.

[0112] Finally, to record and track the entire process of permission data conversion, permission snapshot creation, joint judgment of capabilities and permissions, route candidate generation, dynamic route registration, runtime authorization, exception degradation, and session cleanup, this invention establishes a structured lifecycle audit mechanism. This audit mechanism generates structured audit events at the start, end, pass, reject, fail, or state transition of each critical processing stage. Each audit event includes at least an event identifier, a tracking identifier, an event sequence number, a processing stage, an event type, a processing result, and an occurrence time. Events within the same processing chain are linked by tracking identifiers and arranged by event sequence number to form a complete lifecycle event sequence.

[0113] The audit event handling phase includes at least the following stages: heterogeneous data adaptation, permission snapshot creation or update, capability and permission joint judgment, route candidate generation, path normalization, permission association verification, component whitelist verification, joint verification, route registration, runtime authorization, degraded route processing, and lifecycle cleanup.

[0114] The auditing mechanism records the corresponding event type and structured reason code for each of the following results: successful processing, permission denial, capability unavailability, invalid rules, abnormal component loading, registration failure, state reuse, application degradation or denial, and resource removal and cleanup completion. Audit events are written to a separate storage area, and the success or failure of the audit write does not change the business verification, routing registration, or authorization results.

[0115] Audit logs are retained in the audit store when a session expires or a context switch occurs, and can be used for subsequent tracing queries. However, old routing keys, registration keys, or snapshot versions contained therein must not be used to restore the old running state.

[0116] like Figure 3 As shown below, taking user U100 accessing the parameter management list in Backend-A as an example, this illustrates the participating entities and interaction order of permission loading and route registration, as well as the continuous processing from heterogeneous raw data input to the end of the lifecycle. The Backend-A adapter receives the raw capability record {id:"pm", code:"PARAMETER_MANAGEMENT",type:"module",enabled:1}, the raw permission record {id:"p-view",code:"parameter:view",resource:" / parameter / list"}, the menu record {id:"m-param", parentId:"m-admin",title:"Parameter Management", path:" / parameter"}, and the page configuration {pageId:"parameter-list",componentId:"ParameterList", path:" / list"}. The adaptation layer outputs a unified capability record {backendId:"Backend-A", capabilityId:"cap.parameter", capabilityType:"BUSINESS", enabled:true, matrixVersion:"A-M7"}, a unified permission record {permissionId:"p-view", permissionType:"PAGE", normalizedPath:" / parameter / list"}, a unified menu node {menuNodeId:"m-param", capabilityId:"cap.parameter", routeCandidateRef:"rc-001"}, and a component configuration reference {componentId:"ParameterList", componentType:"BUSINESS_PAGE", loaderRef:"loader.parameter.list"}. The specific registration method includes the following steps: Step 1: The adaptation layer generates a configSnapshotId:"cfg-A-18" for this login and establishes a permission access snapshot {backendId:"Backend-A",userId:"U100",sessionId:"S900",snapshotVersion:"A-S12",contextGeneration:41,permissionIds:["p-view"],createdAt:t1} based on it; users who lack p-view will not proceed to the subsequent page authorization steps.

[0117] Step 2: The unified permission evaluator reads the capability matrix matrixVersion: "A-M7", obtains capabilityState: {capabilityId: "cap.parameter", state: "AVAILABLE", reasonCode: null}, and binds the result to this time with capabilityContextKey: "Backend-A|U100|S900|41|A-S12|A-M7|cap.parameter".

[0118] Step 3: Menu and Route Candidate Generation. Generate a route candidate: routeCandidate:{routeCandidateId:"rc-001", routeOwnerType:"DYNAMIC", routeType:"PAGE", rawPath:" / parameter / list", arentPath:" / parameter", componentId:"ParameterList", capabilityId:"cap.parameter", errorIds:["p-view"], menuNodeId:"m-param", contextGeneration:41}. After path normalization, obtain normalizedPath:" / parameter / list", name:"backendA.parameter.list", and form registrationKey:"Backend-A|41| / parameter / list|ParameterList|cap.parameter|p-view" using route-v1 normalized payload.

[0119] Step 4: The component registry query finds componentId: "ParameterList" with componentType: "BUSINESS_PAGE", enabled: true, and loaderRef: "loader.parameter.list". Joint verification confirms that routeType, capabilityType, componentType, and authorizationMode are allowed combinations, and the component is allowed to be associated with cap.parameter. The runtime authorization record is written to {staticRouteId:"sr-parameter-list", authorizationResult:"ALLOW", pagePermissionIds:["p-view"], snapshotVersion:"A-S12", matrixVersion:"A-M7", contextGeneration:41}.

[0120] Step 5: The dynamic registration record is first synchronized as a placeholder {registrationKey:..., state:"REGISTERING", registerTask:task-77, contextGeneration:41}. Then, only task-77 calls router.addRoute and returns routeHandle:"rh-77", changing the record to {state:"REGISTERED", routeHandle:"rh-77", failureReason:null}. The menu node references this registrationKey, and the page authorization context references sr-parameter-list.

[0121] Step 6: The user navigates to / parameter / list. After the component loads asynchronously, a comparison of Backend-A, U100, S900, 41, A-S12, and A-M7 shows no changes. The page then enters ACTIVE mode, and the page cache record is {pageCacheRef:"cache-parameter-U100-41", contextGeneration:41}. When the user performs a view operation, the operation permission parameter:view passes the review, and the business request is allowed.

[0122] Step 7: If component loading fails due to network timeout, the registration record is written to FAILED and failureReason: "COMPONENT_LOAD_TIMEOUT". When the reason belongs to the recoverable set and the capabilities, permissions, and context are still valid, a fixed RouteFallback route is created by pressing fallbackRegistrationKey. The menu still references the original routeCandidate, and the downgraded state is ACTIVE. After the original component is restored, a recovery is performed once by pressing retryMode. If successful, RECOVERED is written and the original routeHandle is restored. If permissions are revoked or the component is not registered, no downgraded route is created, and PERMISSION_REVOKED or COMPONENT_NOT_REGISTERED is returned respectively.

[0123] Step 8: When a user logs out or switches backends, generate a cleanupId with lifecycleId and contextGeneration:41 and invalidate the generation. Then, sequentially clean up the page authorization context and cache, downgraded routes, dynamic child routes, dynamic parent routes, component tasks, menus, capability results, permission snapshots, and session bindings. Each result is written to removedResources or failedResources. After cleanup, the old lifecycle is set to CLEARED, and its asynchronous callbacks, even if late, must not be written back to the new route or cache.

[0124] 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.

Claims

1. A method for heterogeneous permission data conversion, dynamic routing security registration, and fallback mechanism, characterized in that, Includes the following steps: S1. Heterogeneous Data Adaptation: A heterogeneous data adaptation layer is set up between heterogeneous backend services and a unified frontend operation support mechanism. The unified frontend operation support mechanism provides at least unified permission processing, capability management, dynamic routing management, controlled component registration, operation status management, and lifecycle cleanup functions. The heterogeneous data adaptation layer contains multiple adaptation instances registered according to backend identifiers. The heterogeneous data adaptation layer selects an adaptation instance through the current backend identifier, obtains the original data of the current backend, and converts the original data into a unified data model. The original data includes user, role, department, menu, resource, permission, route, capability, and layout data. S2. Establish a unified permission model: Build a unified permission model based on a unified data model, and create permission access snapshots based on the current backend identifier, user identifier, and session identifier; the permission access snapshot should at least include the context generation, snapshot version, and configuration snapshot identifier, which will serve as a unified basis for menu display, route generation, capability judgment, and authorization verification. S3. Establish a unified capability model: Based on the unified permission model, build a unified capability model, assign a unique capability identifier to each capability, and divide the front-end functions into public capabilities, business-specific capabilities, and extended capabilities; for business-specific capabilities, establish a heterogeneous back-end capability matrix, using the back-end identifier and capability identifier as matrix dimensions, and record whether each back-end provides each business-specific capability. S4. Dynamic route candidate generation: Obtain the functional availability result based on the heterogeneous backend capability matrix, and associate the business route with the functional availability result; for business routes where the capability is available and the current user meets the corresponding access permission conditions, extract the path, component identifier, capability identifier and menu identifier from the unified routing data to generate dynamic route candidates; S5. Path Normalization: Normalize the paths of dynamic route candidates, separate the path from the additional information, unify the path format, and generate normalized paths; candidates that have not been normalized are prohibited from entering subsequent verification. S6. Permission association verification: For candidates that pass normalization, establish the association between the normalized path, capability identifier, permission identifier and permission access snapshot, verify that the snapshot version and context generation are consistent with the access context, and call the unified permission evaluator to complete the permission association verification. S7. Component whitelist verification: Query the controlled component registry based on the component identifier, and verify that the component record is enabled and matches the current backend identifier and capability identifier; S8. Joint verification: Confirm that the verification results of steps S5-S6 belong to the same backend identifier, user identifier, session identifier, context generation and dynamic route candidate. Query the capability matrix and related records and confirm that the capabilities, permissions and component associations corresponding to the dynamic route candidates are in a valid state. S9. Dynamic route idempotent registration: Generates route keys and registration keys for candidates that pass joint verification; manages the registration process through a registration state machine, reuses existing registration tasks for repeated or concurrent requests in the same access context, and ensures that the route table is written only once for the same route. S10. Runtime authorization for static business routes: For static business routes that have been pre-existing in the front-end routing table, when a user accesses the route, runtime authorization verification is performed based on the current back-end capabilities, user permissions, and access snapshot, and the verification result is used to determine whether access is allowed. S11, Fallback Route: When the target route fails to load a component or fails to recover a write operation, and the current capabilities, user permissions, and context are still valid, the target route will be mapped to a pre-configured fixed fallback component and a fallback route will be established; fallback route mapping will not be executed in case of exceptions such as permission denial, unavailable backend capabilities, or invalid access context. S12, Lifecycle Reverse Cleanup: Establish a lifecycle state list bound to the session, recording the dependencies of permission snapshots, capability states, menu nodes, and route registrations; when a session expires or a context switches, perform cleanup according to the reverse dependency of page, route, menu, and permission snapshots, and prohibit the asynchronous task results of the old context from being written to the new access context.

2. The heterogeneous permission data conversion and dynamic routing security registration and fallback method as described in claim 1, characterized in that: In step S1, the adaptation instance adopts the following conversion rules: The backend identifier is fixedly written by the currently selected adaptation instance and is not inferred from user data, path or other business fields; Between users and roles, menus and routes, routes and permissions, and routes and capabilities, only full-value equality connections are performed based on the original identifier; Original permissions, capabilities, components, and route types are only transformed using precise mapping items pre-registered under the current backend identifier; if no mapping item exists, the data mapping is recorded as not found. If the parsing process identifies duplicate identifiers, it records the identifier conflict. If it finds that a referenced record is missing, it records the missing relationship and stops forming the corresponding unified record. Boolean values, root node values, and null values ​​on each backend are converted according to their own parsing rules, and parsing conversion logic is not mixed between different backends.

3. The heterogeneous permission data conversion and dynamic routing security registration and fallback method as described in claim 1, characterized in that: In step S3, the distinction between public capabilities and business-specific capabilities includes: Obtain the set of functions to be provided by the unified front end, and determine the business meaning, page, component and operation scope of each function; Functions that share common basic semantics across all heterogeneous backends, can reuse unified pages or layout components, and whose backend differences can be eliminated through adaptation rules will be identified as common capabilities, and a unified common capability identifier will be set for these common capabilities. Functions provided by a single or partial heterogeneous backend and whose business implementation depends on the corresponding heterogeneous backend are defined as business-specific capabilities, and a unified business capability identifier is configured.

4. The heterogeneous permission data conversion and dynamic routing security registration and fallback method as described in claim 1 or 3, characterized in that: In step S3, constructing the unified capability model includes the following steps: S3.1 Define the capability identifier, capability name, and capability type for public capabilities, business-specific capabilities, and extended capabilities; S3.

2. Associate common capabilities with unified front-end pages, components, and optional default paths; S3.

3. Through the heterogeneous data adaptation layer, the original capabilities representing the same business meaning in different backends are mapped to the same capability identifier; S3.4 Associate capability records with unified routing data through capability identifiers, and retain backend custom paths; S3.5 Output a unified capability record for use in capability matrix creation and joint capability permission judgment.

5. The method for heterogeneous permission data conversion, dynamic routing security registration, and fallback as described in claim 1, characterized in that: In step S5, the normalization process includes the following steps: S5.1 Verify that the backend identifier, user identifier, session identifier, and context generation of the dynamic route candidate are consistent with the current access context; S5.2 Determine whether the original path is a non-empty string, and verify the length of the original path and the preset path level limit; S5.3 Parse the original path and separate the original path, query parameters and fragment identifiers. If the original path contains external address information, the processing is deemed to have failed. S5.4, unify the format of forward slashes, repeating separators, current level identifiers, and starting root paths; S5.5 Validate the parent directory identifier, encoded characters, control characters, ordinary path fragments, dynamic parameters, and wildcards; S5.6 Generate a normalized path and verify its length, level, and conflicts with restricted paths; S5.7 Write the original path, normalized path, and processing result into the processing record, and only submit the candidates that pass the normalization to the subsequent verification.

6. The method for heterogeneous permission data conversion, dynamic routing security registration, and fallback as described in claim 1, characterized in that: During the verification process in step S7, a controlled component registry is pre-configured. The controlled component registry stores the component identifier, the corresponding component loader, the applicable scope of the backend, and the associated capability identifier. Heterogeneous backends are only allowed to output the component identifier and are prohibited from directly outputting the frontend component file path. During verification, the controlled component registry is precisely searched according to the component identifier of the dynamic route candidate. The system checks whether the component record is in the enabled state, whether the component adapts to the current backend identifier, and whether the component's associated capability identifier matches the capability identifier of the dynamic route candidate. If any verification condition is not met, the dynamic route candidate is rejected and allowed to proceed to the next processing step.

7. The method for heterogeneous permission data conversion, dynamic routing security registration, and fallback as described in claim 1, characterized in that: In step S9, the dynamic route idempotent registration includes: S9.1 Generate a routing key based on the normalized path, component identifier, capability identifier, and permission identifier of the dynamic route candidate; generate a registration key by overlaying the backend identifier, user identifier, session identifier, and context generation on the routing key; S9.

2. The registration status is maintained using the registration key as the key. The registration status includes unregistered, registering, registered, failed, and removed. The status transition rule is as follows: the unregistered status or the failed status that meets the retry conditions is switched to the registering status. The registering status is then switched to the registered status or the failed status. The registered status is switched to the removed status during the lifecycle cleanup. S9.3 The first request changes the status to "Registering" and performs route writing. Subsequent requests with the same key reuse the task and processing result of the first request. If the request is already registered, the existing result is returned directly without repeating the writing. Temporary failures are allowed to be retried, but retry is not performed in cases of path conflict or permission denial. S9.4 Parent and child routes generate corresponding keys respectively. The child route reuses the registration task of the parent route. If the parent route fails to register, the child route will not write the key. Different front-end tabs maintain their registration status and route handles independently.

8. The method for heterogeneous permission data conversion, dynamic routing security registration, and fallback as described in claim 1, characterized in that: In step S10, the runtime authorization verification includes the following steps: S10.1 Receive route access request, and read the backend identifier, user identifier and session identifier in the current access context before the target route is activated; S10.

2. Query the static business route authorization registration table based on the current backend identifier, normalized path, or route name to obtain the corresponding authorization record; S10.3 Determine whether the authorization record exists, whether it is enabled, and whether the authorization method can be determined; S10.4 Obtain the current access snapshot and record the context generation and snapshot version used in this verification; S10.5 When the authorization method requires capability judgment, query the capability matrix to confirm the corresponding capability and whether it is in the enabled state; S10.6 When the authorization method requires permission judgment, call the unified permission evaluator to perform permission verification; S10.7 Verify that the normalized path matches the path or path pattern in the authorization record; S10.

8. Query the component registry based on the component identifier to confirm that the component record exists and is in an enabled state; S10.

9. Route navigation is allowed when all conditions are met; the target component is not activated when any condition is not met.

9. The method for heterogeneous permission data conversion, dynamic routing security registration, and fallback as described in claim 1, characterized in that: In step S11, the fallback route specifically includes the following steps: S11.1 Receive abnormal events and corresponding candidates, registration records or runtime authorization records; S11.

2. Based on the tracking identifier, backend identifier, user identifier, session identifier, and context, confirm that the exception belongs to the current valid context; S11.

3. Based on the exception cause code, query the enabled matching strategy to confirm that the exception belongs to the set of exceptions that are allowed to be downgraded; S11.4 Confirm that the original route has met the prerequisites of path normalization and permission verification; S11.5 Confirm that the target capability identifier is still provided by the current backend identifier and that permission evaluation is still allowed; S11.

6. Query the downgrade component registry based on the fixed downgrade component identifier and obtain the controlled downgrade component loader; S11.7 Generate a unique identifier for the downgraded registration and establish a downgraded route; S11.8 If the downgraded route is successfully established, the downgraded status will be set to active; if the establishment fails, the downgraded status will be set to failed.

10. The method for heterogeneous permission data conversion, dynamic routing security registration, and fallback as described in claim 1, characterized in that: In step S12, the lifecycle reverse cleanup includes the following steps: S12.1 Receive exit, session expiration or backend switch, snapshot revocation or application reset events, and locate the lifecycle state list; S12.2 Generate a cleanup flag based on the lifecycle flag and context generation, and set the lifecycle state to frozen through atomic state change; S12.3 Save the current context generation as an invalid generation, and add a generation or unbind the old session identifier from the current context generation; S12.

4. Verify the lifecycle status and context generation at the write entry points for candidate generation, route registration, degradation establishment, and page activation. If the lifecycle is in an invalid generation or inactive, the write operation will be rejected. S12.5 Cancel unfinished tasks that can be canceled, and mark non-cancellable tasks as invalid in their original generation; S12.6 Terminate unfinished business navigation, remove the association between the activity page and the authorization context, and prohibit the old page from continuing to perform restricted operations; S12.7 Remove degraded routes, dynamic routes, menu nodes, capability status, access permission snapshots, and session bindings in reverse order of dependency; S12.8 After the resource is cleared, set its lifecycle status to cleared.

Images