Control method based on micro-front-end frame

Abstract

The invention discloses a control method based on a micro-front-end framework, relates to the technical field of computers, and effectively solves the problem of session collaboration between a main application client and a plurality of sub-application clients under the micro-front-end framework by establishing a main application server unified authentication and session management mechanism. Specifically, according to the scheme, after a main application server completes user identity verification, a globally unique first session identifier containing a user identifier, public permission data and a validity period is generated based on a preset mapping relation between a global role and a sub-application list, and the globally unique first session identifier is synchronized to a main application client and each sub-application client; seamless transmission and consistent maintenance of the session state among the sub-application clients after single sign-on are realized, the problem of repeated sign-on during switching of the sub-application clients or switching of the main application client and the sub-application clients is fundamentally avoided, and operation continuity and user experience are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a control method based on a micro-frontend framework. Background Technology

[0002] As web applications continue to grow in scale, the drawbacks of the traditional monolithic client development model have become increasingly apparent. For example, the codebase of a large enterprise application has reached millions of lines, leading to extended development cycles for new features and high maintenance costs. Simultaneously, enterprise application business requirements are becoming increasingly complex, with frequent cross-team collaborations, making it difficult for monolithic client architectures to meet the needs of multi-business applications and cross-team development. Inspired by server-side microservice architecture, micro-frontend architecture has emerged. It breaks down client applications into multiple micro-applications that can be independently developed, tested, and deployed, effectively improving development efficiency, enhancing maintainability and scalability, allowing different micro-applications to use different technology stacks, and adapting to complex business and team collaboration needs.

[0003] The client application is broken down into multiple independently developable, testable, and deployable micro-applications, including a main application client and multiple sub-application clients. The main application client serves as the "container" or "base" of the entire micro-frontend system, acting as the user's entry point. Its core responsibilities include registering sub-applications, managing routing and distribution, and handling communication between sub-applications—all part of the overall coordination. Sub-application clients are independently developed and built frontend applications, carrying specific business functions, possessing independent operational capabilities, and featuring flexible technology stacks.

[0004] In a micro-frontend architecture, traditional session management methods struggle to achieve seamless integration between the main application client and sub-application clients. This can lead to users experiencing repeated logins when switching from the main application client to a sub-application client, or between sub-application clients, severely impacting the user experience. Summary of the Invention

[0005] In view of the above problems, this application provides a control method based on a micro-frontend framework to achieve the goal of switching between the main application client and sub-application clients, or between various sub-application clients, without repeated logins. The specific solution is as follows:

[0006] The first aspect of this application provides a control method based on a micro-frontend framework, including:

[0007] The main application client sends login information to the main application server, and the login information includes a user identifier;

[0008] If the login information is verified, the main application server searches for the target sub-application list corresponding to the target global role of the user identifier from the preset correspondence between global roles and sub-application lists. The target sub-application list includes the target sub-application identifier of the target sub-application client.

[0009] The main application server generates a globally unique first session identifier based on the user identifier, public permission data, and the first validity period of the first session identifier. The public permission data includes the target global role and the target sub-application list.

[0010] The main application server sends a login success message, the first session identifier, and the public permission data to the main application client.

[0011] The main application client stores the first session identifier in the global storage space;

[0012] The main application client loads the target sub-application client; and sends the target global role, the first session identifier, and the first validity period broadcast to the target sub-application client.

[0013] The target sub-application client stores the target global role, the first session identifier, and the first validity period in its own session cache;

[0014] The main application client controls and displays the sub-application entry of the target sub-application client.

[0015] By employing the aforementioned technical solutions, this application provides a control method based on a micro-frontend framework. By establishing a unified authentication and session management mechanism on the main application server, it effectively solves the session collaboration problem between the main application client and multiple sub-application clients in a micro-frontend architecture. Specifically, after completing user authentication on the main application server, this application generates a globally unique first session identifier containing user identification, public permission data, and validity period based on a preset global role-to-sub-application list mapping relationship. This identifier is then synchronized to the main application client and each sub-application client, achieving seamless transfer and consistent maintenance of session state across all sub-application clients after single sign-on. This fundamentally avoids the problem of repeated logins when switching between sub-application clients or between the main application client and sub-application clients, significantly improving operational continuity and user experience. Simultaneously, this application manages the lifecycle of the first session identifier and the access permissions of sub-application clients uniformly through the main application client. This retains the technical flexibility of independent development and deployment of sub-application clients under the micro-frontend architecture while establishing globally unified access control. This makes permission configuration more efficient and standardized in cross-team collaboration, reduces the maintenance cost of multi-application client systems, and fully leverages the scalability advantages of the micro-frontend architecture in complex business scenarios. Attached Figure Description

[0016] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0017] Figure 1 A schematic diagram of a system architecture is provided for this application;

[0018] Figure 2 A flowchart illustrating a control method based on a micro-frontend framework provided in an embodiment of this application;

[0019] Figure 3 A flowchart illustrating an implementation method for synchronizing session state and public permission data between the main application client and the sub-application client, as provided in an embodiment of this application.

[0020] Figure 4 A flowchart illustrating an implementation method for synchronizing session state and public permission data between the main application client and the sub-application client, as provided in an embodiment of this application.

[0021] Figure 5 A flowchart illustrating an implementation method for synchronizing session state and public permission data between the main application client and the sub-application client, as provided in an embodiment of this application.

[0022] Figure 6 A flowchart illustrating an implementation method for synchronizing session state and public permission data between the main application client and the sub-application client, as provided in an embodiment of this application.

[0023] Figure 7 A flowchart illustrating an implementation method for synchronizing session state and public permission data between the main application client and the sub-application client, as provided in an embodiment of this application.

[0024] Figure 8 A schematic diagram illustrating one implementation method of the main application server's verification of access permissions to the sub-application client provided for the implementation of this application;

[0025] Figure 9 This is a schematic diagram illustrating one implementation of authentication for the sub-application client and sub-application server provided in the embodiments of this application. Detailed Implementation

[0026] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0027] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0028] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0029] As web applications continue to grow in scale, the drawbacks of the traditional monolithic client development model have become increasingly apparent. For example, the codebase of a large enterprise application has reached millions of lines, leading to extended development cycles for new features and high maintenance costs. Simultaneously, enterprise application business requirements are becoming increasingly complex, with frequent cross-team collaborations, making it difficult for monolithic client architectures to meet the needs of multi-business applications and cross-team development. Inspired by server-side microservice architecture, micro-frontend architecture has emerged. It breaks down client applications into multiple micro-applications that can be independently developed, tested, and deployed, effectively improving development efficiency, enhancing maintainability and scalability, allowing different micro-applications to use different technology stacks, and adapting to complex business and team collaboration needs.

[0030] The following describes the various terms used in the embodiments of this application.

[0031] Micro-frontend: This refers to a front-end architecture design concept. Its core is to break down a complex, large client application into multiple independently developed, deployed, and technology-stack-independent "small front-end applications (sub-applications)," which are then integrated and run through a "main application." Its goal is to address the complexity, team collaboration efficiency, and technology stack limitations of large client applications.

[0032] Main application client: The "container" or "base" of the entire micro-frontend system. It is the application entry point for users and its core responsibilities include registering sub-applications, managing routing and distribution, and handling communication between sub-applications, among other overall coordination tasks.

[0033] Sub-application client: An independently developed and built front-end application that carries specific business functions, has independent operating capabilities, and a flexible technology stack.

