Cross-subsystem login method, communication system, and storage medium

Abstract

Embodiments of the present application disclose a cross-subsystem login method, a communication system and a storage medium. The cross-subsystem login method comprises the following steps: when detecting a login request of a first ID which has logged in a second subsystem, sending a first request to a third subsystem, the first request being used for the third subsystem to determine whether to authorize the first ID to log in a first subsystem; the first ID being a user ID assigned by the second subsystem and used for requesting to log in the second subsystem; receiving a first response sent by the third subsystem; when the first response indicates that the first ID is allowed to log in the first subsystem, sending a second request to a fourth subsystem based on the first ID, the second request being used for requesting a second ID; the second ID pointing to a target page of the first subsystem requested by the first ID to log in; receiving a second response sent by the third subsystem; and when the second response contains the second ID, allowing the first ID to log in the target page.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a cross-subsystem login method, a communication system and a storage medium. BACKGROUND

[0002] In some cases, a service needs to be supported by multiple subsystems. Different subsystems are used to perform different service functions. The introduction of multiple subsystems can achieve the separation of service logic, the information isolation of each subsystem, and the more adaptive service logic of each subsystem to the service functions to be implemented, and the development difficulty is reduced to improve the development efficiency, system scalability and operation flexibility. In general, different subsystems are allocated with different user identities (ID). Generally, the ID allocated by a subsystem can only be used to log in to the subsystem, but cannot be used to log in to other subsystems. Therefore, if a user needs to hold multiple accounts of the subsystems to log in to the corresponding subsystems, it will cause cumbersome operation and low use efficiency. Therefore, Single Sign-On (SSO) emerges as the times require. SSO is an authentication mechanism that allows users to access multiple subsystems using a single identity credential. However, it is found in practice that SSO will fail in some special scenarios. SUMMARY

[0003] Therefore, the main purpose of the present application is to provide a cross-subsystem login method, a communication device and a storage medium.

[0004] The technical solution of the present application is implemented as follows:

[0005] The embodiment of the present application provides a cross-subsystem login method, which is executed by a first subsystem and includes the following steps:

[0006] When it is detected that a login request of a first ID (first identity) logged in a second subsystem is detected, a first request is sent to a third subsystem, the first request being used for the third subsystem to determine whether to authorize the first ID to log in to the first subsystem; the first ID being a user ID allocated by the second subsystem and used for a user ID requesting to log in to the second subsystem;

[0007] A first response sent by the third subsystem is received;

[0008] When the first response indicates that the first ID is allowed to log in to the first subsystem, a second request is sent to a fourth subsystem based on the first ID, the second request being used for requesting a second ID; the second ID pointing to a target page of the first subsystem requested by the first ID to log in to;

[0009] A second response sent by the third subsystem is received;

[0010] If the second response contains the second ID, the first ID is allowed to log in to the target page.

[0011] Based on the above scheme, the step of allowing the first ID to log in to the target page when the second response contains the second ID includes:

[0012] Establish the association between the first ID and the second ID;

[0013] Based on the aforementioned association, perform permission verification for logging into the first subsystem using the first ID;

[0014] Once the permission verification is successful, the target page is displayed based on the second ID.

[0015] Based on the above scheme, establishing the association between the first ID and the second ID includes:

[0016] The first ID and the second ID are stored in the session space corresponding to the login request; different login requests correspond to different sessions, and different sessions have different session spaces.

[0017] Based on the above scheme, the login request includes a login first URL (first unified resource address); the first URL points to the first subsystem; and displaying the target page according to the second ID upon successful permission verification includes:

[0018] Generate a second URL based on the second ID and the first URL;

[0019] The target page is displayed according to the second URL.

[0020] The second aspect provides a cross-subsystem login method, executed by the second subsystem, including:

[0021] When logging into the target page of the first subsystem, the first ID and the second ID are cached in the fourth subsystem; the first ID is the user ID assigned by the second subsystem and is used to request login to the first subsystem; the second ID points to the target page of the first subsystem that the first ID requests to log in; the first ID and the second ID are sent to the fourth subsystem for logging into the target page of the first subsystem after the third subsystem authorizes the first ID to log in to the first subsystem.

[0022] Send a login request to the first subsystem; the login request includes at least the first ID.

[0023] Based on the above scheme, the login request further includes: the first URL; the first URL points to the first subsystem; the first URL and the second ID are used to generate a second URL for logging into the target page.

[0024] The third aspect provides a cross-subsystem login method, executed by the third subsystem, including:

[0025] Receive the first request sent by the first subsystem;

[0026] Based on the first request, determine whether the first ID has permission to log in to the second subsystem. The first ID is the user ID assigned by the second subsystem and is used to request login to the first subsystem.

