Cross-system mutual trust login-free method and device and storage medium
By receiving the browser's redirect request and verifying the user signature parameters, we ensure that the log-free request across systems can only be completed after the user successfully logs in, solving the problem of low security in the existing technology and achieving a more secure Cross-system mutual trust is free to log in.
Patent Information
- Application Number
- CN202411385914.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-30
- Publication Date
- 2025-01-10
AI Technical Summary
The security of mutual trust between cross-systems in the prior art is low and vulnerable to illegal requests, especially in the fact that it is impossible to effectively verify whether the user initiates a login request under the login state.
By receiving the redirect request sent by the browser, the validity of the user's signature parameters is judged, and the preset request is sent to the first system to verify the login state. According to the verification message, whether the login free request is initiated after successful login is ensured. The user completes the log-free operation when it exists in the second system.
It effectively prevents illegal login-free requests, improves mutual trust and login-free security across systems, and ensures that login-free requests can only be completed after the user successfully logs in.
Smart Images
Figure CN119299149A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of login management technology, and in particular to a cross-system mutual-trust login-free method, device and storage medium. Background Art
[0002] Enterprises often have both self-developed systems and systems purchased from external companies. Each system has different ways and methods of implementing login authentication, and each system has different development languages. In addition, the login states of each system cannot directly trust each other, which means that it is not possible to log in directly across systems.
[0003] At present, the mutual trust and login-free between self-developed systems and external systems is mainly developed by each enterprise based on its own business scenarios. The external system is responsible for accessing according to the standard. As long as the external system and the self-developed system follow the unified standard, mutual trust and login-free can be achieved. There are mainly the following implementation methods: (1) directly put the user encryption in the request parameter, and directly decrypt the user to complete the login. This method is the most direct and simple; (2) the enterprise has developed the oauth2 protocol, and the self-developed system has been connected to oauth2. In this case, it only needs to connect the external system to the enterprise's oauth2 protocol to complete the login-free; (3) provide signature authentication, and each external system completes the login through signature. Compared with method 1, this method has a higher security system, and compared with method 2, non-web systems can also be connected.
[0004] However, if the encrypted user data is intercepted by the first method, it will be easy for others to enter the system by replaying the login-free method, and the security factor is too low. If the second method is used, access to oauth2 requires page interaction, and the external system needs to be customized and developed. For web systems or non-Web systems that have not been connected to oauth2, the access cost is relatively high. The third method can meet the needs of most scenarios, but the third method does not verify whether the user initiates the login-free request in the logged-in state, which means that any user's login-free request can be constructed by the system, and there is a greater security risk of cross-system login-free. Summary of the invention
[0005] The purpose of the embodiments of the present application is to provide a cross-system mutual trust and login-free method, device and storage medium to solve the problem of low security of cross-system mutual trust and login-free in the prior art.
[0006] In order to achieve the above-mentioned purpose, the first aspect of the present application provides a cross-system mutual trust free login method, comprising:
[0007] Receive a redirect request sent by the browser, where the redirect request is generated by the first system based on the free-login request for the second system responded to by the first system and the jump address of the second system and forwarded to the browser, where the free-login request is initiated on the first system after the user successfully logs in to the first system, and carries a user signature parameter and a login status verification address;
[0008] Respond to the redirection request, determine whether the user signature parameters are valid, and send a preset request to the first system, where the preset request carries a login state verification address;
[0009] Receiving a verification message returned by the first system, where the verification message is generated by the first system after verifying whether a cache value in a login state verification address is valid based on a preset request;
[0010] Determine, according to the verification message, whether the free-login request is initiated by the user after successfully logging into the first system;
[0011] If it is determined that the user signature parameter is valid and it is determined that the free log-in request is initiated after successfully logging into the first system, determining whether the user exists in the second system;
[0012] If the user exists, the login session information of the user in the second system is returned to the browser, so that the browser completes the free login operation for the second system.
[0013] In an embodiment of the present application, determining whether the log-free request is initiated after successfully logging into the first system based on the verification message includes: parsing the verification message to extract the verification result parameters in the verification message, the verification result parameters at least including a preset field value; when the preset field value is a preset value, determining that the log-free request is initiated after successfully logging into the first system.
[0014] In an embodiment of the present application, determining whether the user signature parameters are valid includes: extracting the user's user encryption information, signature timestamp, signature random string and signature value from the user signature parameters carried in the redirection request; generating a new signature value for the user according to preset rules and based on the user encryption information, signature timestamp and signature random string; and determining that the user signature parameters are valid when the new signature value is consistent with the signature value.
[0015] In an embodiment of the present application, determining whether the user signature parameters are valid further includes: when the new signature value is inconsistent with the signature value, or a signature value is stored in the second system, determining that the user signature parameters are invalid.
[0016] In an embodiment of the present application, determining whether a user exists in the second system includes: extracting user encryption information of the user from the user signature parameters carried in the redirection request, the user encryption information including at least a user name field; if there is user information matching the user encryption information in the second system, determining that the user exists in the second system.
[0017] In an embodiment of the present application, when at least one of the following conditions is met, a request carrying an error page jump address is sent to the browser to cause the browser to jump to the error page jump address: the user signature parameter is invalid; the log-free request is not initiated after successfully logging into the first system; the user does not exist in the second system.
[0018] In an embodiment of the present application, the verification message is generated after the first system receives a preset request, extracts the cache value in the login state verification address, and detects whether there is a login user corresponding to the cache value in the first system, and is based on the detection result of the login user.
[0019] In an embodiment of the present application, the user's successful login to the first system is determined after the browser responds to the cached value. The cached value is initialized after the first system responds to the login request and is determined based on the user's session information. The login request is sent to the first system after the browser receives the login request sent by the user for the first system.
[0020] A second aspect of the present application provides a cross-system mutual trust login-free device, including:
[0021] a memory configured to store instructions;
[0022] The processor is configured to call instructions from the memory and implement the above-mentioned cross-system mutual trust and login-free method when executing the instructions.
[0023] A third aspect of the present application provides a machine-readable storage medium having instructions stored thereon, which, when executed by a processor, configures the processor to execute the above-mentioned cross-system mutual trust and login-free method.
[0024] Through the above technical solution, the redirection request sent by the browser is received and responded to, it is determined whether the user signature parameters are valid, and a preset request is sent to the first system. The verification message returned by the first system is received, and it is determined according to the verification message whether the free log-in request is initiated by the user after successfully logging into the first system. When it is determined that the user signature parameters are valid, and that the free log-in request is initiated after successfully logging into the first system, and there is a user in the second system, the free log-in operation for the second system is completed, which can effectively prevent the free log-in request actually initiated by non-users, making the mutual trust free log-in across systems safer.
[0025] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] The accompanying drawings are used to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the following specific implementations, they are used to explain the embodiments of the present application, but do not constitute a limitation on the embodiments of the present application. In the accompanying drawings:
[0027] Figure 1 A schematic diagram of the process flow of the cross-system mutual trust and login-free method according to an embodiment of the present application is shown;
[0028] Figure 2 A timing diagram of a cross-system mutual trust and login-free method according to an embodiment of the present application is schematically shown;
[0029] Figure 3 The internal structure diagram of a computer device according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION
[0030] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the specific implementation methods described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.
[0031] It should be noted that if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.
[0032] Figure 1 The flowchart of the cross-system mutual trust and login-free method according to an embodiment of the present application is schematically shown. Figure 1 As shown, in an embodiment of the present application, a cross-system mutual trust free login method is provided. This embodiment mainly uses the method applied to the second system as an example, and includes the following steps:
[0033] Step 101: Receive a redirect request sent by the browser. The redirect request is generated by the first system based on the free log-in request for the second system responded to by the first system and the jump address of the second system, and forwarded to the browser. The free log-in request is initiated on the first system after the user successfully logs in to the first system. The free log-in request carries a user signature parameter and a login status verification address.
[0034] Before logging into the second system, the user needs to successfully log in to the first system. Among them, the first system can be the accessed party, for example, it can be a self-developed system of the enterprise. The first system can also be the party accessing the first system, for example, it can be an externally purchased system. In an embodiment of the present application, the user's successful login to the first system is determined after the browser responds to the cached value. The cached value is determined based on the user's session information after the first system responds to the login request, and the login request is sent to the first system after the browser receives the login request sent by the user for the first system.
[0035] When it is necessary to log in to the first system, the user may send a login request for the first system to the browser. After the browser receives the login request for the first system sent by the user, it may forward the login request to the first system. The first system may initialize the user's session information in response to the login request. The session information may include the user's login information, such as a login ID, etc. The first system may generate a cache value based on the user's session information. The cache value refers to a cookie. The first system may return the generated cache value to the browser, and after the browser responds to the cache value, it may determine that the user has successfully logged in to the first system.
[0036] After the user successfully logs in to the first system, a log-free request for the second system can be initiated on the first system according to demand. The log-free request carries the user signature parameter and the login state verification address. If the first system is the accessed party, for example, it can be the company's self-developed system. At this time, the second system can be the party accessing the first system, for example, it can be an externally purchased system. If the first system is the party accessing the first system, for example, it can be an externally purchased system. At this time, the second system can be the accessed party, for example, it can be the company's self-developed system.
[0037] After responding to the log-free request for the second system, the first system can generate a redirection request based on the user signature parameter and login state verification address carried in the log-free request and the jump address of the second system. The first system can send the redirection request to the browser, and the browser sends the redirection request to the second system.
[0038] Step 102: respond to the redirection request, determine whether the user signature parameters are valid, and send a preset request to the first system, where the preset request carries a login state verification address.
[0039] After receiving the redirection request sent by the browser, the second system responds to the redirection request, determines whether the user signature parameter in the redirection request is valid, and sends a preset request to the first system. The preset request refers to a get request, and the preset request carries a login state verification address. The first system can generate a verification message based on the preset request to verify whether the cache value in the login state verification address is valid.
[0040] In an embodiment of the present application, the verification message is generated after the first system receives a preset request, extracts the cache value in the login state verification address, and detects whether there is a login user corresponding to the cache value in the first system, and is based on the detection result of the login user.
[0041] After the first system receives the preset request, it can extract the cache value in the login state verification address, that is, the cookie. The first system can detect whether there is a login user corresponding to the cache value in the first system to obtain a detection result for the login user. The detection result may include a login user corresponding to the cache value that does not exist in the first system, and a login user corresponding to the cache value that exists in the first system.
[0042] If there is a logged-in user corresponding to the cache value in the first system, the first system determines that the cache value is valid. If there is no logged-in user corresponding to the cache value in the first system, the first system determines that the cache value is invalid. The first system can generate a verification message based on the detection result for the logged-in user and forward the verification message to the second system.
[0043] Step 103: receiving a verification message returned by the first system, where the verification message is generated by the first system after verifying whether a cache value in the login state verification address is valid based on a preset request.
[0044] Step 104: Determine, based on the verification message, whether the free-login request is initiated by the user after successfully logging into the first system.
[0045] The second system may receive the verification message returned by the first system, and may determine, based on the verification message, whether the free log-in request is initiated by the user after successfully logging into the first system.
[0046] In an embodiment of the present application, determining whether the log-free request is initiated after successfully logging into the first system based on the verification message includes: parsing the verification message to extract the verification result parameters in the verification message, the verification result parameters at least including a preset field value; when the preset field value is a preset value, determining that the log-free request is initiated after successfully logging into the first system.
[0047] After receiving the verification message, the second system can parse the verification message to extract the verification result parameters in the verification message. The verification result parameters include at least a preset field value. The preset field value is a Data field value, which can be of boolean type and can be used to describe whether the cookie is valid. When the preset field value is a preset value, the cache value in the login state verification address is valid. At this time, the second system can determine that the free login request was initiated after successfully logging into the first system. The preset value can be true.
[0048] The verification result parameter may also include the code field value and the msg field value. The type of the code field value may be int, which can be used to describe the code returned by the login state verification interface. The code field value may be 0 or non-0. If the code field value is 0, it indicates that the login state verification interface returns the code successfully. If the code field value is non-0, it indicates that the login state verification interface returns the code failed. The type of the msg field value may be String, which can be used to describe the description corresponding to the code field value returned by the login state verification interface.
[0049] In one embodiment, when the preset field value is not the preset value, the cache value in the login state verification address is invalid. At this time, the second system can determine that the free log-in request is not initiated after successfully logging into the first system, and may be a free log-in request not initiated by the user, such as a manually forged or system forged free log-in request.
[0050] In the embodiment of the present application, when it is determined that the free login request is not initiated after successfully logging into the first system, the second system may send a request carrying an error page jump address to the browser, so that the browser jumps to the system error page address. At this time, it can also be determined that the free login for the second system has failed.
[0051] In an embodiment of the present application, determining whether the user signature parameters are valid includes: extracting the user's user encryption information, signature timestamp, signature random string and signature value from the user signature parameters carried in the redirection request; generating a new signature value for the user according to preset rules and based on the user encryption information, signature timestamp and signature random string; and determining that the user signature parameters are valid when the new signature value is consistent with the signature value.
[0052] The second system can extract the user's user encryption information, signature timestamp, signature random string and signature value from the user signature parameter carried in the redirection request. As shown in Table 1 below, the parameters carried by the initiation of the free login request are provided, including the login state verification address and the type and description of the user signature parameter.
[0053] Table 1
[0054]
[0055]
[0056] The second system may generate a new signature value for the user according to preset rules and based on the user encryption information, signature timestamp, and signature random string. The preset rules may be set in advance as required. For example, the new signature value may be generated using the signature calculation method in Table 1 above. The second system may compare the new signature value with the signature value in the user signature parameter carried in the redirection request to verify the validity of the redirection request. If the new signature value is consistent with the signature value carried in the redirection request, the redirection request is valid, and the second system may determine that the user signature parameter is valid.
[0057] In an embodiment of the present application, determining whether the user signature parameters are valid further includes: when the new signature value is inconsistent with the signature value, or a signature value is stored in the second system, determining that the user signature parameters are invalid.
[0058] If the new signature value is inconsistent with the signature value carried in the redirection request, the redirection request is invalid, and the second system can determine that the user signature parameter is invalid. If the signature value is stored in the second system, it means that the signature value in the redirection request is reused, and the second system may be logged in repeatedly. At this time, the redirection request is invalid, and the second system can determine that the user signature parameter is invalid.
[0059] In the embodiment of the present application, when it is determined that the user signature parameter is invalid, the second system may send a request carrying an error page jump address to the browser, so that the browser jumps to the system error page address. At this time, it can also be determined that the free login for the second system has failed.
[0060] Step 105: When it is determined that the user signature parameter is valid and it is determined that the free log-in request is initiated after successfully logging into the first system, it is determined whether the user exists in the second system.
[0061] When it is determined that the user signature parameter is valid and that the free log-in request is initiated after successfully logging into the first system, the second system may determine whether the user exists in the second system.
[0062] In an embodiment of the present application, determining whether a user exists in the second system includes: extracting user encryption information of the user from the user signature parameters carried in the redirection request, the user encryption information including at least a user name field; if there is user information matching the user encryption information in the second system, determining that the user exists in the second system.
[0063] The second system may extract the user's encrypted information from the user's signature parameter carried in the redirect request when the user's signature parameter is valid and the log-free request is initiated after successfully logging into the first system. The encrypted user information includes at least a user name field, namely, a username field. The encrypted user information may also include a mobile field, an email field, and an idNumber field.
[0064] When determining whether there is user information matching the user encrypted information in the second system, the user name field may be used for matching, and one or more of the user encrypted information may be used for matching. If there is user information matching the user encrypted information in the second system, the second system may determine that the user exists in the second system.
[0065] In one embodiment, in the case that there is no user information matching the user encryption information in the second system, the second system may determine that the user does not exist in the second system.
[0066] In the embodiment of the present application, when it is determined that there is no user in the second system, the second system may send a request carrying an error page jump address to the browser, so that the browser jumps to the system error page address. At this time, it can also be determined that the free login for the second system has failed.
[0067] Step 106: if the user exists, the login session information of the user in the second system is returned to the browser, so that the browser completes the free login operation for the second system.
[0068] When it is determined that the user exists in the second system, the second system can complete the user's login-free process according to its own session initialization process. Specifically, the second system can return the user's login session information in the second system to the browser, so that the browser completes the login-free operation for the second system.
[0069] In one embodiment, after completing the free login operation for the second system, jump to the login homepage of the second system.
[0070] like Figure 2 As shown, a timing diagram of a cross-system mutual trust and login-free method is provided.
[0071] Among them, system B supports logging in to the same system without logging in, and supports logging in to the same system without logging in. Users can click system A on the browser to log in to system A. After receiving the user's login request, system A initializes the session and returns a cookie to complete the login of system A.
[0072] After logging into System A, the user can click System B in System A to initiate a log-free request for System B. At this point, System A can generate user parameters, signature parameters, and user verification parameters based on the current logged-in user, attach them to the jump address of System B, and then redirect to the jump address of System B with signature parameters. Among them, the user parameter is the user parameter, which can be a user string encrypted by RSA. The signature parameter may include a signature timestamp, a signature random self-reading, and a signature value. The user verification parameter is the login state verification address, which is used to verify whether the user is a logged-in address and is provided by the user when initiating a log-free request on System A.
[0073] System A returns 302 to the browser to redirect the browser to system B. The browser redirects to the address http: / / b.com / sign / sso / login?user=xxx&sign=xxx×tamp=xxx&checkLogin=http: / / a.com / alreadylogin / confirm?cookie=xxx. The system to be redirected is system B, http: / / b.com / sign / sso / login refers to the authentication address of system B, user refers to the user encryption parameter, sign refers to the signature value, timestamp refers to the timestamp, checkLogin refers to the login status verification address, and http: / / a.com / alreadylogin / confirm?cookie=xxx refers to the verification address for verifying whether the user has logged in on system A before initiating the free login request, which can be used to verify whether the free login request initiated by the user on system A for system B is valid.
[0074] After system B responds to the browser's redirection, it can generate a signature according to the rules. Specifically, system B can extract the user, timestamp, nonce, and sign parameters from the redirected address, perform signature calculation based on user, nonce, and timestamp, and obtain the generated signature. Afterwards, system B compares the generated signature with the signature sign in the redirection. If the generated signature is inconsistent with the signature sign in the redirection, the signature is determined to be invalid. If the signature sign in the redirection has been used and the link is reused, the signature is determined to be invalid. System B can use RSA to decrypt the user parameter. If the decryption fails, the user information is invalid.
[0075] If the signature is determined to be invalid, system B returns 302 to the browser and jumps to the system B error page address, which is http: / / b.com / error_page?err=signature invalid. If the user information is determined to be invalid, system B returns 302 to the browser and jumps to the system B error page address, which is http: / / b.com / error_page?err=user information invalid.
[0076] When system B performs source session verification, it can initiate an http call to obtain the verification result. The verification result is the verification result json message returned by system A. Specifically, system B extracts the checkLogin parameter from the request url, initiates a GET request, and calls the interface address corresponding to checkLogin. When system A receives the GET request, it extracts the cookie value from the interface address carried by the GET request. System A can check whether the corresponding login user can be found in its system based on this cookie value. System A can return the message generated based on its check result to system B. Specifically, if it exists, it means that the cookie value is valid, and the message generated by system A can be: {"code":200,"msg":"success","data":true}. If it does not exist, it means that the cookie value is invalid, and the message generated by system A can be: {"code":200,"msg":"success","data":false}.
[0077] System B can parse the returned message and obtain the data value in the message. If the data value is false, it can be determined that the free login request was not initiated by the user after successfully logging into the first system, and the free login request is invalid. At this time, system B returns 302 to the browser and jumps to the system B error page address, which is http: / / b.com / error_page? err = illegal user request. If the data value is true, it can be determined that the free login request was initiated by the user after successfully logging into the first system, and the free login request is valid.
[0078] When the signature is verified to be valid and the source session verification is passed, system B uses RSA to decrypt the user parameter, extracts the username / mobile / email / idNumber fields from the user, and selects one or more of the fields to match the user in system B. If the match fails, the error page address is jumped to, and the free login fails. If the user is matched, system B completes the user's login process according to its own session initialization process, and the free login is successful, jumps to the login homepage of system B, and completes the free login of system B on system A.
[0079] Through the above technical solution, the redirection request sent by the browser is received and responded to, it is determined whether the user signature parameters are valid, and a preset request is sent to the first system. The verification message returned by the first system is received, and it is determined according to the verification message whether the free log-in request is initiated by the user after successfully logging into the first system. When it is determined that the user signature parameters are valid, and that the free log-in request is initiated after successfully logging into the first system, and there is a user in the second system, the free log-in operation for the second system is completed, which can effectively prevent the free log-in request actually initiated by non-users, making the mutual trust free log-in across systems safer.
[0080] Figure 1 FIG. 1 is a flow chart of a cross-system mutual trust free login method in one embodiment. It should be understood that although Figure 1 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 1 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.
[0081] In one embodiment, a cross-system mutual trust login-free device is provided, including:
[0082] a memory configured to store instructions;
[0083] The processor is configured to call instructions from the memory and implement the above-mentioned cross-system mutual trust and login-free method when executing the instructions.
[0084] In one embodiment, a cross-system mutual trust login-free system is provided, including:
[0085] The first system is used to respond to a login request for the first system, initialize the user's session information, generate a cache value based on the user's session information, return the generated cache value to the browser, so that the browser determines that the user has successfully logged into the first system after responding to the cache value, respond to a free login request for the second system, generate a redirection request based on the user signature parameter and the login state verification address carried in the free login request and the jump address of the second system, send the redirection request to the browser, so that the browser sends the redirection request to the second system, verify whether the cache value in the login state verification address is valid based on a preset request, generate a verification message, and forward the verification message to the second system;
[0086] The second system is used to respond to the redirection request after receiving the redirection request sent by the browser, determine whether the user signature parameter in the redirection request is valid, and send a preset request to the first system, receive the verification message returned by the first system, and determine whether the free log-in request is initiated by the user after successfully logging into the first system according to the verification message. When it is determined that the user signature parameter is valid and that the free log-in request is initiated after successfully logging into the first system, it is determined whether there is a user in the second system. If there is a user, the user's login session information in the second system is returned to the browser, so that the browser completes the free log-in operation for the second system.
[0087] In one embodiment, a storage medium is provided, on which a program is stored, and when the program is executed by a processor, the above-mentioned cross-system mutual trust and login-free method is implemented.
[0088] In one embodiment, a processor is provided, and the processor is used to run a program, wherein the above-mentioned cross-system mutual trust and login-free method is executed when the program is running.
[0089] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 3 As shown. The computer device includes a processor A01, a network interface A02, a memory (not shown in the figure) and a database (not shown in the figure) connected via a system bus. Among them, the processor A01 of the computer device is used to provide computing and control capabilities. The memory of the computer device includes an internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02 and a database (not shown in the figure). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 in the non-volatile storage medium A04. The database of the computer device is used to store data such as verification messages. The network interface A02 of the computer device is used to communicate with an external terminal through a network connection. When the computer program B02 is executed by the processor A01, a cross-system mutual trust and free login method is implemented.
[0090] Those skilled in the art will understand that Figure 3 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.
[0091] An embodiment of the present application provides a device, the device includes a processor, a memory, and a program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the program: receiving a redirection request sent by a browser, the redirection request is generated by a first system based on a free-login request for a second system to which the first system responds and a jump address of the second system and forwarded to the browser, the free-login request is initiated on the first system after a user successfully logs into the first system, and the free-login request carries a user signature parameter and a login state verification address; responding to the redirection request, determining whether the user signature parameter is valid, and sending a preset request to the first system, the preset request carrying the login state verification address; receiving a verification message returned by the first system, the verification message is generated by the first system after verifying whether a cache value in the login state verification address is valid based on the preset request; determining whether the free-login request is initiated by the user after successfully logging into the first system according to the verification message; determining whether the free-login request is initiated by the user after successfully logging into the first system when it is determined that the user signature parameter is valid and the free-login request is initiated after successfully logging into the first system; and when it is determined that the user signature parameter is valid, returning the login session information of the user in the second system to the browser when it is determined that the browser completes the free-login operation for the second system.
[0092] In one embodiment, determining whether the log-free request is initiated after successfully logging into the first system based on the verification message includes: parsing the verification message to extract the verification result parameters in the verification message, the verification result parameters at least including a preset field value; when the preset field value is a preset value, determining that the log-free request is initiated after successfully logging into the first system.
[0093] In one embodiment, determining whether the user signature parameters are valid includes: extracting the user's user encryption information, signature timestamp, signature random string and signature value from the user signature parameters carried in the redirection request; generating a new signature value for the user according to preset rules and based on the user encryption information, signature timestamp and signature random string; and determining that the user signature parameters are valid when the new signature value is consistent with the signature value.
[0094] In one embodiment, determining whether the user signature parameters are valid further includes: determining that the user signature parameters are invalid when the new signature value is inconsistent with the signature value or the signature value is stored in the second system.
[0095] In one embodiment, determining whether a user exists in the second system includes: extracting user encryption information of the user from a user signature parameter carried in a redirection request, the user encryption information including at least a user name field; and determining that the user exists in the second system if user information matching the user encryption information exists in the second system.
[0096] In one embodiment, when at least one of the following conditions is met, a request carrying an error page jump address is sent to the browser to cause the browser to jump to the error page jump address: the user signature parameter is invalid; the log-free request is not initiated after successfully logging into the first system; the user does not exist in the second system.
[0097] In one embodiment, the verification message is generated after the first system receives a preset request, extracts a cache value in the login state verification address, and detects whether there is a login user corresponding to the cache value in the first system, and is based on the detection result of the login user.
[0098] In one embodiment, the user's successful login to the first system is determined by the browser responding to a cached value. The cached value is determined based on the user's session information after the first system responds to the login request and initializes the user's session information. The login request is sent to the first system by the browser after receiving the login request sent by the user for the first system.
[0099] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that initializes the following cross-system mutual trust and login-free method steps.
[0100] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.
[0101] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0102] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0103] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.
[0104] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0105] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.
[0106] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
[0107] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.
[0108] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.
Claims
1. A cross-system mutual trust and no-login method, characterized in that: Applied to the second system, the mutual trust free login method includes: receiving a redirection request sent by a browser, wherein the redirection request is generated by the first system based on a log-free request for the second system to which the first system responds and a jump address of the second system, and forwarded to the browser, wherein the log-free request is initiated on the first system after a user successfully logs in to the first system, and the log-free request carries a user signature parameter and a login state verification address; In response to the redirection request, determining whether the user signature parameter is valid, and sending a preset request to the first system, wherein the preset request carries the login state verification address; receiving a verification message returned by the first system, wherein the verification message is generated by the first system after verifying whether the cache value in the login state verification address is valid based on the preset request; Determining, according to the verification message, whether the free-login request is initiated by the user after successfully logging into the first system; If it is determined that the user signature parameter is valid and that the free log-in request is initiated after successfully logging into the first system, determining whether the user exists in the second system; In the case where the user exists, the login session information of the user in the second system is returned to the browser, so that the browser completes the log-free operation for the second system.
2. The cross-system mutual trust and no-login method according to claim 1, characterized in that: The step of judging whether the free login request is initiated after successfully logging into the first system according to the verification message includes: Parsing the verification message to extract verification result parameters in the verification message, wherein the verification result parameters at least include preset field values; When the preset field value is a preset value, it is determined that the free log-in request is initiated after successfully logging into the first system.
3. The cross-system mutual trust and login-free method according to claim 1, characterized in that: The determining whether the user signature parameter is valid includes: Extract the user encryption information, signature timestamp, signature random string and signature value of the user from the user signature parameters carried in the redirection request; Generate a new signature value for the user according to a preset rule and based on the user encryption information, the signature timestamp and the signature random character string; When the new signature value is consistent with the signature value, it is determined that the user signature parameter is valid.
4. The cross-system mutual trust and no-login method according to claim 3, characterized in that: The determining whether the user signature parameter is valid also includes: In the case where the new signature value is inconsistent with the signature value, or the signature value is stored in the second system, it is determined that the user signature parameter is invalid.
5. The cross-system mutual trust and no-login method according to claim 1, characterized in that: The determining whether the user exists in the second system comprises: Extracting the user encryption information of the user from the user signature parameter carried in the redirection request, where the user encryption information at least includes a user name field; In a case where user information matching the user encryption information exists in the second system, it is determined that the user exists in the second system.
6. The cross-system mutual trust and no-login method according to claim 1, characterized in that: When at least one of the following conditions is met, a request carrying an error page jump address is sent to the browser, so that the browser jumps to the error page jump address: The user signature parameter is invalid; The log-free request is not initiated after successfully logging into the first system; The user does not exist in the second system.
7. The cross-system mutual trust and no-login method according to claim 1, characterized in that: The verification message is generated after the first system receives the preset request, extracts the cache value in the login state verification address, and detects whether there is a login user corresponding to the cache value in the first system, and is based on the detection result of the login user.
8. The cross-system mutual trust and no-login method according to claim 1, characterized in that: The user's successful login to the first system is determined after the browser responds to the cached value. The cached value is initialized after the first system responds to the login request and is determined based on the user's session information. The login request is sent to the first system by the browser after receiving the login request sent by the user for the first system.
9. A cross-system mutual trust login-free device, characterized in that: The mutual trust free login device comprises: a memory configured to store instructions; A processor is configured to call the instructions from the memory and implement the cross-system mutual trust and login-free method according to any one of claims 1 to 8 when executing the instructions.
10. A machine-readable storage medium, characterized in that: The machine-readable storage medium stores instructions for causing a machine to execute the cross-system mutual trust and login-free method according to any one of claims 1 to 8.