[0034] Session ID: A lightweight credential used for authentication, authorization, or information transmission. It is usually in the form of a string and is generated by the server and issued to the client (such as a browser or app). Its core function is to replace the "traditional account and password verification". While ensuring security, it simplifies the interaction process between the client and the server and is widely used in web applications, mobile applications, API interfaces and other scenarios.

[0035] Application Access Control List (ACL): In a micro-frontend architecture, an application-level ACL is a set of rules used to manage the access permissions of users or roles to various sub-applications. Its core function is to clarify "who can access which sub-application client", and it is a key mechanism for realizing the isolation and fine-grained control of sub-application client permissions.

[0036] Permission granularity: This is a core term in permission management systems that describes the fineness of permission control. It refers to the level of detail in permission division. Finer granularity results in more precise permission control, down to specific operations or data; coarser granularity results in broader permission control, covering only major functionalities or modules. Permission granularity is closely related to application flexibility, security, and management costs, making it a key decision point in permission design. In independent permission control implementations, sub-application clients can define different permission granularities according to business needs, without being restricted by other applications.

[0037] Application isolation: In a micro-frontend architecture, this refers to a mechanism that uses technical means to ensure that sub-application clients do not interfere with the main application client or other sub-application clients during runtime. In independent access control, application isolation guarantees the independence of permission rules for sub-application clients, avoiding permission logic conflicts.

[0038] In micro-frontend architectures, session management methods in related technologies struggle to achieve seamless integration between the main application client and sub-application clients. Different sub-application clients maintain their own session states, leading to inconsistent session states or duplicate logins when users switch between the main application client and sub-application clients, or between sub-application clients, severely impacting user experience. For example, users must log in again to obtain the independent session states of each sub-application client when navigating from the main application client, resulting in a fragmented user experience.

[0039] Based on this, this application achieves "seamless integration of multiple sub-application clients," allowing users to switch between the main application client and sub-application clients without repeatedly logging in, while maintaining consistent session state. Among the aforementioned technologies, "unified session management" is particularly crucial, as it ensures the continuity and consistency of the entire application system.

[0040] Session state refers to a set of global contextual information generated by the main application client after a user successfully logs in, which identifies the user's continuously valid login identity throughout the entire micro-frontend system (main application + all sub-applications). For example, session state includes a global session identifier and validity period.

[0041] It is understandable that the functions and business logic of each sub-application client are independent. Different sub-application clients may have different business scenarios and permission requirements. For example, in sub-application client one, the user may have administrator privileges, while in sub-application client two, the user may only have visitor privileges. Furthermore, different teams may be responsible for developing different sub-application clients, and during development, they may independently define permission rules and authentication logic based on their own business needs and development habits. For example, in a large enterprise's R&D collaboration management platform, the main application client is responsible for basic functions such as global user login, system settings, and notifications / to-do lists, while each sub-application client may correspond to different business modules such as requirements, testing, and R&D management. Due to differences in business rules and security requirements, each business module requires an independent permission control mechanism. However, due to the decoupling between the main application client and sub-application clients, the diversity of technology stacks, and the complexity of security boundaries, the micro-frontend architecture in related technologies faces many challenges when handling this scenario of unified session management and independent permission control. These challenges can be summarized into the following two major issues:

[0042] Problem 1: Facing the challenge of bidirectional interaction across session lifecycles: Unified session management requires that the session states of the main application client and sub-application clients remain consistent, including login, expiration, and logout. For example, if a main application client session expires due to timeout / voluntary logout, all sub-application clients must be forced to log out immediately, and the session identifier cannot be authenticated by any sub-application client's server. Another challenge is the difference in session storage across technology stacks: Sub-application clients may be based on different front-end technology stacks, and their session storage methods may differ. The characteristics of different storage mechanisms (such as cross-domain policies) can lead to difficulties in synchronizing session states.

[0043] Question 2: Facing the challenge of adapting to heterogeneous authorization models: The permission systems of different sub-application clients may be based on different permission models, and the granularity of permissions may also vary greatly. The unified framework needs to be compatible with heterogeneous authorization models while avoiding intrusion into the permission logic of sub-application clients. It also needs to handle the complexity of the mapping between the user system and the permission system. Although the user system is consistent, the permissions of the same user in different sub-application clients may be completely independent. This many-to-many mapping of "user-permission" needs to be associated in a unified session. Storing mapping information in the main application client will require synchronous updates to the main application client when sub-application client permissions change, increasing coupling and making it impossible to handle scenarios such as real-time changes in sub-application client permissions, such as temporary authorization or timed revocation, potentially leading to sub-application clients using expired permissions.

[0044] This application addresses the aforementioned issues from the following aspects: it implements globally unique session identifier authentication through a unified authentication module; it achieves global unification of login status and session lifecycle through a session management module; and it addresses session validity synchronization issues in various scenarios such as session expiration and invalidation. It solves the challenges of heterogeneous adaptation of permission models and data isolation through a permission data storage module; and it resolves permission dependency and verification collaboration issues through an independent permission control module.

[0045] The technical solutions involved in this application are described below.

[0046] See Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100 and a server 200. The server 200 can provide the methods provided in the embodiments of this application to one or more terminals.

[0047] The terminal 100 may have an application installed on it. The application and webpage can provide an interface. The terminal 100 can receive relevant parameters entered by the user on the interface, such as login information, and send the parameters to the server 200. The server 200 can obtain the processing result based on the received parameters and return the processing result to the terminal 100.

[0048] For example, the applications installed on terminal 100 include a main application client and one or more sub-application clients.

[0049] For example, server 200 has a main application server corresponding to the main application client and a sub-application server corresponding to each sub-application client.

[0050] For example, the main application server includes: a unified authentication module, a permission data storage module, a session management module, and a permission control module; the sub-application server includes: a unified authentication module, a permission data storage module, a session management module, and a permission control module.

[0051] For example, the main application client includes: a permission control module and a permission data storage module.

[0052] For example, the sub-application client includes: a permission control module and a permission data storage module.

[0053] The unified authentication module is used to implement login verification and unified session verification; the session management module is used to implement session state synchronization throughout its entire lifecycle; the independent access control module is used to implement authorization and authentication between the main application client and each sub-application client; the access data storage module is used to implement independent storage management of access data; and the communication module is used to implement communication between the main application client and each sub-application client, as well as within each sub-application client.

[0054] The following description Figure 1 The product form of the mid-terminal 100;

[0055] The terminal 100 in this application embodiment can be a mobile phone, tablet computer, wearable device, vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0056] Terminal 100 may include a radio frequency unit, memory, input unit, display unit, camera (optional), audio circuitry (optional), speaker (optional), microphone (optional), headphone jack (optional), processor, external interface, power supply, and other components. Those skilled in the art will understand that the above-mentioned components are merely examples and do not constitute a limitation on the terminal or multifunctional device; it may include more or fewer components, or a combination of certain components, or different components.

[0057] The input unit can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the portable multi-functional device. Specifically, the input unit may include a touchscreen (optional) and / or other input devices. Other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0058] Among them, the input device can receive input data, etc.

[0059] The display unit can be used to display information input by the user or information provided to the user, various menus of the terminal, interactive interfaces, file display, and / or playback of any multimedia file. In the embodiments of this application, the display unit can be used to display interfaces, processing results, etc.

[0060] This radio frequency unit (optional) can be used to receive and send signals during information transmission or calls.

[0061] In this embodiment of the application, the radio frequency unit can send data to the server 200 and receive the processing results sent by the server 200.

[0062] It should be understood that this radio frequency unit is optional and can be replaced with other communication interfaces, such as a network port.