[0027] Send a first response to the first subsystem, the first response being used to indicate to the first subsystem whether the first ID has permission to log in to the first subsystem.

[0028] Based on the above scheme, determining whether the first ID has permission to log in to the second subsystem according to the first request includes:

[0029] When the first ID has successfully logged into the second subsystem, determine whether the first ID specifies a type ID;

[0030] When specifying a type ID in the first ID, it is determined that the first ID has permission to log in to the first subsystem.

[0031] Based on the above scheme, the method further includes:

[0032] The system determines whether the first ID has successfully logged into the second subsystem based on the cookie of the second subsystem.

[0033] The fourth aspect provides a communication system, comprising:

[0034] The first subsystem is used to execute the method described in any one of the technical solutions of the first aspect;

[0035] The second subsystem is used to execute the method described in any one of the technical solutions of the second aspect;

[0036] The third subsystem is used to perform the method described by any one of the techniques of the third aspect;

[0037] The fourth subsystem is used to cache at least the first ID and the second ID provided by the third subsystem.

[0038] The fifth aspect provides a computer storage medium storing computer-readable instructions, which, when executed, can perform the methods described in any one of the technical solutions of the first aspect, the second aspect, and the third aspect.

[0039] A sixth aspect provides a computer-readable instruction, characterized in that, when executed, the computer-readable instruction is capable of performing the method described in any of the technical solutions of the first, second, and third aspects described above.

[0040] The present invention provides a cross-subsystem login method, communication device, and storage medium. When a first ID in a second subsystem requests to log in to a first subsystem, the first subsystem requests a third subsystem to confirm that the first ID has permission to log in, and then obtains the second ID corresponding to the first ID from a fourth subsystem. In this way, in the SSO scenario, the first ID of the first subsystem can be allowed to successfully log in to the second subsystem across regions or subsystems, reducing the probability of SSO failure and improving the login success rate. Attached Figure Description

[0041] Figure 1 A flowchart illustrating a cross-subsystem login method provided in some embodiments of the present invention;

[0042] Figure 2 A flowchart illustrating a cross-subsystem login method provided in some embodiments of the present invention;

[0043] Figure 3 A flowchart illustrating a cross-subsystem login method provided in some embodiments of the present invention;

[0044] Figure 4 A flowchart illustrating a cross-subsystem login method provided in some embodiments of the present invention;

[0045] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention.

[0046] Figure 6 This is a schematic diagram of a communication system provided in an embodiment of the present invention. Detailed Implementation

[0047] SSO (Signal for Server Authentication) is implemented using cookies, sessions, and tokens. While SSO simplifies the user login experience and centrally manages user identities, it has limitations in cross-system authorization. For example, SSO can easily fail when multiple subsystems require separate authentication. For instance, after logging into subsystem A, if redirected to subsystem B, subsystem B will authenticate the login account based on its own authentication method. Since the ID from subsystem A originally lacked permissions for subsystem B, the login to subsystem B will fail. Another example: if subsystem B is a multi-page subsystem, the URL (Uniform Resource Locator) sent by the login request from subsystem A might execute a specific page within subsystem B. However, during cross-domain redirection, information pointing to that specific page in the URL can be easily lost, also causing SSO login to fail in subsystem B.

[0048] This invention provides a cross-subsystem login method, communication device, and storage medium, aiming to solve the aforementioned SSO login failure.

[0049] like Figure 1 As shown in the embodiments of this disclosure, a cross-subsystem login method is provided, which may include:

[0050] S1101: When a login request from a first ID already logged into the second subsystem is detected, a first request is sent to the third subsystem. The first request is used by the third subsystem to determine whether to authorize the first ID to log into the first subsystem. The first ID is a user ID assigned by the second subsystem and is used to request login to the second subsystem.

[0051] S1102: Receive the first response sent by the third subsystem;

[0052] S1103: When the first response indicates that the first ID is allowed to log in to the first subsystem, a second request is sent to the fourth subsystem based on the first ID. The second request is used to request a second ID. The second ID points to the target page of the first subsystem that the first ID requested to log in to.

[0053] S1104: Receive the second response sent by the third subsystem;

[0054] S1105: When the second response contains the second ID, the first ID is allowed to log in to the target page.

[0055] In some embodiments, the first subsystem, the second subsystem, the third subsystem, and the fourth subsystem may be different subsystems of the same system, and these subsystems belong to different security domains. For example, the first subsystem, the second subsystem, the third subsystem, and the fourth subsystem may be different subsystems within the same distributed system. The first subsystem, the second subsystem, the third subsystem, and the fourth subsystem may implement different business functions for the same or one type of business.

