Cross-subsystem login method, communication system and storage medium

Abstract

The embodiment of the invention discloses a cross-subsystem login method, a communication system and a storage medium. The cross-subsystem login method comprises the steps that when a login request for logging in a first ID of a second subsystem is detected, a first request is sent to a third subsystem, and the first request is used for the third subsystem to determine whether to authorize the first ID to log in the first subsystem or not; the first ID is a user ID distributed by the second subsystem and is used for requesting to log in the user ID of 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, a second request is sent to a fourth subsystem based on the first ID, and the second request is used for requesting a second ID; the second ID points to a target page of the first subsystem requested to be logged in by the first ID; 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 invention relates to the field of communication technology, and in particular to a cross-subsystem login method, a communication system and a storage medium. Background Art

[0002] In some cases, a business needs support from multiple subsystems. Different subsystems are used to perform different business functions. The introduction of multiple subsystems can achieve the separation of business logic. While isolating the information of each subsystem, the business logic of each subsystem is more compatible with the business functions to be implemented, and the development difficulty is reduced, so as to improve development efficiency, system scalability and operation and maintenance flexibility. Usually, different subsystems are assigned different user identities (Identity, ID). Generally, the ID assigned to a subsystem can only be used to log in to the subsystem, but not to log in to other subsystems. In this way, if a user needs to log in to the corresponding subsystems with accounts of multiple subsystems, it will lead to cumbersome operations and low efficiency. In view of this, Single Sign-On (SSO) came into being. SSO is an authentication mechanism that allows users to access multiple subsystems with a single identity credential. However, practice has found that SSO fails in some special scenarios. Summary of the invention

[0003] In view of this, the main purpose of the present invention is to provide a cross-subsystem login method, communication equipment and storage medium.

[0004] The technical solution of the present invention is achieved in this way: An embodiment of the present disclosure provides a cross-subsystem login method, which is executed by a first subsystem and includes: When a login request of a first ID (first identification) that has logged into the second subsystem is detected, a first request is sent to a third subsystem, where 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 a user ID to log into 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 to the first subsystem, a second request is sent to the fourth subsystem based on the first ID, where the second request is used to request a second ID; the second ID points to a target page of the first subsystem that the first ID requests to log in to; receiving a second response sent by the third subsystem; When the second response includes the second ID, the first ID is allowed to log in to the target page.

[0005] Based on the above solution, when the second response includes the second ID, allowing the first ID to log in to the target page includes: Establishing an association relationship between the first ID and the second ID; Performing an authority check for the first ID to log into the first subsystem based on the association relationship; When the authority check passes, the target page is displayed according to the second ID.

[0006] Based on the above solution, establishing the association relationship between the first ID and the second ID includes: The first ID and the second ID are stored correspondingly in the session space corresponding to the login request; different login requests correspond to different sessions, and different sessions have different session spaces.

[0007] Based on the above solution, the login request includes logging in to a first URL (first uniform resource address); the first URL points to the first subsystem; when the permission check passes, displaying the target page according to the second ID includes: Generate a second URL according to the second ID and the first URL; The target page is displayed according to the second URL.

[0008] A second aspect provides a cross-subsystem login method, which is performed by the second subsystem and includes: During the login operation of logging into the target page of the first subsystem, the first ID and the second ID are cached to the fourth subsystem; the first ID is the user ID assigned by the second subsystem and is used to request the user ID to log into the first subsystem; the second ID points to the target page of the first subsystem requested to be logged in 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 in to the first subsystem.

[0009] A login request is sent to the first subsystem; the login request includes at least the first ID.

[0010] Based on the above solution, the login request also 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.

[0011] A third aspect provides a cross-subsystem login method, which is executed by a third subsystem and includes: receiving a first request sent by a first subsystem; Determine whether the first ID has the authority to log in to the second subsystem according to the first request, where the first ID is a user ID assigned by the second subsystem and is used to request to log in to the first subsystem; A first response is sent to the first subsystem, where the first response is used to indicate to the first subsystem whether the first ID has the authority to log in to the first subsystem.

