Session management method and device, computer device and readable storage medium

Abstract

This application relates to a session management method, apparatus, computer device, and computer-readable storage medium. It includes: receiving a login request from a first front-end service, carrying a service identifier header; the first front-end service running in a browser, and the browser running at least one front-end service; querying the corresponding cookie name in a configuration center based on the service identifier header; creating a corresponding session based on the cookie name; generating response information based on the cookie name and sending it back to the browser. This method assigns different cookie names to front-end services running in the same browser, allowing users to access the same back-end service through multiple front-end services in the same browser without exiting and creating a new session, seamlessly switching between different identities, improving user experience and operational efficiency; by assigning a session cookie name through the service identifier header of each front-end service, it can resolve session conflicts between multiple front-end services on the same browser.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a session management method, apparatus, computer device, and computer-readable storage medium. Background Technology

[0002] Currently, because the domain attribute of browser cookies is unique, cookies with the same name under the same domain or IP address can conflict. However, the default session cookie name in the Shiro framework is JsessionId. If multiple services using Shiro to manage sessions are deployed on the same site, or if the same backend service provides multiple frontend pages, session conflicts may occur.

[0003] In traditional network frameworks, users typically access backend services through a single frontend interface. When a user needs to access the same backend service with different identities, they usually have to log out of the current session and log in again. This approach degrades the user experience and increases operational complexity. Summary of the Invention

[0004] Therefore, it is necessary to provide a session management method, apparatus, computer device, and computer-readable storage medium to address the aforementioned technical problems and resolve session conflicts among multiple front-end services on the same browser.

[0005] Firstly, this application provides a session management method, including:

[0006] Receive login request from the first front-end service; the login request carries a service identifier header; the first front-end service runs in the browser, and the browser runs at least one front-end service;

[0007] Based on the service identifier header, query the corresponding cookie name in the configuration center;

[0008] Create a corresponding session based on the cookie name;

[0009] Generate response information based on the cookie name and send the response information back to the browser.

[0010] In one embodiment, the login request also carries login information; after creating a corresponding session based on the cookie name, the method further includes:

[0011] Authentication is performed based on login information;

[0012] After successful identity authentication, access to resources is authorized;

[0013] The authorization information for accessing resources is associated with the cookie name, and the authorization information is stored in the session.

[0014] In one embodiment, the method further includes:

[0015] Receive access requests from the second front-end service; the access request carries the target service identifier header and the target cookie name obtained by the browser;

[0016] Verify the target cookie name based on the target service identifier header;

[0017] After successful verification, the corresponding target session is determined based on the target cookie name;

[0018] The system processes access requests based on the target session and returns the corresponding processing data.

[0019] In one embodiment, after verifying the target cookie name based on the target service identifier header, the method further includes:

[0020] If verification fails, a message indicating access failure will be returned to the browser.

[0021] In one embodiment, the method further includes:

[0022] During the operation of each session, the session data of each session is stored in the Redis cluster according to the cookie name of each session.

[0023] In one embodiment, the method further includes:

[0024] If the current session is detected to have ended, the corresponding session data is deleted from the Redis cluster based on the cookie name of the current session, and the current session is terminated.

[0025] In one embodiment, the method further includes:

[0026] During the backend service upgrade process, obtain the cookie name of the created session;

[0027] Based on the front-end service corresponding to each created session, determine the service identifier header for each created session;

[0028] Update the mapping between cookie names and service identifier headers in the configuration center based on the cookie names and service identifier headers of each created session.

[0029] Secondly, this application also provides a session management device, comprising:

[0030] The receiving module is used to receive login requests from the first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service;

[0031] The query module is used to query the corresponding cookie name in the configuration center based on the service identifier header;

[0032] Create a module to create a corresponding session based on the cookie name;

[0033] The response module is used to generate response information based on the cookie name and send the response information back to the browser.

[0034] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect above.

[0035] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect above.