[0056] Taking e-commerce as an example, the first subsystem could be the store / merchant subsystem (or simply the store / merchant system), the second subsystem could be the store operations backend subsystem (or store operations backend system), the third subsystem could be the single sign-on management subsystem (i.e., the single sign-on system), and the fourth subsystem could be a caching system (e.g., Redis). Of course, this is an example of e-commerce; in practice, it could also be different subsystems for school management, company operations, etc.

[0057] The first ID can be assigned to a user in the second subsystem. Normally, the first ID can only be used to log in to the first subsystem. However, with SSO, the first ID can be used to log in to multiple subsystems managed by SSO. For example, the third subsystem can simultaneously manage logins to the first and second subsystems.

[0058] However, in this embodiment, the second subsystem requesting login with the first ID has its own authentication process. Since the first ID is not an ID assigned by the second subsystem, it has no right to log in to the first subsystem, thus causing SSO failure. However, in this embodiment, when the first subsystem detects a login request with the first ID, it sends a first request to the third subsystem for authentication. This method uses the third subsystem to perform unified authentication management for logins from the first and second subsystems, ensuring login security.

[0059] In some embodiments, the login request provided by the second subsystem includes at least a first ID.

[0060] In some embodiments, the login request may also include other account information for the first ID, such as account type information. For example, the account type information may be a specific string. Different account types may have different strings, but the specific meaning represented by the string is transparent to the second, third, and fourth subsystems. That is, the account type information can be represented by a specific string. In some embodiments, different types of first IDs can be authorized by the third subsystem to log in to different types of pages on the first subsystem. In this case, if the page on the second subsystem requested by the first ID is not the page authorized for its login, the third subsystem may inform the first subsystem to reject the login of the first ID through a first response. In some embodiments, the string may be a referent for the account type. This referent may be appended to the beginning or end of the first ID. For example, the referent may be a suffix of a specified length for the first ID. In some embodiments, the first subsystem may perform formal and / or type validation on the first ID. If the validation fails, the login of the first ID can be directly rejected; if the validation is successful, the authentication request to the third subsystem continues.

[0061] In some embodiments, the login request sent by the second subsystem may include a second ID. If the second ID in the login request is not lost, the first subsystem, upon determining the target page that allows the first ID to log in based on the first response from the third subsystem, can also directly allow the first ID to log in and display the target page on the first ID's user interface. This reduces unnecessary interaction between the first subsystem and the fourth subsystem that caches the second ID, provided the second ID is not lost in the login request. If the second ID carried in the login request is lost, the first subsystem can request the second ID from the fourth subsystem based on the first ID.

[0062] In some embodiments, the first response may indicate whether the first ID is allowed to log in to the first subsystem. For example, when the first response indicates that the first ID is allowed to log in to the first subsystem, the first response may also include a rejection indication and / or a reason for failure.

[0063] In some embodiments, after receiving a first response indicating that a first ID is denied login to the first subsystem, the first subsystem provides a login response to the second subsystem based on the first response. This login response may include the first response, etc., so that the second subsystem can display the login failure or the reason for the failure.

[0064] If the initial response indicates that login is permitted, the first subsystem will retrieve the second ID of the target page for the login request from the fourth subsystem. For example, the second ID could be a page identifier. In e-commerce, for instance, the second ID could be a store identifier. One second ID can point to one or more related pages in the first subsystem; that is, there can be one or more target pages.

[0065] In some embodiments, the second request may include at least the first ID.

[0066] In some embodiments, the second request may further include relevant user information such as the account type indicating the first ID. For example, the second request may include the aforementioned string.

[0067] In some embodiments, if the first subsystem pre-stores the first ID and the second ID in the fourth subsystem, the first subsystem will receive the second ID returned by the fourth subsystem, and the second response will carry the second ID. If the first subsystem has not pre-stored the first ID and the second ID in the fourth subsystem, the first subsystem will be unable to successfully obtain the second ID from the fourth subsystem, and the second response may indicate failure.

[0068] In some embodiments, the first subsystem will successfully obtain the second ID from the fourth subsystem, and then the second subsystem will be able to accurately locate the target page for the login request of the first ID, thereby enabling the user to easily log in to the target page of the second subsystem without having to enter an ID and / or password from the second subsystem.

[0069] In some embodiments, allowing the first ID to log in to the target page when the second response includes the second ID includes:

[0070] Establish the association between the first ID and the second ID;

[0071] Based on the aforementioned association, perform permission verification for logging into the first subsystem using the first ID;

[0072] Once the permission verification is successful, the target page is displayed based on the second ID.