[0012] Based on the above solution, determining whether the first ID has the authority to log in to the second subsystem according to the first request includes: When the first ID has successfully logged into the second subsystem, determining whether the first ID specifies a type ID; When the type ID is specified for the first ID, it is determined that the first ID has the authority to log in to the first subsystem.

[0013] Based on the above scheme, the method also includes: Determine whether the first ID has successfully logged into the second subsystem based on the cookie of the second subsystem.

[0014] A fourth aspect provides a communication system, comprising: A first subsystem, configured to execute the method described in any one of the technical solutions of the first aspect; A second subsystem, configured to execute the method described in any one of the technical solutions of the second aspect; A third subsystem, configured to execute the method described in any one of the techniques of the third aspect; The fourth subsystem is at least used to cache the first ID and the second ID provided by the third subsystem.

[0015] The fifth aspect provides a computer storage medium, which stores computer-readable instructions. After the computer-readable instructions are executed, the method described in any technical solution of the first aspect, the second aspect and the third aspect can be executed.

[0016] The sixth aspect provides a computer-readable instruction, characterized in that after the computer-readable instruction is executed, it can execute the method described in any of the technical solutions of the first aspect, the second aspect and the third aspect.

[0017] An embodiment of the present invention provides a cross-subsystem login method, communication equipment and storage medium. When the first ID of the second subsystem requests to log in to the first subsystem, the first subsystem will request the third subsystem to determine whether the first ID has the authority to log in, and obtain the second ID corresponding to the first ID from the 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, thereby reducing the probability of SSO failure and improving the success rate of login. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A schematic diagram of a flow chart of a cross-subsystem login method provided in some embodiments of the present invention; Figure 2 A schematic diagram of a flow chart of a cross-subsystem login method provided in some embodiments of the present invention; Figure 3 A schematic diagram of a flow chart of a cross-subsystem login method provided in some embodiments of the present invention; Figure 4 A schematic diagram of a flow chart of a cross-subsystem login method provided in some embodiments of the present invention; Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention.

[0019] Figure 6 A schematic diagram of the structure of a communication system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] SSO is implemented based on cache files (Cookies), sessions (Sessions), and tokens (Tokens). SSO can simplify the user login experience and centrally manage user identities, but it still has limitations in cross-system authorization. For example, SSO is prone to failure when multiple subsystems need to be authenticated separately. For example, after logging in to subsystem A, it jumps to different subsystems B. When subsystem B authenticates the login account based on its own authentication method, the ID of system A does not originally have the authority of subsystem B, which will cause the login of subsystem B to fail. For example, subsystem B is a multi-page subsystem, and the URL (Uniform Resource Locator) sent by the login request of subsystem A may execute a specific page of a specific subsystem B. However, when jumping across domains, the information pointing to the specific page in the URL is easily lost, which will also cause the SSO login of subsystem B to fail.

[0021] The embodiments of the present invention provide a cross-subsystem login method, a communication device and a storage medium, aiming to solve the above-mentioned SSO login failure.

[0022] like Figure 1 As shown, the embodiment of the present disclosure provides a cross-subsystem login method, which may include: S1101: upon detecting a login request of a first ID that has logged into a second subsystem, sending a first request to a third subsystem, wherein 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 a user ID to log into the second subsystem; S1102: Receive a first response sent by the third subsystem; 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, where the second request is used to request a second ID; the second ID points to a target page of the first subsystem that the first ID requests to log in to; S1104: Receive a second response sent by the third subsystem; S1105: When the second response includes the second ID, allow the first ID to log in to the target page.