[0036] The aforementioned session management method, apparatus, computer device, and computer-readable storage medium receive a login request from a first front-end service. The login request carries a service identifier header. The first front-end service runs in a browser, and the browser runs at least one front-end service. Based on the service identifier header, the corresponding cookie name is queried from the configuration center. Based on the cookie name, a corresponding session is created. Response information is generated based on the cookie name and sent back to the browser. By assigning different cookie names to each front-end service running in the same browser, users can access the same back-end service through multiple front-end services in the same browser, seamlessly switching between different identities without exiting and creating a new session, thus improving user experience and operational efficiency. Assigning a session cookie name through the service identifier header of each front-end service resolves session conflicts between multiple front-end services on the same browser. Attached Figure Description

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

[0038] Figure 1 This is a diagram illustrating the application environment of a session management method in one embodiment;

[0039] Figure 2 This is a flowchart illustrating a session management method in one embodiment;

[0040] Figure 3 This is a flowchart illustrating the session management method in another embodiment;

[0041] Figure 4 This is a schematic diagram illustrating the interaction between a browser and a backend service in one embodiment;

[0042] Figure 5 This is a structural block diagram of a session management device in one embodiment;

[0043] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] It is understood that the terms "first," "second," etc., used in this application may be used to describe various elements herein, but these elements are not limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of this application, a first front-end service may be referred to as a second front-end service, and similarly, a second front-end service may be referred to as a first front-end service. Both the first front-end service and the second front-end service are front-end services, and may be the same front-end service or different front-end services.

[0046] The session management method provided in this application embodiment can be applied to, for example, Figure 1The application environment is shown. Browser 102 communicates with backend server 104 via a network. A data storage system stores the data that backend server 104 needs to process. The data storage system can be integrated onto backend server 104 or placed on the cloud or other network servers. Browser 102 runs at least one frontend service, and each frontend service interfaces with the backend service running on backend server 104. Backend server 104 allocates sessions for each frontend service, enabling access to the backend service. Browser 102 runs on a terminal, which can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Backend server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0047] To facilitate understanding of the embodiments provided in this application, some terms that appear in the detailed description are introduced below:

[0048] A session refers to the process of multiple requests and responses between a browser and a server. From the moment the browser accesses the server until the access ends (i.e., the browser is closed), all the requests and responses generated during this period constitute one browser-server session. It can be understood as a user opening a browser, clicking multiple hyperlinks to access web resources on the server, and then closing the browser; this entire process is called a session. A session includes not only instances where a new window or tab is opened, but also instances where the user clicks multiple links, whether in the same window or a newly opened window or tab. Session data is stored between the browser and the server to track and record information about user interactions with the website.

[0049] A cookie is a small text file that a website stores on the user's local terminal (client-side) to identify the user. It is usually encrypted. The purpose of setting cookies is to allow websites to identify users, track sessions, and remember specific user information, such as the location of the last visit, the time spent, or user preferences (such as style sheets). Cookies can be stored in the browser's random access memory (RAM) or on the computer's hard drive so that the information is retained even after the user logs out of the website or web server.

[0050] Shiro, or Apache Shiro, is a powerful and easy-to-use Java security framework that provides authentication, authorization, encryption, and session management capabilities. For any application, Shiro can provide comprehensive security management services.

[0051] In one exemplary embodiment, such as Figure 2 As shown, a session management method is provided, which can be applied to... Figure 1 Taking the backend server 104 as an example, the explanation includes:

[0052] Step 202: Receive a login request from the first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service.

[0053] Each frontend service adds a corresponding service identifier header when making a request, allowing the backend server to identify and differentiate them. Optionally, the service identifier header can be added via an nginx reverse proxy or similar method. The service identifier header can be the credential information configured by the developer for each application.

[0054] The login request received by the backend server carries a service identifier header. This means the backend server interfaces with at least one frontend service running on the browser, capable of processing requests from different frontend services synchronously or asynchronously. Each request carries the service identifier header of the frontend service that issued the request. This method allows for the differentiation of sessions across multiple frontend services, facilitating user access to the backend server through various frontend services.

[0055] Step 204: Based on the service identifier header, query the corresponding cookie name in the configuration center.