[0073] In some embodiments, the first subsystem requires additional authentication to further ensure the login security of the second subsystem. After obtaining the second ID from the fourth subsystem, the first subsystem establishes an association between the first ID and the second ID. This association can be used by the first subsystem for temporary authentication of login to the first subsystem using the first ID. For example, in e-commerce, the first ID might be the user ID of an operator in the store's backend system. This operator doesn't belong to any particular store, but to ensure the security of store logins, authentication is required, yet authentication information for store logins is lacking. In this embodiment, establishing the association between the first ID and the second ID can be considered as establishing temporary authentication information. After establishing this association, the first subsystem performs permission verification based on it, thus enabling fast login across subsystems using the first ID without modifying the original login logic of the first subsystem.

[0074] In some embodiments, when the permission verification passes, the target page is displayed according to the second ID; when the permission verification fails, the login request of the first ID is rejected.

[0075] In some embodiments, establishing the association between the first ID and the second ID further includes: when the page type of the target page pointed to by the second ID matches the account type of the first ID, establishing an association between the first ID, the second ID, and the page type information of the first subsystem authorized for login by the account type of the first ID. For example, if the account type of the first ID is "financial personnel," then only financial-related business in the first subsystem is allowed to be logged in. If the account type of the first ID is "sales management page," then only the sales management page of the first subsystem is allowed to be logged in. Thus, when the first ID performs cross-page navigation after logging into the first subsystem, it can only be redirected to the page it is authorized to log in to. In some embodiments, the second ID may refer to different types of pages. For example, if the second ID is a store ID, it will point to all pages of a specific page. In this case, by establishing an association between the first ID, the second ID, and the page type information of the first subsystem authorized for login by the account type of the first ID, login to pages of types that the first ID is not authorized to log in to can be restricted. When the second ID is the page ID of a page or the ID of a certain type of page, it is sufficient to establish an association between the first ID and the second ID. This is because, in this case, when jumping between pages of different types, the association between the first ID and the second ID cannot satisfy the permission verification of the first subsystem.

[0076] In some embodiments, establishing the association between the first ID and the second ID includes: storing the first ID and the second ID in the session space corresponding to the login request; different login requests correspond to different sessions, and different sessions have different session spaces.

[0077] In this embodiment, since the first subsystem sets up separate sessions for different login requests from the second subsystem and stores the aforementioned association relationships in the session space corresponding to each session, information isolation between different second IDs can be achieved, ensuring the security of the second ID information. Furthermore, by managing association relationships and / or login requests from the second subsystem through sessions, the association relationship between the first ID and the second ID automatically becomes invalid at the end of the session and will be overwritten by other information from the first subsystem. The lifecycle of the association relationship is managed through the session lifecycle, thereby further ensuring the security of the second ID and the page information associated with it.

[0078] In some embodiments, the method further includes:

[0079] When the first subsystem detects the end of the session, it sends a third request to the fourth subsystem. This third request requests the fourth subsystem to delete the second ID corresponding to the first ID. This reduces information security issues caused by caching in the fourth subsystem.

[0080] In some embodiments, the login request includes a login first URL; the first URL points to the first subsystem; and the step of displaying the target page according to the second ID upon successful permission verification includes:

[0081] Generate a second URL based on the second ID and the first URL;

[0082] The target page is displayed according to the second URL.

[0083] In some embodiments, the first URL may point to at least the main page or root page of the first subsystem. Of course, the root page of the second subsystem is not the page on which the first ID requests login. In this embodiment, after obtaining the second ID, the first subsystem generates a first URL and a second URL based on the second ID, and the second URL directly points to the target page on which the first ID requests login.

[0084] In some embodiments, when navigating across subsystems, the URL carried in the login request may not discard the second ID or the information pointing to the target page corresponding to the second ID. In this case, after obtaining the second ID, it is possible to determine whether to use the URL carried in the login request to log in to the target page through matching.

[0085] In some embodiments, after receiving a login request from the second subsystem, the first subsystem automatically checks whether the URL carried in the login request corresponds to a second ID. If it does, the corresponding information is discarded, and the second ID obtained from the fourth subsystem is appended to the first URL to generate a second URL. By generating the second URL through this URL concatenation, even if the second ID or the information corresponding to the second ID is lost in the URL during cross-region or cross-subsystem login, accurate login to the target page can still be achieved.

[0086] like Figure 2 As shown, this disclosure provides a cross-subsystem login method, executed by a second subsystem, including:

[0087] S2101: During the login operation of the target page of the first subsystem, the first ID and the second ID are cached in the fourth subsystem; the first ID is the user ID assigned by the second subsystem and is used to request the login of the first subsystem; the second ID points to the target page of the first subsystem requested by the first ID; the first ID and the second ID are sent to the fourth subsystem for logging into the target page of the first subsystem after the third subsystem authorizes the first ID to log into the first subsystem.