[0063] Terminal 100 also includes a power source (such as a battery) for supplying power to the various components.

[0064] Terminal 100 also includes an external interface, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.

[0065] Server 200 includes a bus, a processor, a communication interface, and memory. The processor, memory, and communication interface communicate with each other via the bus.

[0066] It is understandable that terminal 100 and server 200 communicate with each other through a communication module.

[0067] Reference Figure 2 , Figure 2 A flowchart illustrating a control method based on a micro-frontend framework provided in this application embodiment is shown below. Figure 2 As shown in the figure, the control method based on the micro front-end framework provided in this application embodiment may include steps S201 to S208, which are described in detail below.

[0068] Step S201: The main application client sends login information to the main application server, and the login information includes the user identifier.

[0069] For example, login information includes username and password.

[0070] For example, the main application client displays a login interface where the user enters their username and password. For example, the main application client encrypts the login information and sends it to the unified authentication module on the main application server.

[0071] Step S202: If the login information is verified, the main application server searches for the target sub-application list corresponding to the target global role of the user identifier from the preset correspondence between global roles and sub-application lists. The target sub-application list includes the target sub-application identifier of the target sub-application client.

[0072] Understandably, the unified authentication module on the main application server verifies login information, such as password encryption / decryption comparison and verification code verification.

[0073] For example, the unified authentication module of the main application server requests the user's public permission data from the permission data storage module of the main application server; the permission data storage module of the main application server searches for the target sub-application list corresponding to the target global role identified by the user from the preset correspondence between global roles and sub-application lists, and feeds back the public permission data to the unified authentication module of the main application server.

[0074] The public permission data includes the target global role and the target sub-application list.

[0075] Understandably, the mapping relationship between "global roles" and "list of accessible sub-applications" is pre-configured. When a user logs in, the system automatically finds the list of sub-applications that the assigned global role is authorized to access. An example is provided below.

[0076] Suppose a bank's micro-frontend system has 5 sub-application clients: subApp1 (personal online banking), subApp2 (corporate online banking), subApp3 (loan management), subApp4 (wealth management products), and subApp5 (system management). The correspondence between global roles and the list of sub-applications can be shown in Table 1.

[0077] Table 1 Global Roles List of accessible sub-applications R001_Individual Customers [subApp1, subApp4] R002_Enterprise Customers [subApp2, subApp3] R003_Account Manager [subApp1, subApp2, subApp3] R004_System Administrator [subApp1, subApp2, subApp3, subApp4, subApp5]

[0078] Assuming user Zhang San logs in and verifies his identity, his user ID is found to be userId: zhangsan; Zhang San's target global role is R001_Individual Customer. According to Table 1, the target sub-application list corresponding to R001 is [subApp1, subApp4]. The main application client only displays the sub-application entries for "Personal Online Banking" and "Wealth Management Products," for example, displaying the icons for "Personal Online Banking" and "Wealth Management Products." Other sub-application clients are not visible to user Zhang San.

[0079] Step S203: The main application server generates a globally unique first session identifier based on the user identifier, public permission data, and the first validity period of the first session identifier. The public permission data includes the target global role and the target sub-application list.

[0080] For example, the unified authentication module in the main application server carries the user identifier and public permission data information, and requests the session management module in the main application server to generate a globally unique session identifier. The session management module combines the user identifier and public permission data information with the timestamp to aggregate and encrypt them, generating a first session identifier; and feeds back the first session identifier to the unified authentication module in the main application server.

[0081] For example, the timestamp is the moment when the first session identifier was generated.

[0082] For example, the first validity period of the first session identifier refers to the valid time period of the first session identifier. If the expiration time of the first validity period is 14:30:30 on November 21, 2025, and the current time is 13:30:30 on November 21, 2025, then the first session identifier is valid. If the current time is 13:30:31 on November 21, 2025, then the first session identifier is invalid.

[0083] Step S204: The main application server sends a login success message, the first session identifier, and the public permission data to the main application client.

[0084] For example, the unified authentication module in the main application server returns a login success message, the first session identifier, and public permission data to the main application client through the communication module.

[0085] Step S205: The main application client stores the first session identifier in the global storage space.

[0086] Step S206: The main application client loads the target sub-application client; and sends the target global role, the first session identifier, and the first validity period broadcast to the target sub-application client.

[0087] In this embodiment of the application, the sub-application client corresponding to the target sub-application identifier included in the target sub-application list is referred to as the target sub-application client. For example, there can be one or more target sub-application identifiers, and different target sub-application identifiers correspond to different target sub-application clients.

[0088] For example, the main application client loads the target sub-application clients according to the target sub-application list, and notifies the loaded target sub-application clients of the "session initialization instruction" through the communication module of the micro frontend framework, and transmits the target global role, the first session identifier, and the first validity period.

[0089] Step S207: The target sub-application client stores the target global role, the first session identifier, and the first validity period in its own session cache.

[0090] For example, the target sub-application client can send a confirmation message to the main application client, indicating that the target sub-application client has received the target global role, first session identifier, and first validity period. This allows the main application client to control the display of a "Login successful" feedback message.

[0091] Step S208: The main application client controls and displays the sub-application entry of the target sub-application client.

[0092] For example, sub-application entry points include, but are not limited to: links to the target sub-application client and icons for the target sub-application client.

[0093] In summary, steps S201 to S208 are the process of generating a globally unique first session identifier and initializing public permission data.

[0094] This application provides a control method based on a micro-frontend framework. By establishing a unified authentication and session management mechanism on the main application server, it effectively solves the session collaboration problem between the main application client and multiple sub-application clients in a micro-frontend architecture. Specifically, after completing user authentication on the main application server, this application generates a globally unique first session identifier containing user identification, public permission data, and validity period based on a preset global role-sub-application list mapping relationship. This identifier is then synchronized to the main application client and each sub-application client, achieving seamless transfer and consistent maintenance of session state across all sub-application clients after single sign-on. This fundamentally avoids the problem of repeated logins when switching between sub-application clients or between the main application client and sub-application clients, significantly improving operational continuity and user experience. Simultaneously, this application manages the lifecycle of the first session identifier and the access permissions of sub-application clients uniformly through the main application client. This retains the technical flexibility of independent development and deployment of sub-application clients under the micro-frontend architecture while establishing globally unified access control. This makes permission configuration more efficient and standardized in cross-team collaboration, reduces the maintenance cost of multi-application client systems, and fully leverages the scalability advantages of the micro-frontend architecture in complex business scenarios.

[0095] Unified session management refers to a technical mechanism in micro-frontend architecture where the main application client uniformly generates, maintains, and manages global session identifiers. Through active or passive synchronization mechanisms between the main application client and sub-application clients, it ensures the consistency of session states (i.e., consistent session identifiers and consistent session identifier validity periods) and the validity of public permission data between the main application client and sub-application clients. This enables users to switch between the main application client and various sub-application clients without repeated authentication after single sign-on.

[0096] The core objective of unified session management is to ensure the consistency of global session state and the validity of public permission data, achieving unified management of session lifecycle and state synchronization across application clients. Based on different synchronization triggering methods, it is divided into two categories: active synchronization and passive synchronization. Active synchronization involves the main application client broadcasting the session state, such as session initialization, session update, and session expiration, to sub-application clients through the communication module, ensuring that sub-application clients are aware of the global session dynamics in real time. Passive synchronization involves sub-application clients actively requesting the main application client to obtain the latest session state, suitable for periodic verification or abnormal recovery scenarios, ensuring the validity of the session identifiers stored by the sub-application clients themselves.