[0056] In this implementation, upon receiving a login request, the backend service running on the backend server first checks the service identifier header in the login request to determine which frontend service the login request belongs to. Based on the service identifier header, it then looks up the corresponding cookie name in the configuration center. The configuration center contains the service identifier headers and corresponding session cookie names for each frontend service, allowing for flexible modification. Nacos can be used as the configuration center; this embodiment does not impose any restrictions. After receiving the login request, the backend server queries the configuration center based on the service identifier header carried in the login request to determine the configured cookie name.

[0057] Understandably, the configuration center pre-assigns different cookie names to different service identifier headers to avoid session conflicts. In an alternative implementation, the backend server uses the Shiro framework, with a custom `ShiroSessionManager` class inheriting from the framework's `DefaultWebSessionManager` class for flexible session management; the `onStart` method is overridden, modifying the `storeSessionId` method called within it to a custom method; and the custom `storeSessionId` method assigns a specific cookie name to the request based on the specific header identifier of the request. The mapping between different headers and cookie names is stored in the Nacos configuration center.

[0058] Step 206: Create the corresponding session based on the cookie name.

[0059] Step 208: Generate response information based on the cookie name and send the response information back to the browser.

[0060] The backend server uses this cookie name to create a new session. Optionally, a custom ShiroSessionManager class can be used to create and manage sessions. The custom storeSessionId method stores the newly created session ID in a cookie in the response and sends it back to the browser. The name of this cookie is the same as the cookie name queried in step 204.

[0061] In one alternative implementation, upon receiving a session creation request (carrying a service identifier header), if a session with the same name already exists, the session name corresponding to the service identifier header is retrieved from the configuration center, and a new session is created using the new session name.

[0062] In one alternative implementation, when a user switches between different front-end services, the back-end service reads and updates the session using the corresponding cookie name based on the service identifier header in the request, thus enabling the use of multiple sessions.

[0063] In this embodiment, the relationship between cookie names and header identifiers is managed through a configuration center, improving the flexibility and maintainability of session management. Users can use multiple front-end services within the same browser, accessing them with different identities and quickly switching between them, reducing the number of steps required for switching between identities. Controlling identity switching through back-end services enhances system security.

[0064] Understandably, the following example illustrates the application scenario of the session management method provided in this application: In a low-code development platform, developers build and deploy applications that share the same backend service. Developers can configure specific credential information for each application and carry this information in user requests through custom code to enable multi-user login.

[0065] In the above session management method, a login request from a first front-end service is received; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service; based on the service identifier header, the corresponding cookie name is queried in the configuration center; based on the cookie name, a corresponding session is created; response information is generated based on the cookie name and sent back to the browser. By assigning different cookie names to each front-end service running in the same browser, users can access the same back-end service through multiple front-end services in the same browser, seamlessly switching between different identities without exiting and creating a new session, improving user experience and operational efficiency; by assigning a session cookie name through the service identifier header of each front-end service, the session conflict problem of multiple front-end services on the same browser can be resolved.

[0066] In an exemplary embodiment, after step 206, the login request also carries login information. The method further includes: performing identity authentication based on the login information; authorizing access to resources after successful identity authentication; associating the authorization information for accessing resources with a cookie name and storing the authorization information in the session.

[0067] In this process, the user initiates a login request through the interface of the first front-end service in their browser, entering login information (such as username and password). The first front-end service then sends the user's login information and a service identifier header to the back-end service. The back-end service authenticates the user's login information, such as looking up the password for the username and verifying whether it matches the password entered by the user. If authentication is successful, the user is authorized to access the corresponding resources; the authorization information is stored in the created session and associated with a specific cookie name.

[0068] In one exemplary embodiment, such as Figure 3 As shown, the method further includes:

[0069] Step 302: Receive the access request from the second front-end service; the access request carries the target service identifier header and the target cookie name obtained by the browser.

[0070] In this embodiment, the second front-end service and the first front-end service run in the same browser. They can be the same front-end service or different front-end services; this embodiment does not impose any restrictions on this. It is understood that after a user successfully logs in through the second front-end service, the browser stores the target cookie name associated with the session of the second front-end service based on the response information from the back-end service. When the user initiates subsequent access requests to the back-end service, the browser automatically includes this target cookie name and the target service identifier header of the second front-end service.

[0071] Step 304: Verify the target cookie name based on the target service identifier header.