[0088] S2102: Send a login request to the first subsystem; the login request includes at least the first ID.

[0089] In this embodiment of the disclosure, when the first subsystem detects a login operation that requires redirection to the second subsystem, it caches the first ID and the second ID in the fourth subsystem to facilitate the second subsystem's request from the fourth subsystem.

[0090] In some embodiments, S2101 and S2102 do not have a fixed order. Considering login efficiency, S2101 and S2102 can be executed in parallel. To ensure that the first subsystem can successfully obtain the second ID with the highest probability, S2101 can be executed first and then S2102.

[0091] In some embodiments, the method further includes:

[0092] Receive the cache response from the fourth subsystem. This cache response indicates whether the first ID and the second ID were successfully cached. The fourth subsystem will store the first ID and the second ID accordingly.

[0093] In some embodiments, the second subsystem may send a login request to the first subsystem after receiving a cache response indicating successful caching.

[0094] In some embodiments, when caching the first ID and the second ID in the fourth subsystem, the account type information (e.g., a reference symbol) of the first ID can also be sent to the fourth subsystem cache, so that the first subsystem can subsequently open a page matching the account type to the first ID.

[0095] In some embodiments, the login request further includes: the first URL; the first URL points to the first subsystem; the first URL and the second ID are used to generate a second URL for logging into the target page.

[0096] In some embodiments, the second subsystem may include one or more lists. These lists may store entity IDs for different entities within the first subsystem, such as different shops. Different entity IDs correspond to different pages. Detecting a user action applied to one or more entity IDs indicates a login operation to the first subsystem. For example, the second subsystem may cache at least the URLs of specified pages, such as the root page, for logging into the first subsystem; these URLs can be directly used as the first URL. Alternatively, the second subsystem may cache URLs corresponding to different entity IDs as the first URL carried in the login request.

[0097] In some embodiments, the method may further include:

[0098] Before sending a login request and / or caching the first ID and the second ID in the fourth subsystem, the second subsystem determines whether the first ID has permission to log in to the second subsystem or the target page of the second subsystem requested by the first ID based on the account type of the first ID. If the first ID does not have permission to log in, the login request of the first ID is rejected, and the sending of the login request and / or unnecessary caching of the first ID and the second ID in the fourth subsystem is stopped.

[0099] like Figure 3 As shown, this disclosure provides a cross-subsystem login method, executed by a third subsystem, including:

[0100] S3101: Receive the first request sent by the first subsystem;

[0101] S3102: Determine whether the first ID has permission to log in to the second subsystem based on the first request. The first ID is a user ID assigned by the second subsystem and is used to request login to the first subsystem.

[0102] S3103: Send a first response to the first subsystem, the first response being used to indicate to the first subsystem whether the first ID has permission to log in to the first subsystem.

[0103] In some embodiments, the third subsystem is the SSO management subsystem, which can be used for login authentication across regions or subsystems. After receiving the first request, the SSO determines whether the first ID has permission to log in to the second subsystem. For example, after receiving the first ID, the SSO can perform authentication based on a locally stored list of accounts in the second subsystem that can log in to the first subsystem. Alternatively, it can determine whether the first ID has successfully logged into the second subsystem based on the second subsystem's cookie. Furthermore, the third subsystem records the login status of its management ID. If it detects that the first ID has already been authenticated using a token, password, or other methods, it checks whether the cookie generated by the current login request and the previous cookie in the second subsystem are from the same source. If they are, the first ID is considered to have permission to log in; otherwise, the first ID is considered not to have permission to log in to the first subsystem. Here, the previous cookie in the second subsystem can be the cookie generated during the first account's previous login, for example, the cookie verified by the SSO subsystem when the first account logged in to the second subsystem.

[0104] In some embodiments, when performing same-origin verification based on cookies, the system can determine whether to trigger the first account to log in to the second subsystem again based on the caching time of the previous cookie of the second subsystem. For example, if the time interval between the caching time of the previous cookie of the second subsystem and the current time is greater than a preset duration, the SSO subsystem sends a re-login reminder to the second subsystem during the security period. A re-login prompt can pop up on the system page of the second subsystem. For example, a pop-up window for re-login to the second subsystem can be displayed on the client page of the second subsystem. This pop-up window may include the input of account information and verification information. The account information database already contains the first account requesting to log in to the first subsystem. The verification information may be a password, SMS verification code, or dynamically assigned token, etc. The user needs to log in again by inputting the verification information. Alternatively, a QR code scanning page can be displayed on the client of the second subsystem, allowing the user to log in to the second subsystem again by scanning a QR code using a mobile phone or other device that supports QR code scanning.