[0023] In some embodiments, the first subsystem, the second subsystem, the third subsystem, and the fourth subsystem may belong to different subsystems of the same system, and these subsystems belong to different security domains. Exemplarily, the first subsystem, the second subsystem, the third subsystem, and the fourth subsystem may belong to different subsystems under 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 one or more businesses.

[0024] Taking e-commerce business as an example, the first subsystem can be the store merchant subsystem (also referred to as the store merchant system), the second subsystem can be the store operation background subsystem (store operation background system), the third subsystem can be the single sign-on management subsystem (i.e. single sign-on system), and the fourth subsystem can be the cache system (for example, Redis). Of course, this is an example of e-commerce business, and the specific implementation can also be different subsystems of school management business, company operation business, etc.

[0025] The first ID can be a user ID assigned by the second subsystem. Normally, the first ID can only be used to log in to the first subsystem, but with SSO, the first ID can log in to multiple subsystems managed by SSO. For example, the third subsystem can log in to the first subsystem and the second subsystem at the same time.

[0026] However, in the disclosed embodiment, the second subsystem that the first ID requests to log in 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, so SSO will fail. However, in the disclosed embodiment, when the first subsystem detects that the first ID requests to log in to the first subsystem, it will send a first request to the third subsystem to request authentication. In this way, the third subsystem is used to perform one-time authentication and unified management of logins to the first subsystem and the second subsystem to ensure login security.

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

[0028] In some embodiments, the login request may also include other account information of the first ID. For example, account type information, etc. Exemplarily, the account type information may be a specific string. Different account types may have different strings, but the specific meaning represented by the string here is transparent to the second subsystem, the third subsystem, and the fourth subsystem. That is, the account type information may be referred to by a specific string. In some embodiments, different types of first IDs may be authorized by the third subsystem to log in to different types of pages of the first subsystem. At this time, if the page of the second subsystem requested by the first ID to log in is not the page authorized to log in, the third subsystem may inform the first subsystem through the first response to reject the login of the first ID. In some embodiments, the string may be a designator of the account type. The designator may be spliced ​​at the front end or the back end of the first ID. Exemplarily, the designator may be used as a suffix of a specified length of the first ID. In some embodiments, the first subsystem may perform a form check and / or a type check on the first ID. If the check fails, the login of the first ID may be directly rejected; if the check does not fail, the authentication of the third subsystem is continued.

[0029] In some embodiments, the login request sent by the second subsystem may include the second ID. When the second ID in the login request is not lost, the first subsystem may allow the first ID to log in to the first subsystem directly based on the second ID and display the target page on the user side of the first ID when the first subsystem determines the target page that allows the first ID to log in to the first subsystem based on the first response of the third subsystem. In this way, when the login request does not lose the second ID, unnecessary interactions between the first subsystem and the fourth subsystem that caches the second ID are reduced. In the event that the second ID carried in the login request is lost, the first subsystem may request the second ID from the fourth subsystem based on the first ID.

[0030] 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 failure reason.

[0031] In some embodiments, after receiving the first response indicating the rejection of the first ID to log into the first subsystem, the first subsystem provides a login response to the second subsystem according to the first response. The login response may include the first response, etc., so that the second subsystem can display the login failure or the reason for the failure.

[0032] When the first response indicates that login is allowed, the first subsystem obtains the second ID of the target page for the first ID to request login from the fourth subsystem. For example, the second ID may be a page ID. Taking e-commerce business as an example, the second ID may be a store ID. One of the second IDs may point to one or more related pages in the first subsystem. That is, the target page may be one or more.

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

[0034] In some embodiments, the second request may further include user information related to the account type of the first ID, etc. Exemplarily, the second request may include the aforementioned string.

[0035] In some embodiments, if the first subsystem stores the first ID and the second ID in the fourth subsystem in advance, 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 does not store the first ID and the second ID in the fourth subsystem in advance, the first subsystem cannot successfully obtain the second ID from the fourth subsystem, and the second response may indicate a failure.