[0072] The backend service retrieves the corresponding cookie name from the configuration center based on the target service identifier header. If the found cookie name matches the target cookie name, the verification passes; otherwise, the verification fails.

[0073] Step 306: After successful verification, determine the corresponding target session based on the target cookie name.

[0074] The backend service is based on the Shiro framework and uses a custom getSessionId method to read the session using a new session name based on the target cookie name in the request.

[0075] Step 308: Process the access request according to the target session and return the corresponding processing data.

[0076] The backend service processes user access requests based on the target session and returns the corresponding processing data to the second frontend service.

[0077] In this embodiment, by carrying the service identifier header and cookie name when accessing the backend service, the backend service can easily verify the cookie name and quickly obtain the session, thereby improving the security of accessing the backend service.

[0078] In one exemplary embodiment, after step 304, the method further includes: if the verification fails, returning an access failure message to the browser.

[0079] If the found cookie name does not match the target cookie name, the verification fails, indicating that the backend service has established a new session for the second frontend service, but the browser has not yet updated the relevant cookie name. To avoid information conflicts, an access failure message is returned to the browser. After receiving the response information containing the new cookie name, the browser resends the access request based on the updated cookie name, and the backend service provides services based on the newly established session.

[0080] In an exemplary embodiment, the method further includes: during the operation of each session, storing the session data of each session in a Redis cluster according to the cookie name of each session.

[0081] Throughout the user's session, the backend service updates session data based on runtime conditions, such as user behavior logs and permission changes. Based on the session's cookie name, the session data is stored in a Redis cluster, ensuring the consistency and high availability of session data in the distributed system.

[0082] In an exemplary embodiment, the method further includes: if it is detected that the current session has ended, then delete the corresponding session data from the Redis cluster according to the cookie name of the current session, and end the current session.

[0083] Specifically, when a user logs out or the session expires, the backend service looks up the corresponding cookie name in the configuration center based on the service identifier header in the request. If it detects that the current session corresponding to the cookie name has ended, it deletes the corresponding session data from the Redis cluster based on the cookie name of the current session and ends the current session, thus deleting the session.

[0084] In an exemplary embodiment, the method further includes: during the backend service upgrade process, obtaining the cookie name of the created session; determining the service identifier header of each created session according to the frontend service corresponding to each created session; and updating the correspondence between the cookie name and the service identifier header in the configuration center according to the cookie name and the service identifier header of each created session.

[0085] It is understandable that when the backend server upgrades the functionality corresponding to the session management method provided in this application from the initial processing logic, for existing sessions, the mapping between the cookie name and the service identifier header is updated in the configuration center based on the cookie name and service identifier header of the existing session, achieving a smooth transition without restarting the service. The service identifier header can be entered by the developer during the backend service upgrade, or it can be obtained by the backend service through interaction with the frontend service; this embodiment does not impose any restrictions on this.

[0086] In one alternative implementation, refer to Figure 4 A browser runs three front-end services: A, B, and C. Different ports on the same IP address correspond to different front-end services. Traditionally, setting the same cookie name for the same IP address leads to session conflicts. The session management method provided in this application addresses this by having each front-end service add its own service identifier header when accessing a back-end service. This allows the back-end service to distinguish between requests from different front-end services and provide sessions with different cookie names for each, thus enabling simultaneous service provision to front-ends A, B, and C.

[0087] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0088] Based on the same inventive concept, this application also provides a session management device for implementing the session management method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more session management device embodiments provided below can be found in the limitations of the session management method described above, and will not be repeated here.

[0089] In one exemplary embodiment, such as Figure 5 As shown, a session management device is provided, comprising:

[0090] The receiving module 502 is used to receive a login request from the first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service.

[0091] The query module 504 is used to query the corresponding cookie name in the configuration center based on the service identifier header.

[0092] Create module 506 to create a corresponding session based on the cookie name.

[0093] Response module 508 is used to generate response information based on the cookie name and send the response information back to the browser.