[0097] The following describes the methods of session state synchronization in conjunction with application scenarios. This application provides, but is not limited to, the following five application scenarios.

[0098] The first application scenario: When the menu of the sub-application client is activated, the session state and public permission data of the main application client and the sub-application client are synchronized.

[0099] like Figure 3 The flowchart shown is a method for synchronizing the session state and public permission data of the main application client and the sub-application client according to an embodiment of this application. The process includes the following steps S301 to S305.

[0100] Step S301: In response to the operation of the sub-application menu entry displayed through the main application client, the main application server verifies whether the first session identifier has expired and whether the public permission data has been updated.

[0101] For example, the sub-application menu entry corresponds to the target sub-application client.

[0102] Sub-application menu entry refers to an interactive navigation element presented on the main application client interface that is used to trigger and load a specific sub-application client. It is usually represented by menu items, icons, or buttons.

[0103] It is understandable that users need to interact with the sub-application client to access the sub-application menu, so it is necessary to synchronize the session state and public permission data of the main application client and the sub-application client.

[0104] For example, the method for the main application server to verify whether public permission data has been updated includes: searching for a candidate sub-application list corresponding to the target global role identified by the user from a preset correspondence between global roles and sub-application lists; detecting whether the target sub-application list and the candidate sub-application list are consistent; if they are consistent, it means that the public permission data has not been updated; if they are inconsistent, it means that the public permission data has been updated.

[0105] For example, the method for the main application server to verify whether the first session identifier has expired includes: if the expiration time of the first validity period is later than or equal to the current time, it is determined that the first session identifier has not expired; if the expiration time of the first validity period is earlier than the current time, it is determined that the first session has expired.

[0106] For example, the unified authentication module on the main application server checks whether the first session identifier has expired and whether the public permission data has been updated; if the first session has expired or the public permission data has been updated, then you need to log in again.

[0107] Step S302: If the first session identifier has not expired and the public permission data has not been updated, the main application server sends session validity information indicating that the first session identifier is valid and the public permission data has not been updated to the main application client.

[0108] Step S303: The main application client broadcasts a session initialization instruction to the target sub-application client. The session initialization instruction includes the first session identifier and the first validity period.

[0109] After confirming the session is valid, the main application client broadcasts the session initialization command to all sub-application clients through the communication mechanism of the micro-frontend framework or a custom event (implemented by the communication module), pushing the first session identifier and the first validity period.

[0110] Step S304: The target sub-application client updates the session cache based on the session initialization instruction.

[0111] After receiving the session initialization command, the target sub-application client updates the local session cache and initializes the functional permissions of the sub-application client through its own permission control module, such as rendering buttons that it has permission to access and hiding menus that it does not have permission to access.

[0112] For example, the target sub-application client sends a confirmation to the main application client that it has received the session initialization instruction.

[0113] Step S305: The target sub-application client renders the object that the target global role has permission to operate.

[0114] For example, the target sub-application client stores a mapping between global roles and operable objects, thereby enabling it to look up objects corresponding to the target global role. The target sub-application client can then render objects that the target global role has the permission to operate on.

[0115] Steps S301 to S304 ensure that the session state of the target sub-application client is completely consistent with the session state of the main application client when it starts, thus avoiding permission discrepancies caused by cache expiration.

[0116] The second application scenario is when the session identifier has not expired but is nearing its expiration time (e.g., the validity period is 2 hours and there are 10 minutes left before it expires), the main application client actively triggers the session renewal process and synchronizes it to the sub-application client.

[0117] like Figure 4 The flowchart shown is a method for synchronizing the session state and public permission data of the main application client and the sub-application client according to an embodiment of this application. The process includes the following steps S401 to S406.

[0118] Step S401: If the difference between the expiration time of the first validity period and the current time is less than or equal to the preset duration, the main application client sends a session renewal request to the main application server, and the session renewal request includes the first session identifier.

[0119] For example, the preset duration can be determined based on the actual situation and is not limited here. For instance, the preset duration is 10 minutes. The preset duration is greater than 0.

[0120] For example, the session management module of the main application client sends a session renewal request to the main application server.

[0121] Step S402: If it is detected that the expiration time of the first validity period of the first session identifier in the session renewal request is later than the current time, the main application server determines the second session identifier and the second validity period.

[0122] For example, the unified authentication module of the main application server checks whether the expiration time of the first validity period is later than the current time. If it is later than the current time, the first session identifier is determined to be valid. The unified authentication module of the main application server sends a session renewal request to the session management module of the main application server. The session management module of the main application server can generate a second session identifier and determine a second validity period in accordance with step S203.

[0123] Step S403: The main application server sends the second session identifier and the second validity period to the main application client.

[0124] For example, the session management module of the main application server sends the second session identifier and the second validity period to the main application client.

[0125] Step S404: The main application client updates the global storage space based on the second session identifier and the second validity period.

[0126] The global storage space will delete the first session identifier and the first expiration date, and store the second session identifier and the second expiration date.

[0127] Step S405: The main application client broadcasts a session update instruction to the target sub-application client. The session update instruction includes the second session identifier and the second validity period.

[0128] For example, the main application client broadcasts a "session updated" instruction to all loaded target sub-application clients through the communication mechanism of the micro-frontend framework or a custom event (implemented by the communication module). The session updated instruction is accompanied by a second session identifier and a second validity period.

[0129] Step S406: The target sub-application client updates its session cache based on the second session identifier and the second validity period.

[0130] Updating the session cache means that the target sub-application client replaces the first session identifier in the session cache with the second session identifier and replaces the first expiration date in the session cache with the second expiration date.

[0131] For example, the target sub-application client can send a message to the main application client confirming that the session has been updated.

[0132] Understandably, steps S401 to S406 achieve seamless session connection and improve user experience through "early renewal + proactive synchronization".

[0133] The third application scenario: When the main application client accesses the main application server, it is rejected by the main application server due to invalid session, such as expired session identifier (e.g., user has not operated for a long time or forced logout) or invalid public permission data (e.g., public permission data has changed, such as changes in the target sub-application list or changes in the target global role). The main application client triggers global logout synchronization, that is, both the main application client and the target sub-application client log out.

[0134] like Figure 5 The diagram shown is a flowchart of an implementation method for synchronizing the session state and public permission data of the main application client and the sub-application client according to an embodiment of this application. The process includes the following steps S501 to S506.

[0135] Step S501: The main application client sends an application service request to the main application server. The application service request includes the first session identifier and the first validity period.

[0136] Step S502: If it is detected that the expiration time of the first validity period is earlier than the current time or the public permission data is updated, the main application server sends an invalidation message indicating that the first session identifier has expired or the public permission data has been updated to the main application client; the first session identifier is assigned to a blacklist; and the blacklist is sent to the target sub-application server corresponding to the target sub-application client.

[0137] For example, the main application client sends the application service request to the unified authentication module of the main application server. The unified authentication module of the main application server checks whether the first session identifier has expired and whether the public permission data has been updated. If the first session identifier has expired or the public permission data has been updated, it means that you need to log out.

[0138] For example, the unified authentication module of the main application server sends the invalidation information to the session management module of the main application server. The session management module of the main application server adds the first session identifier to the blacklist, that is, the session status is invalid. The session management module of the main application server sends the blacklist to the target sub-application server.

[0139] For example, the failure message is a "401 Unauthorized" error.

[0140] Step S503: The main application client marks the first session identifier as invalid and clears the global storage space.