[0036] In some embodiments, in this way, 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 requested to log in by the first ID, thereby achieving easy login to the target page of the second subsystem without the user having to enter an ID and / or password from the second subsystem.

[0037] In some embodiments, when the second response includes the second ID, allowing the first ID to log in to the target page includes: Establishing an association relationship between the first ID and the second ID; Performing an authority check for the first ID to log into the first subsystem based on the association relationship; When the authority check passes, the target page is displayed according to the second ID.

[0038] In some embodiments, the first subsystem requires additional authentication to ensure the login security of the second subsystem again. After the first subsystem obtains the second ID from the fourth subsystem, it will establish an association relationship between the first ID and the second ID. This association relationship can be used for the first subsystem to temporarily authenticate the first ID to log into the first subsystem. For example, taking the e-commerce business as an example, the first ID can be the user ID of the operator of the store operation background system. The operator does not belong to any store. In order to ensure the security of the store login, the store login authentication is required, but the authentication information of the store login is missing at this time. In the embodiment of the present disclosure, the establishment of the association relationship between the first ID and the second ID can be considered as the establishment of a temporary authentication information. After the establishment of the association relationship, the first subsystem will perform permission verification based on the association relationship, so that the first ID can quickly log in across subsystems without modifying the original login logic of the first subsystem.

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

[0040] In some embodiments, the establishment of the association relationship between the first ID and the second ID also includes: when the page type of the target page pointed to by the second ID matches the account type of the first ID, the establishment of the association relationship between the first ID, the second ID, and the page type information of the first subsystem authorized to log in by the account type of the first ID. For example, if the account type of the first ID is a financial personnel, only financial related businesses of the first subsystem are allowed to log in. If the account type of the first ID is a sales management page, only the sales management page of the first subsystem is allowed to log in. In this way, when the first ID jumps across pages after logging in to the first subsystem, it can only jump to the page with permission to log in. In some embodiments, the second ID can 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, the association relationship between the first ID, the second ID, and the page type information of the first subsystem authorized to log in by the account type of the first ID can be established to restrict the first ID from logging in to pages of types that it does not have permission to log in. 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 relationship between the first ID and the second ID. Because of the cross-type page jump at this time, the association relationship between the first ID and the second ID cannot satisfy the permission check of the first subsystem.

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

[0042] In the disclosed embodiment, since the first subsystem sets up sessions for different login requests from the second subsystem respectively and stores the above association relationship in the session space corresponding to the session, the information isolation of different second IDs can be achieved, ensuring the security of the second ID information. And by managing the association relationship and / or the login request from the second subsystem through the session, when the session ends, the association relationship between the first ID and the second ID will automatically become invalid and will also be covered by other information of the first subsystem. The management of the life cycle of the association relationship is achieved through the session life cycle, so that the security of the second ID and the page information associated with the second ID can be ensured again.

[0043] In some embodiments, the method further comprises: The first subsystem detects that the session ends, and sends a third request to the fourth subsystem, the third request being used to request the fourth subsystem to delete the second ID corresponding to the first ID, thereby reducing the information security problem caused by the cache of the fourth subsystem.

[0044] In some embodiments, the login request includes logging in to a first URL; the first URL points to the first subsystem; and when the permission check passes, displaying the target page according to the second ID includes: Generate a second URL according to the second ID and the first URL; The target page is displayed according to the second URL.

[0045] In some embodiments, the first URL may at least point to the main page or root page of the first subsystem. Of course, the root page of the second subsystem is not the page where the first ID requests to log in. In the disclosed embodiment, after obtaining the second ID, the first subsystem will generate the first URL and the second ID will generate the second URL, and the second URL will directly point to the target page where the first ID requests to log in.

[0046] In some embodiments, the URL carried in the login request may not discard the second ID or the information corresponding to the target page of the second ID when jumping across subsystems. In this case, after obtaining the second ID, it can be determined by matching whether to use the URL carried in the login request to log in to the target page.