[0094] In the aforementioned session management device, a login request is received from a first front-end service. The login request carries a service identifier header. The first front-end service runs in a browser, and the browser runs at least one front-end service. Based on the service identifier header, the corresponding cookie name is queried from the configuration center. Based on the cookie name, a corresponding session is created. Response information is generated based on the cookie name and sent back to the browser. By assigning different cookie names to each front-end service running in the same browser, users can access the same back-end service through multiple front-end services in the same browser, seamlessly switching between different identities without exiting and creating a new session, thus improving user experience and operational efficiency. Furthermore, assigning a session cookie name through the service identifier header of each front-end service resolves session conflicts between multiple front-end services on the same browser.

[0095] In an exemplary embodiment, the session management device further includes an authorization module, wherein the login request also carries login information; the authorization module is used to perform identity authentication based on the login information; after successful identity authentication, authorize access to resources; associate the authorization information for accessing resources with a cookie name, and store the authorization information in the session.

[0096] In an exemplary embodiment, the session management device further includes a processing module; the processing module is configured to receive an access request from a second front-end service; the access request carries a target service identifier header and a target cookie name obtained by the browser; the target cookie name is verified according to the target service identifier header; after successful verification, the corresponding target session is determined according to the target cookie name; the access request is processed according to the target session, and the corresponding processing data is returned.

[0097] In one exemplary embodiment, the processing module is further configured to return an access failure message to the browser if the verification fails.

[0098] In one exemplary embodiment, the session management device further includes a storage module; the storage module is used to store the session data of each session in a Redis cluster according to the cookie name of each session during the operation of each session.

[0099] In one exemplary embodiment, the storage module is further configured to, if it detects that the current session has ended, delete the corresponding session data from the Redis cluster based on the cookie name of the current session and terminate the current session.

[0100] In an exemplary embodiment, the session management device further includes an update module; the update module is used to obtain the cookie name of the created session during the backend service upgrade process; determine the service identifier header of each created session according to the frontend service corresponding to each created session; and update the correspondence between the cookie name and the service identifier header in the configuration center according to the cookie name and the service identifier header of each created session.

[0101] Each module in the aforementioned session management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the corresponding operations of each module.

[0102] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a session management method.

[0103] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0104] In one exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: receiving a login request from a first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service; querying the corresponding cookie name in a configuration center based on the service identifier header; creating a corresponding session based on the cookie name; generating response information based on the cookie name, and sending the response information back to the browser.

[0105] In one embodiment, when the processor executes the computer program, it further performs the following steps: authenticating the user based on login information; authorizing access to resources after successful authentication; associating the authorization information for accessing the resources with a cookie name and storing the authorization information in the session.

[0106] In one embodiment, when the processor executes the computer program, it further performs the following steps: receiving an access request from a second front-end service; the access request carries a target service identifier header and a target cookie name obtained by the browser; verifying the target cookie name based on the target service identifier header; after successful verification, determining the corresponding target session based on the target cookie name; processing the access request based on the target session and returning the corresponding processing data.

[0107] In one embodiment, the processor, when executing the computer program, also performs the following steps: if verification fails, returns an access failure message to the browser.

[0108] In one embodiment, when the processor executes the computer program, it further performs the following steps: during the operation of each session, storing the session data of each session in the Redis cluster according to the cookie name of each session.

[0109] In one embodiment, when the processor executes the computer program, it further performs the following steps: if it detects that the current session has ended, it deletes the corresponding session data from the Redis cluster based on the cookie name of the current session and ends the current session.

[0110] In one embodiment, when the processor executes the computer program, it further performs the following steps: during the backend service upgrade process, obtaining the cookie name of the created session; determining the service identifier header of each created session based on the frontend service corresponding to each created session; and updating the correspondence between the cookie name and the service identifier header in the configuration center based on the cookie name and the service identifier header of each created session.

[0111] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: receiving a login request from a first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service; querying the corresponding cookie name in the configuration center according to the service identifier header; creating a corresponding session according to the cookie name; generating response information according to the cookie name, and sending the response information back to the browser.

[0112] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: authenticating the user based on login information; authorizing access to resources after successful authentication; associating the authorization information for accessing the resources with a cookie name and storing the authorization information in the session.