[0141] Step S504: The main application client sends a session expired instruction to the target sub-application client. The session expired instruction includes the first session identifier and the expiration information.

[0142] For example, the main application client broadcasts a session expiration instruction to all target sub-application clients through the micro-frontend framework's communication mechanism or a custom event (implemented by the communication module).

[0143] The failure information indicates the reason for the verification failure.

[0144] Step S505: After receiving the session expired instruction, the target sub-application client clears the target global role, the first session identifier, and the first validity period stored in its own session cache.

[0145] For example, the target sub-application client controls the display of the login page.

[0146] Step S506: The target sub-application server intercepts incomplete session requests with session identifiers included in the blacklist.

[0147] Any request carrying a session identifier from the blacklist will be intercepted by the target sub-application server, ensuring the synchronization of the final state when the session expires.

[0148] Steps S501 to S506 ensure that all sub-application clients log out synchronously when the session expires, thus avoiding the security problem of "the main application client has logged out but the sub-application clients can still operate".

[0149] The fourth application scenario: In order to avoid the inconsistency between the session identifier and validity period stored in the local session cache of the sub-application client and that of the main application client, for example, the main application client has already renewed the session (such as steps S401 to S404), but has not executed step S405, that is, it has not broadcast to the target sub-application client; or, step S405 has been executed but the sub-application client has not received it, so the sub-application client needs to perform active verification at regular intervals.

[0150] like Figure 6 The flowchart shown is a method for synchronizing the session state and public permission data of the main application client and the sub-application client according to an embodiment of this application. The process includes the following steps S601 to S604.

[0151] Step S601: The target sub-application client sends a timed session request to the main application client every preset time period.

[0152] For example, when the target sub-application client initializes, it starts a timer and calls a global method exposed by the main application client through the communication module to make a timed session request.

[0153] The timed session request is used to obtain the session identifier and validity period stored in the main application client.

[0154] For example, the preset time period can be determined based on the actual situation, and this application embodiment does not limit it.

[0155] Step S602: The main application client sends back session information to the target sub-application client. The session information includes the first session identifier, the first validity period, and whether the first session identifier is valid.

[0156] The main application client's session management module responds to the timed session request and returns the current global session identifier and validity period.

[0157] Step S603: If the first session identifier is invalid, the target sub-application client clears the target global role, the first session identifier, and the first validity period stored in its own session cache.

[0158] For example, the target sub-application client controls the display of the login interface, i.e., logout.

[0159] Step S604: If the first session identifier is valid, the target sub-application client updates the session cache of the target sub-application client based on the session information.

[0160] For example, if the first session identifier is valid, the target sub-application client can also synchronously verify its own public permission data. For example, it can retrieve the public permission data again from the permission data storage module of the main application server. See step S203 for details, which will not be repeated here.

[0161] Steps S601 to S604 utilize the "periodic heartbeat" mechanism of the sub-application client to compensate for any omissions that may occur during active synchronization (such as broadcast loss due to network fluctuations).