[0047] In some embodiments, after receiving the login request from the second subsystem, the first subsystem automatically checks whether the URL carried in the login request contains information corresponding to the second ID. If so, the corresponding information is discarded, and the second ID obtained from the fourth subsystem is concatenated with the first URL to generate the second URL. By concatenating the URLs to generate the second URL, even if the second ID or the information corresponding to the second ID in the URL is lost during the cross-region or cross-subsystem login process, accurate login to the target page can still be achieved.

[0048] like Figure 2 As shown, the embodiment of the present disclosure provides a cross-subsystem login method, which is executed by the second subsystem and includes: S2101: During the login operation of the target page of the first subsystem, the first ID and the second ID are cached to the fourth subsystem; the first ID is the user ID assigned by the second subsystem and is used to request the user ID to log in to the first subsystem; the second ID points to the target page of the first subsystem requested to be logged in by the first ID; the first ID and the second ID are sent to the fourth subsystem for logging in to the target page of the first subsystem after the third subsystem authorizes the first ID to log in to the first subsystem.

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

[0050] In the disclosed embodiment, when the first subsystem detects a login operation to jump to the second subsystem, it will cache the first ID and the second ID to the fourth subsystem to facilitate the second subsystem to request from the fourth subsystem.

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

[0052] In some embodiments, the method further comprises: Receive a cache response sent by the fourth subsystem. The cache response may indicate whether the first ID and the second ID are cached successfully. The fourth subsystem stores the first ID and the second ID accordingly.

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

[0054] In some embodiments, when caching the first ID and the second ID to 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 to facilitate the subsequent opening of a page matching the account type by the first subsystem to the first ID.

[0055] In some embodiments, the login request also 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.

[0056] In some embodiments, the second subsystem may include one or more lists. The list may store entity IDs of different entities such as different stores in the first subsystem. Different entity IDs correspond to different pages. When a user operation acting on one or more of the entity IDs is detected, it can be considered that a login operation to the first subsystem is detected. For another example, the second subsystem at least caches the URL of a specified page such as the root page for logging into the first subsystem, and the URL can be directly used as the first URL. Of course, the second subsystem can cache URLs corresponding to different entity IDs as the first URL carried by the login request.

[0057] In some embodiments, the method may further include: Before sending a login request and / or caching the first ID and the second ID to the fourth subsystem, the second subsystem determines whether the first ID has the authority to log in to the second subsystem or to the target page of the second subsystem requested by the first ID based on the account type of the first ID. In this way, when the first ID does not have the authority to log in, the login request of the first ID is rejected, and the sending of login requests and / or unnecessary caching of the first ID and the second ID in the fourth subsystem is stopped.

[0058] like Figure 3 As shown, the embodiment of the present disclosure provides a cross-subsystem login method, which is executed by the third subsystem and includes: S3101: receiving a first request sent by a first subsystem; S3102: Determine whether the first ID has the authority to log in to the second subsystem according to the first request, where the first ID is a user ID assigned by the second subsystem and is used to request to log in to the first subsystem; S3103: Send a first response to the first subsystem, where the first response is used to indicate to the first subsystem whether the first ID has the authority to log in to the first subsystem.

[0059] In some embodiments, the third subsystem is the management subsystem of SSO, which can be used for cross-region or cross-subsystem login authentication. After receiving the first request, SSO will determine whether the first ID has the right to log in to the second subsystem. For example, after receiving the first ID, SSO can perform authentication based on the account list of the second subsystem that can log in to the first subsystem stored locally. For example, it is determined whether the first ID has successfully logged in to the second subsystem based on the cookie of the second subsystem. For another example, the third subsystem will record the login status of its management ID. When it is detected that the first ID is an ID that has been authenticated and logged in using a token, password, etc., the cookie generated by the current request login and the previous cookie of the second subsystem are the same source cookies. If it is, it can be considered that the first ID has the right to log in, otherwise it can be considered that the first ID has no right to log in to the first subsystem. Here, the previous cookie of the second subsystem can be a cookie generated when the first account logged in last time. For example, the cookie can be a cookie verified by the SSO subsystem when the first account of the second subsystem logs in.