[0113] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: receiving an access request from a second front-end service; the access request carries a target service identifier header and a target cookie name obtained by the browser; verifying the target cookie name based on the target service identifier header; after successful verification, determining the corresponding target session based on the target cookie name; processing the access request based on the target session and returning the corresponding processing data.

[0114] In one embodiment, when the computer program is executed by the processor, it also performs the following steps: if the verification fails, it returns an access failure message to the browser.

[0115] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: during the operation of each session, storing the session data of each session in the Redis cluster according to the cookie name of each session.

[0116] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if it is detected that the current session has ended, delete the corresponding session data from the Redis cluster according to the cookie name of the current session, and end the current session.

[0117] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: during the backend service upgrade process, obtaining the cookie name of the created session; determining the service identifier header of each created session according to the frontend service corresponding to each created session; and updating the correspondence between the cookie name and the service identifier header in the configuration center according to the cookie name and the service identifier header of each created session.

[0118] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0119] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. The memory, database, or other media mentioned in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0120] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0121] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A session management method, characterized in that, The method is applied to a backend server, and the method includes: Receive a login request from a first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service; the service identifier header is used to distinguish different front-end services. Based on the service identifier header, the corresponding cookie name is queried in the configuration center; wherein, the configuration center is the Nacos configuration center, which stores the mapping relationship between the service identifier headers of each front-end service and the corresponding cookie names; the back-end server adopts the Shiro framework, and a custom ShiroSessionManager class inherits the framework's DefaultWebSessionManager class for flexible session management; the onStart method is overridden, and the storeSessionId method called therein is modified to a new custom method; through the custom storeSessionId method, a cookie name is assigned to the request based on the requested service identifier header; the mapping relationship between different service identifier headers and cookie names is stored in the Nacos configuration center; Create a corresponding session based on the cookie name; A response is generated based on the cookie name, and the response is sent back to the browser.

2. The method according to claim 1, characterized in that, The login request also carries login information; after creating the corresponding session based on the cookie name, the method further includes: Identity authentication is performed based on the login information; After successful identity authentication, access to resources is authorized; The authorization information for accessing the resource is associated with the cookie name, and the authorization information is stored in the session.

3. The method according to claim 2, characterized in that, The method further includes: Receive an access request from the second front-end service; the access request carries a target service identifier header and the target cookie name obtained by the browser query; The target cookie name is verified based on the target service identifier header; After successful verification, the corresponding target session is determined based on the target cookie name; The access request is processed according to the target session, and the corresponding processing data is returned.

4. The method according to claim 3, characterized in that, After verifying the target cookie name based on the target service identifier header, the method further includes: If verification fails, a message indicating access failure will be returned to the browser.

5. The method according to claim 1, characterized in that, The method further includes: During the operation of each session, the session data of each session is stored in the Redis cluster according to the cookie name of each session.

6. The method according to claim 5, characterized in that, The method further includes: If it is detected that the current session has ended, the corresponding session data is deleted from the Redis cluster according to the cookie name of the current session, and the current session is terminated.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: During the backend service upgrade process, obtain the cookie name of the created session; Based on the front-end service corresponding to each created session, determine the service identifier header for each created session; Update the mapping between cookie names and service identifier headers in the configuration center based on the cookie names and service identifier headers of each created session.

8. A session management device, characterized in that, The device is used in a backend server, and the device includes: A receiving module is used to receive a login request from a first front-end service; the login request carries a service identifier header; the first front-end service runs in a browser, and the browser runs at least one front-end service; the service identifier header is used to distinguish different front-end services. The query module is used to query the corresponding cookie name in the configuration center based on the service identifier header. The configuration center is the Nacos configuration center, which stores the mapping relationship between the service identifier headers of each frontend service and their corresponding cookie names. The backend server uses the Shiro framework, and a custom ShiroSessionManager class inherits from the framework's DefaultWebSessionManager class for flexible session management. The onStart method is overridden, and the storeSessionId method called within it is modified to a new custom method. The custom storeSessionId method assigns a cookie name to the request based on the requested service identifier header. The mapping relationship between different service identifier headers and cookie names is stored in the Nacos configuration center. A module is created to generate a corresponding session based on the cookie name; The response module is used to generate response information based on the cookie name and send the response information back to the browser.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images