[0105] In some embodiments, determining whether the first ID has permission to log in to the second subsystem based on the first request includes:

[0106] When the first ID has successfully logged into the second subsystem, determine whether the first ID specifies a type ID;

[0107] When specifying a type ID in the first ID, it is determined that the first ID has permission to log in to the first subsystem.

[0108] For example, the second subsystem may have different types of accounts, and only accounts of a specific type may be allowed to log in to the first subsystem. In this case, authentication can be achieved by verifying whether the first ID is an ID of the specified type.

[0109] In some embodiments, the system determines whether the first ID has successfully logged into the second subsystem based on the cookie of the second subsystem.

[0110] This disclosure uses e-commerce business as an example, but the specific implementation is not limited to e-commerce business. For example... Figure 4 As shown, this disclosure provides a cross-subsystem login method that may include:

[0111] Step 1: Divide the e-commerce system into a store operation backend subsystem, a store merchant subsystem, an SSO subsystem, and Redis.

[0112] Step 2: When store operators log in to the store operation backend subsystem, they will detect the operation of being redirected from the store operation backend subsystem to the store page of the store merchant subsystem.

[0113] Step 3: The store operation backend subsystem will cache the user ID and store ID in Redis.

[0114] Step 4: If the corresponding store page in the store merchant subsystem detects that the user is not logged into the SSO subsystem, redirect to the SSO subsystem.

[0115] Step 5: If the SSO subsystem detects that the user is an operations staff member's ID or detects a same-origin cookie, it will allow the operations staff member to log in and notify the store merchant subsystem to grant permission.

[0116] Step 6: The store merchant subsystem retrieves the store ID requested by the user from Redis. If it cannot be retrieved, it means the user's redirection did not originate from the store operations backend, authorization failed, and the redirection will display an error page indicating insufficient permissions, terminating the login process.

[0117] Step 7: Establish the association between the user ID and the store ID, and construct the URL that the user will access based on the store ID.

[0118] Step 8: Perform routine authentication of user IDs based on the relationship between the store and merchant subsystems;

[0119] Step 9: After successful authentication, redirect the user to the operations personnel's display page based on the URL obtained above.

[0120] To isolate information from different stores, a session will be established by requesting to log in to the store page based on the ID. Different stores correspond to different sessions, and the aforementioned relationship is stored in the session space of the corresponding session.

[0121] This disclosure uses e-commerce business as an example to provide a cross-subsystem login method, which may include:

[0122] The store operation subsystem and the merchant subsystem both use the same single sign-on (SSO) subsystem.

[0123] Users in the store operations role can access the store list and click "Manage".

[0124] Retrieve the store ID as the value, and use the user's ID and a specific suffix as the key. Store the key-value pairs in Redis to prevent concurrency issues.

[0125] The user is redirected to the merchant-side page of the store's merchant subsystem by taking on the role of store operator.

[0126] The store merchant subsystem detected a redirect to the SSO subsystem. The SSO subsystem detected the store operations subsystem cookie and concluded that the user was logged in.

[0127] The SSO subsystem redirects to the merchant side of the store merchant subsystem. After obtaining the user information, it determines that the user is a backend operations role and does not belong to a store.

[0128] At this point, the API is called to query Redis. If a store ID is found, it is retrieved, appended to the URL, and then immediately deleted.

[0129] The user's ID and store ID are cached in session storage, and the user is assigned an ID; otherwise, the user is not authorized to be redirected to a 401 page to display an error message.

[0130] The store's merchant subsystem performs another verification. At this point, the user information has passed the verification completely, and the user is allowed to enter the merchant's page.

[0131] This disclosure provides a first subsystem, including: a sending module, a receiving module, and a processing module;

[0132] The sending module is configured to send a first request to the third subsystem when a login request from a first ID already logged into the second subsystem is detected. The first request is used by the third subsystem to determine whether to authorize the first ID to log into the first subsystem. The first ID is a user ID assigned by the second subsystem and is used to request the user ID to log into the second subsystem.

[0133] The receiving module is used to receive the first response sent by the third subsystem;

[0134] The sending module is further configured to send a second request to the fourth subsystem based on the first ID when the first response indicates that the first ID is allowed to log in to the first subsystem. The second request is used to request a second ID; the second ID points to the target page of the first subsystem that the first ID requests to log in to.

[0135] The receiving module is also used to receive a second response sent by the third subsystem;

[0136] The processing module is configured to allow the first ID to log in to the target page when the second response contains the second ID.