[0162] The fifth application scenario: When the target sub-application client accesses the target sub-application server, if it is rejected by the target sub-application server due to invalid session, that is, the target sub-application client recognizes that the global session identifier has expired (such as the user has not operated for a long time or has been forcibly logged out) or the public permission data has expired (the user's public permission data has changed, such as the list of target sub-applications that can be accessed has changed), the target sub-application client actively requests synchronization from the main application client to confirm the session status.

[0163] like Figure 7 The diagram shown is a flowchart of an implementation method for synchronizing the session state and public permission data of the main application client and the sub-application client according to an embodiment of this application. The process includes the following steps S701 to S706.

[0164] Step S701: The target sub-application client sends a session request to the target sub-application server.

[0165] Step S702: If the target sub-application server receives a session rejection message, the target sub-application client sends a new session request to the main application client. The new session request includes the first session identifier and the first validity period.

[0166] For example, the session rejection message could be a "401 Unauthorized" error.

[0167] For example, after the target sub-application client captures the session rejection information, it sends a new session request to the main application client through the communication module, indicating "session authentication failed, request a new session".

[0168] For example, the unified authentication module of the target sub-application server can verify the first session identifier and public permission data in the session request, that is, verify whether the first session identifier has expired and whether the public permission data has been updated; if the first session identifier has expired or the public permission data has been updated, a session rejection message will be returned.

[0169] Step S703: If the first session identifier is invalid, the main application client sends the session expired instruction to the target sub-application client.

[0170] For example, if the first session is identified as invalid, a "session expired instruction" is returned, triggering a global logout, see steps S503 to S506.

[0171] Step S704: If the first session identifier has been updated to the second session identifier and the first validity period has been updated to the second validity period, the main application client sends the new global session information to the target sub-application client and the target sub-application server. The new global session information includes the second session identifier and the second validity period.

[0172] Steps S701 to S704 can resolve the issues of "the sub-application client session is invalid but the main application client session is still valid" and "the main application client's active synchronization fails, causing the sub-application client session to expire," thus avoiding unnecessary logout triggers.

[0173] Independent access control refers to a technical mechanism in which each sub-application server, within the unified session framework of a micro-frontend architecture, independently authenticates and authorizes legitimate session users based on its own independent permission data storage module and permission control module.

[0174] The core objective of independent access control is to achieve fine-grained access control within sub-application clients based on a unified session. This includes the following four application scenarios, which will be explained in detail below.

[0175] The first application scenario: Access permission verification of sub-application clients by the main application server. When a user clicks on the sub-application entry point in the main application client, the unified authentication module of the main application server performs session verification, including verification of the session identifier's validity period and public permission data, among which the verification of public permission data is implemented through the permission control module.

[0176] like Figure 8 The diagram illustrates one implementation of the access permission verification method for sub-application clients by the main application server provided in this application. The verification process includes steps S801 to S806.

[0177] Step S801: In response to the operation of the sub-application entry displayed through the main application client, the main application client sends a global session validity verification request to the main application server. The global session validity verification request includes the user identifier, the first session identifier, and the first validity period.

[0178] The embodiments of this application assume that the sub-application entry activated by the user in the main application client is the sub-application entry of the target application client.

[0179] For example, the sub-application entry point is an interactive navigation element that is dynamically rendered based on public permission data and deployed on the main application client. It usually exists in the form of menu items, icons, or buttons and is used to trigger the entire process of access permission verification, session state synchronization, and sub-application client loading in the sub-application client. It is the only access touchpoint that enables users to switch from the main application client to a specific sub-application client.

[0180] Step S802: The main application server searches for the target sub-application list corresponding to the target global role of the user identifier from the preset correspondence between global roles and sub-application lists; if the target sub-application list does not include the identifier of the target sub-application client, it generates no-access information; if the target sub-application list includes the identifier of the target sub-application client, it generates authorized access information.

[0181] For example, the unified authentication module on the main application server parses the request to verify the validity of the global session, obtains the user identifier, and then queries the public permission data in the permission data storage module to obtain the list of target sub-applications.

[0182] For example, the permission data storage module of the main application server can be combined with application-level ACL calculation.

[0183] Step S803: If the main application client receives the authorized access information, it sends the authorized access information to the target sub-application client.

[0184] For example, if the main application client receives an access denied message, it will prompt the user that they do not have permission.

[0185] For example, if the main application client receives the access permission information, it allows access to the target sub-application client. At the same time, the target sub-application client requests private permissions from the target sub-application server to complete the permission data initialization.

[0186] Step S804: The target sub-application client sends a private permission request to the target sub-application server, the private permission request including the target global role.

[0187] Step S805: The target sub-application server sends the private permission data that the target global role is authorized to operate to the target sub-application client.

[0188] Private permission data refers to a set of permission information independently maintained by each sub-application client and used exclusively for internal functional and data-level permission control within the sub-application client. This includes roles, functional operation permissions, and data scope permissions within the sub-application client. It is stored on both the sub-application server and the sub-application client, isolated from the public permission data on the main application server, and forms the core data foundation for achieving independent permission control. An example is provided below for illustration.

[0189] Assuming that sub-application client A is for loan management, then private permission data can include the "loan approval" and "interest rate adjustment" function permissions that the "account manager" role can perform.

[0190] Assuming that the sub-application client B is a financial product, the private permission data includes the "product manager" role's permissions to perform the "product listing" and "yield configuration" functions, as well as the "customer" role's permissions to perform the "purchase" and "redemption" functions, and the "personal data" scope restrictions.

[0191] Step S806: The main application client controls the target sub-application client to display the user interface showing the private permission data.

[0192] Steps S801 to S806 can be used to verify the user's access rights to the target sub-application client through the session verification process on the main application server, thereby achieving precise access control for the target sub-application client.

[0193] The second application scenario involves function permission authentication within the sub-application client. When a user triggers a specific operation within the sub-application client, the sub-application client performs two verification steps: sub-application client authentication and sub-application server authentication.

[0194] like Figure 9 The diagram shown is a schematic representation of an implementation of authentication for a sub-application client and a sub-application server provided in this application embodiment. The authentication process includes the following steps S901 to S905.

[0195] Step S901: In response to an operation on the target object of the target sub-application client, the target sub-application client detects whether the private permission data includes the target object.

[0196] For example, the target object can be any object such as a table, button, link, or field.

[0197] For example, the target sub-application client detects whether the locally cached private permission data includes the target object.

[0198] Step S902: If the private permission data includes the target object, the target sub-application client sends an operation request for the target object to the target sub-application server.

[0199] For example, if the private permission data does not include the target object, then a prompt message indicating that the user does not have permission to operate on the target object is displayed.

[0200] For example, the target sub-application server performs an operation on the target object and feeds back the operation result to the target sub-application client.

[0201] It is understandable that steps S901 to S902 and steps S903 to S905 are two independent cases and there is no order between them.

[0202] Step S903: In response to the operation on the target object for the target sub-application client, the target sub-application client sends the operation request for the target object to the target sub-application server.

[0203] Step S904: If the first session identifier has not expired and the public permission data has not been updated, the target sub-application server detects whether the private permission data includes the target object.

[0204] For example, the unified authentication module of the target sub-application server verifies the validity of the global session, that is, it checks whether the first session identifier has expired and whether the public permission data has been updated. If the first session identifier has not expired and the public permission data has not been updated, the unified authentication module of the target sub-application server sends a private permission verification request to the permission control module of the target sub-application server. The permission control module of the target sub-application server searches for the private permission data of the target global role in the permission data storage module of the target sub-application server. The permission control module of the target sub-application server checks whether the private permission data includes the target object.

[0205] Step S905: If the private permission data includes the target object, the target sub-application server performs an operation on the target object.

[0206] If the private permission data does not include the target object, an error message indicating that the target sub-application client does not have the necessary permissions is sent.

[0207] Steps S901 to S905 ensure global session uniformity, independent authentication of each sub-application client, and prevent any possible sub-application client from bypassing security attacks.

[0208] The third application scenario: The private permission data of the sub-application client has a data range, that is, the user has operation permission for data that belongs to the data range.

[0209] In one alternative implementation, after the target sub-application server performs the operation on the target object, the following two cases are also included.

[0210] Scenario 1: The target sub-application server sends the first operation result to the target sub-application client, where the first operation result is the data corresponding to the dataScope field.

[0211] For example, performing an operation on the target object is a data query operation. The dataScope field corresponding to different global roles can be the same or different.

[0212] For example, when the target sub-application server queries data, it automatically appends data scope conditions (i.e., the `dataScope` field) to ensure that data access complies with permission rules. It's understandable that the `dataScope` field is a key component in implementing data scope permission filtering. The `dataScope` field is typically used to store the range of data that a user or role can access. Based on the value of the `dataScope` field, it determines which data a user can access. For example:

[0213] All data: Users can access all data in the target sub-application, typically for super administrators.

[0214] Departmental Data: Users can only access data from their own department within the target sub-application, applicable to roles such as department managers.

[0215] Personal data: Users can only access their own data within the target sub-application; this applies to ordinary employees.

[0216] Specified data: Users can access specific data in the target sub-application, which may be configured or assigned to specific data.

[0217] Scenario 2: The target sub-application server sends the second operation result to the target sub-application client; the target sub-application client displays the data corresponding to the dataScope field in the second operation result.

[0218] The second operation result may include data outside the data range, which the target sub-application client then filters based on the dataScope field.

[0219] Whether the data filtering is implemented on the target sub-application server or the target sub-application client, it is all done through the access control module. The specific steps for the access control module to implement data range access filtering include steps A1 to A2.

[0220] Step A1: Define the permission model: Define the private permission model for each sub-application client. The private permission model includes the mapping relationship between global roles and private permission data. The private permission data includes the dataScope field corresponding to the global role.

[0221] Step A2: Permission Verification: During permission initialization, the permission control module of the sub-application client obtains the user's private permission model and then controls the data display scope based on the dataScope field corresponding to the global role of that user. When a user requests data, the permission control module of the sub-application server needs to perform permission verification based on the dataScope field value corresponding to the global role of that user, combined with the requested data range, to ensure that the user can only access authorized data.

[0222] The fourth application scenario: If the administrator modifies the user's public permission data in the main application client, such as adding a user's access permission to a certain sub-application client, the permission data storage module updates the corresponding record and marks it as "permissions updated".

[0223] If a user's public permission data changes, such as a change in the sub-application's access list, the main application client's communication module will push the permission update notification to the relevant sub-application server through a call between the main application server and the sub-application server. The sub-application server's communication module will then push the changed content to the sub-application client through either push notifications from the sub-application server or periodic polling by the sub-application client.

[0224] If a user's private permission data changes in the sub-application client, the sub-application client's communication module will push the changed content to the sub-application client through push from the sub-application server or by periodically polling the sub-application client to detect updates. The new permission rules will take effect in real time without requiring the user to log in again.

[0225] This application's embodiments target a general micro-frontend framework. A unified authentication module enables one-time login access across the entire system; a session management module, in conjunction with a communication module, ensures cross-application session consistency; a permission data storage module isolates sub-application permission data; and an authorization and authentication module enables fine-grained permission control for sub-application clients. The solution provided in this application balances system consistency with the autonomy of application clients (a unified term for both sub-application clients and the main application client), improving security and user experience.

[0226] This application isolates and stores the private permission data of sub-application clients through a permission data storage module, allowing the sub-application clients to independently perform authorization and authentication, thus solving the problem of insufficient permission flexibility of sub-application clients caused by permission synchronization.

[0227] The solution in this application generates a global session identifier through a unified authentication module, and combines the session management module and the communication module to realize the synchronization of session identifiers across application clients, while preserving the permission independence of sub-application clients, thus balancing session uniformity and permission flexibility.

[0228] The unified authentication module in this application not only completes identity verification, but also combines with the session management module to realize global session lifecycle management in the micro-frontend environment, achieving the goal of adapting to session synchronization of multiple sub-application clients.

[0229] The scheme in this application embodiment stores the global session identifier in the main application client and the sub-application client respectively, avoiding the single point of failure problem. Furthermore, through the permission data storage module, the global session identifier and public permission data mapping are stored on the main application server, and the global session identifier and private permission data mapping are stored on the sub-application server. The permission control module supports the sub-application client to customize permission rules, and achieves fine-grained independent permission control on the basis of unified authentication.

[0230] This application designs five modules—access control, access data storage, unified authentication, session management, and communication—that work collaboratively across multiple core processes. Unified session management solves the problems of "repeated logins by sub-application clients" and "session state fragmentation" inherent in traditional micro-frontends, ensuring a unified session experience and cross-application consistency. Independent access control isolates and stores public and private access data, supporting sub-application clients to independently execute functional and data-level authentication. This meets the personalized access requirements of different business sub-application clients, avoiding redundancy from repetitive development of the access control system and achieving independent, controllable, and refined management of sub-application client permissions. This design of "centralized management of identity sessions and distributed execution of access rules" balances the overall integrity of the micro-frontend architecture with the independence of sub-application clients, significantly improving system security, user experience, and development efficiency.

[0231] This application achieves unified maintenance and synchronization of session states between the main application and sub-applications under the same user system, avoiding session inconsistencies when users switch between different applications and improving user experience. Simultaneously, each sub-application can independently manage access control based on its own business characteristics and security requirements, ensuring flexibility and security in access management. This effectively addresses the shortcomings of existing micro-frontend architectures in handling such scenarios and has broad application prospects and promotional value.

[0232] The following section, based on the aforementioned process, details the stages and core roles of each module in this application, clarifying their positioning and collaborative relationships within the micro-frontend architecture.

[0233] The unified authentication module acts as the "gatekeeper" of global identity verification, and is mainly responsible for verifying the legitimacy of session credentials, thereby ensuring the legitimacy of user identity and consistency of cross-application authentication.

[0234] The unified authentication module on the main application server serves as the core deployment point and is responsible for the global authentication logic. The unified authentication modules on each sub-application server are deployed in a simplified version, such as a build package, which is mainly used to verify the session credentials generated by the main application client and does not require repeated implementation of the complete authentication logic.

[0235] The unified authentication module has the following three stages: Login stage: verifying user account passwords, third-party authentication information, etc., to confirm the validity of the identity; Session stage: the unified authentication module of the main application server and the sub-application server verifies whether the session identifier is valid to prevent the use of forged or expired session identifiers; Cross-application authentication: the unified authentication module of the sub-application server communicates with the main application server to confirm the validity of the global session (to prevent sub-application clients from logging in repeatedly).

[0236] The core functions of the unified authentication module are as follows: Ensuring unified sessions: As the login verification entry point, only the main application client generates a global session identifier after completing user identity verification. Sub-application clients do not need to log in repeatedly; they only need to verify session legitimacy based on the global session identifier, ensuring from the source that all application clients share the same login identity and session baseline. Ensuring independent access control: It is only responsible for "identity verification," confirming the legitimacy of the user's identity, and does not interfere with the access control logic of sub-application clients. Subsequent access control decisions by sub-application clients are handled by their own access control modules, achieving "unified identity, independent access."

[0237] The session management module controls the entire lifecycle of global session identifiers, ensuring session consistency across application clients, and is the core executor of "unified session".

[0238] The session management module of the main application client is responsible for local storage of session state and synchronous notifications from client sub-applications. The session management module of the main application server is the core deployment point, responsible for the core logic of session generation, renewal, and destruction, and maintaining a globally unified session pool.

[0239] The session management module has the following four stages: Session generation: After a user successfully logs in, a globally unique session identifier is generated and associated with the user's identity and public permission data; Session maintenance: Effective communication mechanisms such as pre-expiration requests and timed requests are used to maintain the effective synchronization of the session; Session destruction: Activated logout, changes to public permission data, forced cancellation, and other scenarios are handled, marking the session as invalid and triggering global synchronization; State synchronization: The current state of the session (valid / expired / cancelled) is recorded to provide other modules with a basis for judging the validity of the session.

[0240] The core functions of the session management module are as follows: Ensuring unified sessions: The main application client, as the global session core, is responsible for generating, updating (refreshing before expiration), and destroying (session expiration) global session identifiers. Through "active synchronization" (the main application client actively pushes session status to activated sub-application clients) and "passive synchronization" (sub-application clients periodically / when authentication fails, requesting the main application client's session status), it ensures that the session status of all sub-application clients is completely consistent with that of the main application client, avoiding session inconsistency issues. Ensuring independent access control: It only manages "session validity," such as whether the session has expired and whether the credentials are valid. It does not store / process the private access data of sub-application clients; the sub-application access logic is decoupled from session management, and each takes effect independently.

[0241] The access control module determines whether to allow access / operation based on public and private access data, and is the "executor" of access control.

[0242] The main application client's permission control module is responsible for application-level authentication, such as blocking unauthorized sub-application entries; the permission control modules of each sub-application client are responsible for function-level authentication within the sub-application client, such as hiding unauthorized buttons; the permission control modules of each sub-application server are responsible for the final authentication of operation requests, preventing client authentication from being bypassed and ensuring data security.

[0243] The access control module's access control is divided into two layers: application-level and function-level authentication. Its specific functions include the following three stages: Application-level authentication: On the main application client, it determines whether a user has permission to access a sub-application client based on the application-level access control list in the public permission data; Function-level authentication: On the sub-application client, it determines whether the user has permission to perform specific operations, such as clicking buttons or submitting forms, including function permissions and data scope permissions; Dynamic authentication: After the public permission data is updated, the new authentication rules take effect in real time, without requiring the user to log in again.

[0244] The core functions of the access control module are as follows: Ensuring unified sessions: When authenticating, sub-application clients must first verify the global session identifier issued by the main application client through the communication module. Subsequent permission checks are only performed if the session is valid, ensuring all authentication operations are based on a unified and valid session and preventing unauthorized sessions from bypassing authentication. Ensuring independent access control: This module is deployed independently on the sub-application server. Based on its own preset permission rules, such as the "global role-menu" mapping in sub-application client A and the "global role-interface" mapping in sub-application client B, it performs permission checks on legitimate session users (e.g., whether they can access a certain interface / menu). The authentication logic and rules of different sub-application clients are completely independent and do not interfere with each other.

[0245] The permission data storage module serves as the "central repository" for permission and session data, responsible for data storage, isolation, and retrieval, supporting the decision-making of various modules.

[0246] The permission data storage modules for the main application server and sub-application servers are the core deployment points, implemented using databases or distributed caching to ensure high availability. The main application server stores the mapping relationship between public permission data and global session identifiers, while the sub-application servers store the mapping relationship between the private permission data of each sub-application client and global session identifiers. The permission data storage module of the main application client is used to cache public permission data, reducing the query pressure on the main application server. The permission data storage module of each sub-application client is used to cache its own private permission data, improving the authentication efficiency of the application client.

[0247] The specific functions of the permission data storage module include the following four stages: Data storage: saving users' public permission data (global roles, sub-application access lists) and private permission data (functional / data permissions within sub-application clients); Data isolation: dividing the private permission storage area according to sub-application clients to ensure that sub-application clients can only access their own private permission data; Association management: binding session credentials with private permission data, supporting quick querying of user permissions through session identifiers; Data update: receiving permission change instructions (such as administrators modifying public or private permission data), updating the stored content in real time, and marking the version.

[0248] The core functions of the permission data storage module are as follows: Ensuring unified sessions: It centrally stores the global session identifier generated by the main application client and binds it to public permission data and private permission data, allowing the main / sub-application servers to query it through the communication module. This ensures that all application clients obtain a consistent session baseline, supporting unified session verification and corresponding permission acquisition and verification. Ensuring independent permission control: It splits and stores permission data according to the sub-application client dimension, allowing only the corresponding sub-application client to query its own private permission data. For example, sub-application client A cannot read the private permission configuration of sub-application client B, achieving independent permission control through data layer isolation.

[0249] The communication module acts as an "information bridge" between various modules, application clients, and application servers, enabling data transmission and event notification, and ensuring cross-application collaboration. This module is installed in three locations: the main application client (providing a global communication interface), each sub-application client (implementing adaptation logic for communication with the main application client), and the main application server and sub-application servers (achieving server-side communication through an API gateway or direct interface calls).

[0250] The communication module specifically implements the following three types of communication: client communication: synchronization of session state and public permission data between the main application client and the sub-application client, such as through the communication mechanism of the micro-frontend framework, custom events, or browser communication mechanism; server communication: session verification and permission data query between the main application server and the sub-application server, such as through internal API interfaces; real-time notification: instant push of key events such as session expiration and permission updates, such as active push by the sub-application server or the main application server, or polling requests from the client.

[0251] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

Claims

1. A control method based on a micro-frontend framework, characterized in that, include: The main application client sends login information to the main application server, and the login information includes a user identifier; If the login information is verified, the main application server searches for the target sub-application list corresponding to the target global role of the user identifier from the preset correspondence between global roles and sub-application lists. The target sub-application list includes the target sub-application identifier of the target sub-application client. The main application server generates a globally unique first session identifier based on the user identifier, public permission data, and the first validity period of the first session identifier. The public permission data includes the target global role and the target sub-application list. The main application server sends a login success message, the first session identifier, and the public permission data to the main application client. The main application client stores the first session identifier in the global storage space; The main application client loads the target sub-application client; Send the target global role, the first session identifier, and the first validity period broadcast to the target sub-application client; The target sub-application client stores the target global role, the first session identifier, and the first validity period in its own session cache; The main application client controls and displays the sub-application entry of the target sub-application client.

2. The control method based on a micro-frontend framework according to claim 1, characterized in that, Also includes: In response to an operation on a sub-application menu entry displayed through the main application client, the main application server verifies whether the first session identifier has expired and whether the public permission data has been updated, and the sub-application menu entry corresponds to the target sub-application client. If the first session identifier has not expired and the public permission data has not been updated, the main application server sends session validity information indicating that the first session identifier is valid and the public permission data has not been updated to the main application client; The main application client broadcasts a session initialization command to the target sub-application client, the session initialization command including the first session identifier and the first validity period; The target sub-application client updates the session cache based on the session initialization command; The target sub-application client renders objects that the target global role has permission to operate.

3. The control method based on a micro-frontend framework according to claim 1, characterized in that, Also includes: If the difference between the expiration time of the first validity period and the current time is less than or equal to the preset duration, the main application client sends a session renewal request to the main application server, and the session renewal request includes the first session identifier. If it is detected that the expiration time of the first validity period of the first session identifier in the session renewal request is later than the current time, the main application server determines the second session identifier and the second validity period; The main application server sends the second session identifier and the second validity period to the main application client; The main application client updates the global storage space based on the second session identifier and the second validity period; The main application client broadcasts a session update instruction to the target sub-application client, the session update instruction including the second session identifier and the second validity period; The target sub-application client updates its session cache based on the second session identifier and the second validity period.

4. The control method based on a micro-frontend framework according to claim 1, characterized in that, Also includes: The main application client sends an application service request to the main application server, and the application service request includes the first session identifier and the first validity period; If the expiration time of the first validity period is detected to be earlier than the current time or the public permission data is updated, the main application server sends an invalidation message indicating that the first session identifier has expired or the public permission data has been updated to the main application client. The first session identifier is assigned to a blacklist; and the blacklist is sent to the target sub-application server corresponding to the target sub-application client. The main application client marks the first session identifier as invalid and clears the global storage space; The main application client sends a session expired instruction to the target sub-application client. The session expired instruction includes the first session identifier and the expiration information. After receiving the session expired instruction, the target sub-application client clears the target global role, the first session identifier, and the first validity period stored in its own session cache; The target sub-application server intercepts incomplete session requests that contain session identifiers included in the blacklist.

5. The control method based on the micro-frontend framework according to claim 4, characterized in that, Also includes: The target sub-application client sends a session request to the target sub-application server; If the target sub-application client receives a session rejection message from the target sub-application server, the target sub-application client sends a new session request to the main application client. The new session request includes the first session identifier and the first validity period. If the first session identifier is invalid, the main application client sends a session expired instruction to the target sub-application client; If the first session identifier has been updated to the second session identifier and the first validity period has been updated to the second validity period, the main application client sends the new global session information to the target sub-application client and the target sub-application server, including the second session identifier and the second validity period.

6. The control method based on a micro-frontend framework according to claim 1, characterized in that, Also includes: The target sub-application client sends a timed session request to the main application client at preset time intervals; The main application client feeds back session information to the target sub-application client. The session information includes the first session identifier, the first validity period, and whether the first session identifier is valid. If the first session identifier is invalid, the target sub-application client clears the target global role, the first session identifier, and the first validity period stored in its own session cache; If the first session identifier is valid, the target sub-application client updates the session cache of the target sub-application client based on the session information.

7. The control method based on a micro-frontend framework according to any one of claims 4 to 6, characterized in that, After the target sub-application client clears its own session cache of the target global role, the first session identifier, and the first expiration date, the process further includes: The target sub-application client controls the display of the login page.

8. The control method based on a micro-frontend framework according to claim 1, characterized in that, Also includes: In response to an operation on the sub-application entry displayed through the main application client, the main application client sends a global session validity verification request to the main application server. The global session validity verification request includes the user identifier, the first session identifier, and the first validity period. The main application server searches for the target sub-application list corresponding to the target global role of the user identifier from the preset correspondence between global roles and sub-application lists; if the target sub-application list does not include the identifier of the target sub-application client, it generates an access denied message. If the target sub-application list includes the identifier of the target sub-application client, generate access permission information; If the main application client receives the authorized access information, it sends the authorized access information to the target sub-application client. The target sub-application client sends a private permission request to the target sub-application server, and the private permission request includes the target global role; The target sub-application server sends the private permission data that the target global role is authorized to operate to the target sub-application client; The main application client controls the target sub-application client to display the user interface showing the private permission data.

9. The control method based on a micro-frontend framework according to claim 8, characterized in that, Also includes: In response to an operation on a target object of the target sub-application client, the target sub-application client detects whether the private permission data includes the target object; If the private permission data includes the target object, send an operation request for the target object to the target sub-application server; or, In response to an operation on the target object of the target sub-application client, the target sub-application client sends an operation request for the target object to the target sub-application server; if the first session identifier has not expired and the public permission data has not been updated, the target sub-application server checks whether the private permission data includes the target object; if the private permission data includes the target object, it executes the operation on the functional module.

10. The control method based on a micro-frontend framework according to any one of claims 8 or 9, characterized in that, The private permission data also includes a dataScope field, and after the target sub-application server performs an operation on the target object, it also includes: The target sub-application server sends a first operation result to the target sub-application client, where the first operation result is the data corresponding to the dataScope field; or... The target sub-application server sends the second operation result to the target sub-application client; the target sub-application client displays the data corresponding to the dataScope field in the second operation result.

Images