[0060] In some embodiments, when performing homology verification based on cookies, it can be determined whether to trigger the first account to re-login to the second subsystem based on the cache time of the previous cookie of the second subsystem. For example, the time interval between the cache time of the previous cookie of the second subsystem and the current time is greater than the preset duration, and during the security period, the SSO subsystem sends a re-login reminder to the second subsystem. A prompt for re-login may pop up on the system page of the second subsystem. For example, a pop-up window for re-login to the second subsystem is displayed on the page of the client of the second subsystem, and the pop-up window may include account input and verification information input. The account input has been filled with the first account requesting to log in to the first subsystem. The verification information may be a password, SMS verification code, or a dynamically allocated token, etc. At this time, the user needs to log in again by entering the verification information. Alternatively, a code scanning page is displayed on the client of the second subsystem, and the user can log in to the second subsystem again by scanning the code through a device that supports code scanning, such as a mobile phone.

[0061] In some embodiments, determining whether the first ID has permission to log in to the second subsystem according to the first request includes: When the first ID has successfully logged into the second subsystem, determining whether the first ID specifies a type ID; When the type ID is specified for the first ID, it is determined that the first ID has the authority to log in to the first subsystem.

[0062] For example, the second subsystem has different types of accounts, and only accounts of a specified type may be able to log in to the first subsystem. At this time, authentication can be achieved by identifying whether the first ID is an ID of a specified type.

[0063] In some embodiments, whether the first ID has successfully logged into the second subsystem is determined based on a cookie of the second subsystem.

[0064] The embodiments of this disclosure take e-commerce business as an example, but the specific implementation is not limited to e-commerce business. Figure 4 As shown, the embodiment of the present disclosure provides a cross-subsystem login method which may include:

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

[0066] Step 2: The store operation staff logs in to the store operation backend subsystem and detects the operation of jumping to the store page of the store merchant subsystem based on the store operation backend subsystem.

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

[0068] Step 4: If the store page of the corresponding store of the store merchant subsystem is detected at this time, and it is detected that the user is not logged in to the SSO subsystem, jump to the SSO subsystem.

[0069] Step 5: If the SSO subsystem detects that the user is the operator's ID and detects the same-origin cookie, it allows the operator to log in and informs the store merchant subsystem to release the user.

[0070] Step 6: The store merchant subsystem obtains the store ID that the user requested to log in from Redis. If it cannot be obtained, it means that the user jump is not from the store operation background and the authorization fails. At this time, the jump is not authorized to display an error page and the login process is terminated.

[0071] Step 7: Establish an association between the user ID and the store ID, and splice it into the URL visited by the user based on the store ID.

[0072] Step 8: Perform regular authentication on the user ID based on the association relationship of the store merchant subsystem; Step 9: After authentication is passed, the operator's display page is redirected based on the URL obtained by the above splicing.

[0073] In order to isolate the information of different stores, a session will be established based on the ID request to log in to the store page. Different stores correspond to different sessions, and the aforementioned association relationship is stored in the session space of the corresponding session.

[0074] Taking e-commerce business as an example, the present disclosure provides a cross-subsystem login method that may include: The store operation subsystem and the merchant subsystem use the same single sign-on (SSO) subsystem.

[0075] A user with the store operation role enters the store list and clicks Manage.

[0076] Get the store ID as the value, use the operating user's ID and specific suffix as the key, and store them in Redis as a key-value pair to prevent concurrency problems.

[0077] Jump to the merchant side page of the store merchant subsystem as a store operation role.

[0078] The store merchant subsystem detects the redirection to the SSO subsystem. The SSO subsystem detects the store operation subsystem cookie and concludes that the user has logged in.