[0137] In some embodiments, the processing module is used to establish an association between the first ID and the second ID; perform permission verification for logging into the first subsystem using the first ID based on the association; and display the target page according to the second ID when the permission verification is successful.

[0138] In some embodiments, the processing module is used to store the first ID and the second ID in the session space corresponding to the login request; different login requests correspond to different sessions, and different sessions have different session spaces.

[0139] In some embodiments, the login request includes a first login URL; the first URL points to the first subsystem; the processing module is configured to generate a second URL based on the second ID and the first URL; and display the target page based on the second URL.

[0140] In some embodiments, the first subsystem may correspond to one or more servers.

[0141] This disclosure provides a second subsystem. The second subsystem includes:

[0142] The caching module is used to cache a first ID and a second ID in the fourth subsystem during a login operation on the target page of the first subsystem. The first ID is a user ID assigned by the second subsystem and is used to request login to the first subsystem. The second ID points to the target page of the first subsystem that the first ID requests to log in. The first ID and the second ID are sent to the fourth subsystem for logging into the target page of the first subsystem after the third subsystem authorizes the first ID to log in to the first subsystem.

[0143] A sending module is used to send a login request to the first subsystem; the login request includes at least the first ID.

[0144] In some embodiments, the login request further includes: the first URL; the first URL points to the first subsystem; the first URL and the second ID are used to generate a second URL for logging into the target page.

[0145] In some embodiments, the second subsystem may correspond to one or more servers.

[0146] This disclosure provides a third subsystem, including: a receiving module for receiving a first request sent by a first subsystem; a processing module for determining, based on the first request, whether a first ID has permission to log in to a second subsystem, wherein the first ID is a user ID assigned by the second subsystem and used to request login to the first subsystem; and a sending module for sending a first response to the first subsystem, wherein the first response is used to indicate to the first subsystem whether the first ID has permission to log in to the first subsystem.

[0147] In some embodiments, the processing module is configured to determine whether the first ID specifies a type ID when the first ID has successfully logged into the second subsystem; and to determine whether the first ID has permission to log into the first subsystem when the first ID specifies a type ID.

[0148] In some embodiments, the processing module is configured to determine whether the first ID has successfully logged into the second subsystem based on the cookie of the second subsystem.

[0149] In some embodiments, the third subsystem may correspond to one or more servers.

[0150] In some embodiments, the aforementioned transmitting module and receiving module may correspond to a network interface or a transceiver antenna. The processing module may correspond to a processor.

[0151] Optional, such as Figure 5 As shown, this disclosure provides an electronic device. This electronic device can be used to form a communication system, a first subsystem, a second subsystem, a third subsystem, and / or a fourth subsystem. For example, the communication system, the first subsystem, the second subsystem, the third subsystem, and / or the fourth subsystem may include, for example... Figure 5 One or more electronic devices are shown. These electronic devices are connected via a local area network (LAN) or the internet, or via a direct connection port. For example... Figure 5As shown, the electronic device may include a processor 501 and a memory 502. The processor 501 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Here, the program executed by the processor 501 may be stored in the memory 502 connected to the processor 501 via a communication bus 503. The memory 502 may be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache.By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM). The memory 502 described in this embodiment of the invention is intended to include, but is not limited to, these and any other suitable types of memory 502. The memory 502 in this embodiment of the invention is used to store various types of data to support the operation of the processor 501. Examples of this data include: any computer programs operated by the processor 501, such as operating systems and applications; contact data; phonebook data; messages; pictures; videos, etc. The operating system contains various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks.

[0152] In some embodiments of the present invention, the memory 502 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0153] The processor 501 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 501 or by instructions in software form. The processor 501 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 502, and the processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method. In some embodiments, the embodiments described herein can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0154] like Figure 6 As shown in the embodiments of this disclosure, a communication system is also provided, including:

[0155] The first subsystem is used to execute any of the technical solutions described in the first aspect above.

[0156] The second subsystem is used to execute any of the technical solutions in the second aspect mentioned above.

[0157] The third subsystem is used to execute any of the technical solutions in the aforementioned third aspect.

[0158] The fourth subsystem is used to cache at least the first ID and the second ID provided by the third subsystem.

[0159] In some embodiments, the communication system may be a distributed system.

[0160] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or externally.

[0161] Another embodiment of the present invention provides a computer storage medium storing an executable program, which, when executed by a processor 501, implements the steps of a cross-subsystem login method applied to the endpoint device. For example, as... Figure 1 , Figure 2 , Figure 3 and / or Figure 4 One or more of the methods shown.

[0162] In some embodiments, the computer storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0163] It should be noted that the technical solutions described in the embodiments of the present invention can be combined arbitrarily without conflict.

[0164] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

Claims

1. A cross-subsystem login method, characterized in that, Executed by the first subsystem, including: Upon detecting a login request from a first ID already logged into the second subsystem, a first request is sent to the third subsystem. The first request is used by the third subsystem to determine whether to authorize the first ID to log into the first subsystem. The first ID is a user ID assigned by the second subsystem and is used to request login to the second subsystem. Receive the first response sent by the third subsystem; When the first response indicates that the first ID is allowed to log in to the first subsystem, a second request is sent to the fourth subsystem based on the first ID. The second request is used to request a second ID. The second ID points to the target page of the first subsystem that the first ID requested to log in to. Receive the second response sent by the third subsystem; When the second response contains the second ID, the first ID is allowed to log in to the target page; The first ID and the second ID are stored in the session space corresponding to the login request to establish an association between the first ID and the second ID; different login requests correspond to different sessions, and different sessions have different session spaces; when the session corresponding to the login request is released, the association between the first ID and the second ID in the session space automatically becomes invalid. Upon detecting the end of the session, a third request is sent to the fourth subsystem, which requests the fourth subsystem to delete the second ID corresponding to the first ID.

2. The method according to claim 1, characterized in that, The step of allowing the first ID to log in to the target page when the second response contains the second ID includes: Based on the aforementioned association, perform permission verification for logging into the first subsystem using the first ID; Once the permission verification is successful, the target page is displayed based on the second ID.

3. The method according to claim 2, characterized in that, The login request includes the first login URL; The first URL points to the first subsystem; The step of displaying the target page based on the second ID upon successful permission verification includes: Generate a second URL based on the second ID and the first URL; The target page is displayed according to the second URL.

4. A cross-subsystem login method, characterized in that, Executed by the second subsystem, including: When logging into the target page of the first subsystem, the first ID and the second ID are cached in the fourth subsystem. The first ID is a user ID assigned by the second subsystem and is used to request login to the first subsystem. The second ID points to the target page of the first subsystem that the first ID requests to log into. The first ID and the second ID are sent to the fourth subsystem for logging into the target page of the first subsystem after the third subsystem authorizes the first ID to log into the first subsystem. The association between the first ID and the second ID is stored in the session space. Different login requests correspond to different sessions, and different sessions have different session spaces. When the session corresponding to the login request is released, the association between the first ID and the second ID stored in the session space is automatically invalidated. When the fourth subsystem receives a third request sent by the first subsystem after the session ends, it deletes the second ID corresponding to the first ID. Send a login request to the first subsystem; the login request includes at least the first ID.

5. The method according to claim 4, characterized in that, The login request also includes: a first URL; the first URL points to the first subsystem; the first URL and the second ID are used to generate a second URL for logging into the target page.

6. A cross-subsystem login method, characterized in that, Executed by a third subsystem, including: Receive the first request sent by the first subsystem; Based on the first request, it is determined whether the first ID has permission to log in to the second subsystem. The first ID is a user ID assigned by the second subsystem and is used to request login to the first subsystem. Send a first response to the first subsystem, the first response being used to indicate to the first subsystem whether the first ID has permission to log in to the first subsystem; if the first ID has permission to log in to the first subsystem, the second ID corresponding to the first ID is used to log in to the target page of the first subsystem; The association between the first ID and the second ID is stored in the session space; different login requests correspond to different sessions, and different sessions have different session spaces; when the login request corresponds to the release of the session, the association between the first ID and the second ID stored in the session space automatically becomes invalid; the fourth subsystem is used to delete the second ID corresponding to the first ID after receiving a third request sent by the first subsystem after the session ends.

7. The method according to claim 6, characterized in that, The step of determining whether the first ID has permission to log in to the second subsystem based on the first request includes: When the first ID has successfully logged into the second subsystem, determine whether the first ID is a specified type ID; When the first ID is a specified type ID, it is determined that the first ID has permission to log in to the first subsystem.

8. The method according to claim 7, characterized in that, The method further includes: The system determines whether the first ID has successfully logged into the second subsystem based on the cookie of the second subsystem.

9. A communication system, characterized in that, include: A first subsystem is configured to perform the method described in any one of claims 1 to 3; The second subsystem is used to perform the method described in any one of claims 4 to 5; A third subsystem is configured to perform the method described in any one of claims 6 to 8; The fourth subsystem is used to cache at least the first ID and the second ID provided by the third subsystem.

10. A computer storage medium, characterized in that, The computer storage medium stores computer-readable instructions, which, when executed, can perform the method described in any one of claims 1 to 3, 4 to 5, and 6 to 8.

Images