[0079] The SSO subsystem jumps to the merchant side of the store merchant subsystem. After obtaining the user information, it is determined that the user is a backend operation role and does not belong to any store.

[0080] At this time, call the interface to query Redis. If there is a store ID, obtain it, concatenate it to the URL and delete it immediately.

[0081] The user's ID and store ID are cached in the session storage, and an ID is assigned to the user. Otherwise, the user will not have permission to jump to the 401 page to prompt an error.

[0082] The store merchant subsystem verifies again. At this time, the user information has passed the verification and is allowed to enter the merchant page.

[0083] The embodiment of the present disclosure provides a first subsystem, including: a sending module, a receiving module and a processing module; The sending module is used to send a first request to the third subsystem when detecting a login request of the first ID that has logged in to the second subsystem, wherein the first request is used by the third subsystem to determine whether to authorize the first ID to log in to the first subsystem; the first ID is a user ID assigned by the second subsystem and is used to request a user ID to log in to the second subsystem; The receiving module is used to receive a first response sent by the third subsystem; 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, wherein the second request is used to request a second ID; the second ID points to a target page of the first subsystem that the first ID requests to log in to; The receiving module is further used to receive a second response sent by the third subsystem; The processing module is used to allow the first ID to log in to the target page when the second response includes the second ID.

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

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

[0086] In some embodiments, the login request includes logging in to a first URL; the first URL points to the first subsystem; the processing module is used to generate a second URL according to the second ID and the first URL; and the target page is displayed according to the second URL.

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

[0088] The present disclosure provides a second subsystem. The second subsystem includes:

[0089] A cache module is used to cache the first ID and the second ID to the fourth subsystem when logging in to the target page of the first subsystem; the first ID is the user ID assigned by the second subsystem and is used to request the user ID to log in to the first subsystem; the second ID points to the target page of the first subsystem requested to log in by the first ID; the first ID and the second ID are sent to the fourth subsystem for logging in to the target page of the first subsystem after the third subsystem authorizes the first ID to log in to the first subsystem.

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

[0091] In some embodiments, the login request also 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.

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

[0093] The disclosed embodiment provides a third subsystem, including: a receiving module, used to receive a first request sent by the first subsystem; a processing module, used to determine whether a first ID has the authority to log in to a second subsystem based on the first request, the first ID is a user ID assigned to the second subsystem and is used to request a user ID to log in to the first subsystem; a sending module, used to send a first response to the first subsystem, the first response is used to indicate to the first subsystem whether the first ID has the authority to log in to the first subsystem.

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

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

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

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

[0098] Optional, such as Figure 5 As shown, an embodiment of the present disclosure provides an electronic device. The 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 Figure 5 One or more electronic devices shown. These electronic devices are connected based on a local area network or the Internet or based on a direct connection interface. Figure 5As shown, the electronic device may include: a processor 501 and a memory 502. The processor 501 may be a general processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. Here, the program executed by the processor 501 may be stored in a memory 502 connected to the processor 501 via a communication bus 503. The memory 502 may be a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a 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), synchronous link dynamic random access memory (SLDRAM), direct RAM bus random access memory (DRRAM). The memory 502 described in the embodiment of the present invention is intended to include but is not limited to these and any other suitable types of memory 502. The memory 502 in the embodiment of the present invention is used to store various types of data to support the operation of the processor 501. Examples of such data include: any computer program operated by the processor 501, such as an operating system and application programs; contact data; phone book data; messages; pictures; videos, etc. Among them, the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks.

[0099] In some embodiments, the memory 502 in the embodiments of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDRSDRAM), enhanced synchronous DRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus DRAM (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.

[0100] The processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 501. The above processor 501 may be a general processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor are combined to be executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 502, and the processor 501 reads the information in the memory 502 and completes the steps of the above method in combination with its hardware. In some embodiments, the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0101] like Figure 6 As shown, the present disclosure also provides a communication system, including: The first subsystem is used to execute any one of the technical solutions of the first aspect mentioned above.

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

[0103] The third subsystem is used to execute any one of the technical solutions of the third aspect mentioned above.

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

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

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

[0107] Another embodiment of the present invention provides a computer storage medium, the computer readable storage medium stores an executable program, and when the executable program is executed by the processor 501, the steps of the cross-subsystem login method applied to the endpoint device can be implemented. Figure 1 , Figure 2 , Figure 3 and / or Figure 4 One or more of the methods shown.

[0108] In some embodiments, the computer storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

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

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

Claims

1. A cross-subsystem login method, characterized in that: Executed by the first subsystem, including: When a login request of a first ID that has logged into the second subsystem is detected, a first request is sent to a third subsystem, where 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 a user ID to log into 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 to the first subsystem, a second request is sent to the fourth subsystem based on the first ID, where the second request is used to request a second ID; the second ID points to a target page of the first subsystem that the first ID requests to log in to; receiving a second response sent by the third subsystem; When the second response includes the second ID, the first ID is allowed to log in to the target page.

2. The method according to claim 1, characterized in that When the second response includes the second ID, allowing the first ID to log in to the target page includes: Establishing an association relationship between the first ID and the second ID; Performing an authority check for the first ID to log into the first subsystem based on the association relationship; When the authority check passes, the target page is displayed according to the second ID.

3. The method according to claim 2, characterized in that The establishing an association relationship between the first ID and the second ID includes: The first ID and the second ID are stored correspondingly in the session space corresponding to the login request; different login requests correspond to different sessions, and different sessions have different session spaces.

4. The method according to claim 2 or 3, characterized in that: The login request includes logging into a first URL; The first URL points to the first subsystem; When the permission check is passed, displaying the target page according to the second ID includes: Generate a second URL according to the second ID and the first URL; The target page is displayed according to the second URL.

5. A cross-subsystem login method, characterized in that: Executed by the second subsystem, including: During the login operation of the target page of the first subsystem, the first ID and the second ID are cached to the fourth subsystem; the first ID is the user ID assigned by the second subsystem and is used to request the user ID to log in to the first subsystem; the second ID points to the target page of the first subsystem requested to be logged in by the first ID; the first ID and the second ID are sent to the fourth subsystem for logging in to the target page of the first subsystem after the third subsystem authorizes the first ID to log in to the first subsystem. A login request is sent to the first subsystem; the login request includes at least the first ID.

6. The method according to claim 5, characterized in that The login request also 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.

7. A cross-subsystem login method, characterized in that: Executed by the third subsystem, including: receiving a first request sent by a first subsystem; Determine whether the first ID has the authority to log in to the second subsystem according to the first request, where the first ID is a user ID assigned by the second subsystem and is used to request to log in to the first subsystem; A first response is sent to the first subsystem, where the first response is used to indicate to the first subsystem whether the first ID has the authority to log in to the first subsystem.

8. The method according to claim 7, characterized in that The determining, according to the first request, whether the first ID has the authority to log in to the second subsystem includes: When the first ID has successfully logged into the second subsystem, determining whether the first ID specifies a type ID; When the type ID is specified for the first ID, it is determined that the first ID has the authority to log in to the first subsystem.

9. The method according to claim 8, characterized in that The method further comprises: Determine whether the first ID has successfully logged into the second subsystem based on the cookie of the second subsystem.

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

11. A computer storage medium, characterized in that: The computer storage medium stores computer-readable instructions, and the computer-readable instructions can execute the method of any one of claims 1 to 4, 5 to 6, and 7 to 9 after being executed.

12. A computer-readable instruction, characterized in that: The computer readable instructions are capable of executing the method of any one of claims 1 to 4, 5 to 6, and 7 to 9 after being executed.

Images