Login control method, device and system and medium
By introducing five preset life cycle functions during the login process, the entire login process is solved, and the problems of complex login process and difficult code management in the existing technology are solved, and a clearer and easier to maintain code structure and higher response speed are achieved.
Patent Information
- Application Number
- CN202411486464.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-23
- Publication Date
- 2025-02-25
AI Technical Summary
In the prior art, the login process is complex and difficult to manage, especially when it involves tripartite capabilities and multi-endpoint interactions, resulting in difficult code management, logical confusion and difficulty in maintaining.
By defining five preset life cycles, each life cycle has a corresponding cycle function to manage the entire login process. Each life cycle function is responsible for a specific task, such as login verification, three-party authorization, data preprocessing, etc., and uses a modular management method to handle exceptions.
It realizes clearer code structure, easy to understand and maintain, improves code management difficulties caused by complex business logic and multi-endpoint interaction, and improves the system's response speed and maintainability.
Smart Images
Figure CN119520031A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a login control method, device, system and medium. Background Art
[0002] Login is a common requirement in every project. When the login process requires the use of third-party capabilities, such as the use of WeChat capabilities by mini-programs, the login requires an additional WeChat authorization step, and the login process becomes more complicated. In this case, the login process involves three main endpoints: the mobile phone, the third-party interface server (such as the WeChat interface server), and the developer server. The business logic in the middle is very complicated. In addition to the verification of the account and password, it may also involve user authorization and cancellation, encryption and decryption of sensitive information, verification and storage of tokens, and automatic retry when network communication is abnormal. In addition, the login itself may be divided into silent login and non-silent login. Complex business logic and multi-endpoint interaction make code management difficult, prone to logical confusion and difficult maintenance. Summary of the invention
[0003] The present application provides a login control method, device, system and medium, which can facilitate the comparison of multiple interfaces.
[0004] In a first aspect, the present application provides a login control method, wherein the login process includes a first life cycle, a second life cycle, a third life cycle, a fourth life cycle, and a fifth life cycle, each life cycle is provided with a corresponding life cycle function, and the method includes:
[0005] Receive the user's login request and call the first life cycle function to determine whether the user's login state is valid;
[0006] If the user's login status is invalid, the second life cycle function is called to trigger the operation of the second life cycle;
[0007] After successfully executing the second life cycle operation, the third life cycle function is called to send a request instruction to the third-party server to obtain a third-party access token;
[0008] Determine whether the third-party access token sent by the third-party server is successfully received;
[0009] If a third-party access token is received from a third-party server, the fourth lifecycle function is called to pre-process the third-party access token and the local data preset by the user to obtain the target data;
[0010] Call the fifth life cycle function to log in the target data on the developer server;
[0011] Determine whether the developer service token sent by the developer server is successfully received;
[0012] If the developer service token sent by the developer server is received, it means that the login is successful.
[0013] Its further technical solution is to call the fourth life cycle function to pre-process the three-party access token and the local data preset by the user to obtain the target data, including:
[0014] The fourth life cycle function is called to encrypt and / or decrypt the three-party access token and the local data preset by the user to obtain the target data.
[0015] Its further technical solution is to determine whether the developer service token sent by the developer server is successfully received, and also includes:
[0016] If the developer service token sent by the developer server is not received, the process returns to the retry operation step of calling the fourth lifecycle function based on the three-party access token to log in to the developer server.
[0017] A further technical solution is that the method returns to the step before the retry operation of calling the fourth life cycle function based on the three-party access token to log in on the developer server, and the method further includes:
[0018] Determine whether the number of retry operations reaches the preset number of retry times;
[0019] If the number of retry operations reaches the preset number of retry operations, the process returns to the restart operation step of calling the first life cycle function to determine whether the user's login state is valid.
[0020] A further technical solution is to determine whether the number of retry operations reaches a preset number of retry operations, and further include:
[0021] If the number of retries reaches the preset number of retries, the retry operation will be automatically stopped, or,
[0022] Call the passed callback method to obtain the user's stop instruction;
[0023] The retry operation ends based on the user's stop instruction.
[0024] Its further technical solution is to determine whether the developer service token sent by the developer server is successfully received, and also includes:
[0025] If the developer service token sent by the developer server is not received, the process returns to the restart operation step of calling the first life cycle function to determine whether the user's login state is valid.
[0026] A further technical solution is to call the second life cycle function to trigger the operation of the second life cycle, including:
[0027] Call the second life cycle function to send a confirmation instruction for the third-party service login to the user;
[0028] Successfully execute the second life cycle operations, including:
[0029] Successfully obtained the user's confirmation instruction.
[0030] In a second aspect, the present application provides a login control device, the login control device comprising a unit for executing any one of the above methods.
[0031] In a third aspect, the present application provides a logged-in control system, which includes a memory and a processor, the memory is used to store program data, and the processor is used to execute the program data to implement the steps of any of the above methods.
[0032] In a fourth aspect, the present application provides a computer-readable storage medium, which is used to store a computer program, and when the computer program is executed by a processor, it is used to implement the steps of any of the above methods.
[0033] The beneficial effects of the present application are as follows: Different from the prior art, the present application defines five preset life cycles, each of which has a corresponding life cycle function, ensuring that each step has clear responsibilities and operations, that is, five preset life cycles are introduced in the login process to manage the entire login process, and each life cycle function is responsible for a specific task, such as login status verification, three-party authorization, data preprocessing, etc. In this way, a modular management method is adopted. When a problem occurs in a certain link, only exception handling needs to be performed in the corresponding life cycle function, making the code structure clearer, easier to understand and maintain. This can improve the existing complex business logic and multi-endpoint interaction that make code management difficult, prone to logical confusion and difficult maintenance. BRIEF DESCRIPTION OF THE DRAWINGS
[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. Among them:
[0035] Figure 1 It is a flowchart of the first embodiment of the login control method provided by the present application;
[0036] Figure 2 A login management timing diagram of the login control method provided in this application;
[0037] Figure 3It is a structural schematic diagram of an embodiment of a computer-readable storage medium provided by the present application. DETAILED DESCRIPTION
[0038] The technical solutions 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 will be understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the present application. It should also be noted that, for ease of description, only some but not all structures related to the present application are shown in the drawings. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.
[0039] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0040] Login is a common requirement in every project. When the login process requires the use of third-party capabilities, such as the use of WeChat capabilities by mini-programs, the login requires an additional WeChat authorization step, and the login process becomes more complicated. In this case, the login process involves three main endpoints: the mobile phone, the third-party interface server (such as the WeChat interface server), and the developer server. The business logic in the middle is very complicated. In addition to the verification of the account and password, it may also involve user authorization and cancellation, encryption and decryption of sensitive information, verification and storage of tokens, and automatic retry when network communication is abnormal. In addition, the login itself may be divided into silent login and non-silent login. Complex business logic and multi-endpoint interaction make code management difficult, prone to logical confusion and difficult maintenance.
[0041] Secondly, if the access is made outdoors, the network communication quality (such as 4G, 5G) may fluctuate greatly, resulting in response delays or even access timeouts, and data may be lost or in abnormal status.
[0042] Therefore, in order to solve the above technical problems, the present application provides a login control method. Please refer to the following embodiments for details.
[0043] Before introducing the embodiments of the present application, the relevant terms involved in the present application are explained first:
[0044] Client: An application that requests access to resources, which can be an app, website, or mini-program.
[0045] Third-party server: A third-party network server that provides various open API capabilities, such as WeChat, Alipay, etc.
[0046] Three-party access token: After successful authorization, the three-party server issues a credential to the client, indicating that the client is allowed to access the resources of the three-party server.
[0047] Developer server: A network service owned by client developers themselves that provides business data support.
[0048] Developer service token: A credential issued by the developer service to the client, which allows the client to access resources on the developer service.
[0049] OAuth2.0: is an industry standard protocol for authorization that allows users to authorize clients to access their resources on third-party servers.
[0050] For example, if the client wants to integrate into the ecosystem of WeChat and Alipay, it must initiate authorized login to WeChat and Alipay. The authorization process follows the OAuth2.0 standard.
[0051] If the client itself is a WeChat or Alipay applet, the authorization process will omit the step of redirecting to the WeChat or Alipay authorization page. Its essence is still OAuth2.0, and the technical solution adopted is the OAuth2.0 authorization code mode.
[0052] See also Figure 1 , Figure 1 This is a flow chart of the first embodiment of the login control method provided by the present application. The login process includes a first life cycle, a second life cycle, a third life cycle, a fourth life cycle and a fifth life cycle, each life cycle is provided with a corresponding life cycle function, and the method includes:
[0053] Step 110: Receive a login request from the user, and call the first life cycle function to determine whether the user's login state is valid.
[0054] Step 120: If the user's login state is invalid, the second life cycle function is called to trigger the operation of the second life cycle.
[0055] Step 130: After successfully executing the operation of the second life cycle, the third life cycle function is called to send a request instruction for obtaining a third-party access token to the third-party server.
[0056] Step 140: Determine whether the third-party access token sent by the third-party server is successfully received.
[0057] Step 150: If a three-party access token sent by a three-party server is received, the fourth lifecycle function is called to pre-process the three-party access token and the local data preset by the user to obtain the target data.
[0058] Step 160: Call the fifth life cycle function to log the target data on the developer server.
[0059] Step 170: Determine whether the developer service token sent by the developer server is successfully received.
[0060] Step 180: If the developer service token sent by the developer server is received, it means that the login is successful.
[0061] This embodiment defines five preset life cycles, each of which has a corresponding cycle function, to ensure that each step has clear responsibilities and operations, that is, five preset life cycles are introduced in the login process to manage the entire login process, and each life cycle function is responsible for a specific task, such as login status verification, three-party authorization, data preprocessing, etc. In this way, a modular management method is adopted. When a problem occurs in a certain link, only exception handling needs to be performed in the corresponding life cycle function, making the code structure clearer, easier to understand and maintain. This can improve the existing complex business logic and multi-endpoint interaction that makes code management difficult, prone to logical confusion and difficult maintenance.
[0062] In addition, by asynchronously calling the third-party service interface and the developer service interface, you can avoid blocking the main thread and improve the system's response speed.
[0063] Refer to the second embodiment of the login control method provided by this application. The method includes the following steps:
[0064] Step 210: Receive a login request from the user, and call the first life cycle function to determine whether the user's login state is valid.
[0065] Step 220: If the user's login state is invalid, the second life cycle function is called to trigger the operation of the second life cycle.
[0066] Step 230: After successfully executing the operation of the second life cycle, the third life cycle function is called to send a request instruction for obtaining a third-party access token to the third-party server.
[0067] Step 240: Determine whether the third-party access token sent by the third-party server is successfully received.
[0068] Step 250: If a third-party access token is received from a third-party server, the fourth lifecycle function is called to encrypt and / or decrypt the third-party access token and the local data preset by the user to obtain the target data.
[0069] In this way, by calling the fourth lifecycle function to encrypt and / or decrypt the third-party access token and the user's preset local data, some time-consuming data conversion operations can be processed before the developer service authorization is executed, which helps to improve the response delay or even access timeout problem that occurs when the developer service authorization is executed.
[0070] Step 260: Call the fifth life cycle function to log the target data on the developer server.
[0071] Step 270: Determine whether the developer service token sent by the developer server is successfully received.
[0072] Step 280: If the developer service token sent by the developer server is received, it means that the login is successful.
[0073] Refer to the third embodiment of the login control method provided by this application. The method includes:
[0074] Step 310: Receive a login request from the user, and call the first life cycle function to determine whether the user's login state is valid.
[0075] Step 320: If the user's login state is invalid, the second life cycle function is called to trigger the operation of the second life cycle.
[0076] Step 330: After successfully executing the operation of the second life cycle, the third life cycle function is called to send a request instruction for obtaining a third-party access token to the third-party server.
[0077] Step 340: Determine whether the third-party access token sent by the third-party server is successfully received.
[0078] Step 350: If a third-party access token sent by a third-party server is received, the fourth lifecycle function is called to pre-process the third-party access token and the local data preset by the user to obtain the target data.
[0079] Step 360: Call the fifth life cycle function to log the target data on the developer server.
[0080] Step 370: Determine whether the developer service token sent by the developer server is successfully received.
[0081] Step 380: If the developer service token sent by the developer server is received, it means that the login is successful.
[0082] Step 390: If the developer service token sent by the developer server is not received, return to the retry operation step of calling the fourth lifecycle function based on the three-party access token to log in to the developer server.
[0083] In this way, when a network request fails, a retry operation can be performed automatically, thereby increasing the success rate of the request.
[0084] Among them, step 310, step 320, step 330, step 340, step 350, step 360, step 370 and step 380 have the same or similar technical solutions as the above embodiments, and are not repeated here.
[0085] In some embodiments, before returning to the retry operation step of calling the fourth lifecycle function based on the three-party access token to log in on the developer server, the method further includes:
[0086] Step 391: Determine whether the number of retry operations reaches the preset number of retry operations.
[0087] Step 392: If the number of retry operations reaches the preset number of retry operations, return to the restart operation step of calling the first life cycle function to determine whether the user's login state is valid.
[0088] In some embodiments, if the number of retry operations reaches a preset number of retry operations, the retry operation is automatically stopped, or the incoming callback method is called to obtain the user's stop instruction; the retry operation is ended based on the user's stop instruction.
[0089] In some embodiments, if the developer service token sent by the developer server is not received, the process returns to the restart operation step of calling the first life cycle function to determine whether the user's login state is valid.
[0090] Refer to the fourth embodiment of the login control method provided by this application. The method includes:
[0091] Step 410: Receive a login request from the user, and call the first life cycle function to determine whether the user's login state is valid.
[0092] Step 420: If the user's login status is invalid, the second life cycle function is called to send a confirmation instruction for the third-party service login to the user.
[0093] Step 430: After successfully obtaining the user's confirmation instruction, the third life cycle function is called to send a request instruction for obtaining a third-party access token to the third-party server.
[0094] Step 440: Determine whether the third-party access token sent by the third-party server is successfully received.
[0095] Step 450: If a third-party access token sent by a third-party server is received, the fourth lifecycle function is called to pre-process the third-party access token and the local data preset by the user to obtain the target data.
[0096] Step 460: Call the fifth life cycle function to log the target data on the developer server.
[0097] Step 470: Determine whether the developer service token sent by the developer server is successfully received.
[0098] Step 480: If the developer service token sent by the developer server is received, it means that the login is successful.
[0099] Based on the above embodiments, combined with Figure 2 , Figure 2 This is a login management sequence diagram of the login control method provided by the present application. The login control method provided by the present application may specifically include the following processes:
[0100] 1. Trigger the login process;
[0101] 2. Call the first life cycle function to determine whether the user's login status is valid;
[0102] 2.1 If the user's login status is valid (i.e. logged in and not expired), the login is terminated;
[0103] 2.2 If the user's login status is invalid (i.e. not logged in or expired), execute 3;
[0104] 3. Call the second life cycle function to send a confirmation instruction for the third-party service login to the user. When the user is authorized, that is, the user's confirmation instruction is successfully obtained, execute 4.1;
[0105] 4.1 Request the third-party service provider (i.e., call the third-party lifecycle function to send a request instruction to the third-party server to obtain a third-party access token);
[0106] 4.2 The third-party service provider, i.e. the third-party server, sends a third-party access token;
[0107] At this point, the client can determine whether it has successfully received the three-party access token sent by the three-party server. If it has, execute 5; if it has not, that is, an exception has occurred, then retry.
[0108] 5. Call the fourth life cycle function to pre-process the three-party access token and the local data preset by the user to obtain the target data, that is, the pre-processed data;
[0109] 6.1 Login data, i.e. call the fifth life cycle function to log in the target data on the developer server;
[0110] 6.2 The developer server sends the developer service token to the client;
[0111] At this point, the client can determine whether it has successfully received the developer service token sent by the developer server; if it has received the developer service token sent by the developer server, it means that the login is successful, that is, 6.3; if it has not received the developer service token sent by the developer server, an exception occurs, and it will retry.
[0112] The first life cycle, the second life cycle, the third life cycle, the fourth life cycle and the fifth life cycle respectively correspond to the following stages in the login process:
[0113] 1. When verifying the login state: onAuthChecking (i.e. the first life cycle). The purpose of this step is to reduce unnecessary logins and improve user experience.
[0114] 2. Before the third-party service authorization is executed: beforeTPAuth (i.e. the second life cycle). The significance of this life cycle is that the third-party service may require the user to actively confirm before logging in. There is a time-consuming waiting for the user's operation. The result here can be provided to the next life cycle.
[0115] 3. When the third-party service authorization is executed: onTPAuth (i.e. the third life cycle), call the third-party service interface for authorization and obtain the third-party access token.
[0116] 4. Before the developer service authorization is executed: beforeSelfAuth (the fourth life cycle), this life cycle is to process some time-consuming data conversion operations. For example, after obtaining the three-party access token, for projects with higher security requirements, it will not only rely on https encryption, but usually there will be a custom encryption and decryption algorithm to encrypt sensitive information before allowing transmission. Encryption and decryption is a computationally intensive operation, which may take 1-2 seconds depending on the performance of the client. The results here will be provided for access in the next life cycle.
[0117] 5. When the developer service authorization is executed: onSelfAuth (the fifth life cycle), the developer service is called to obtain the developer service token. After successful acquisition, it is generally stored locally on the client. Subsequent interface requests can carry the developer service token for identity identification.
[0118] The above five life cycles can be managed through the event bus EventBus in the software design pattern. The event bus can process events in a specific order, and different events support complete modularization and no dependencies on each other. If a life cycle is not published, the system will skip that life cycle and continue to execute the next one in the order. If an exception occurs in the business code contained in a life cycle, developers can easily send a signal to re-execute that life cycle or even restart the entire life cycle. Therefore, this way of organizing code will be more flexible and easy to expand.
[0119] In this way, no matter which link of the login process encounters a problem, developers can easily handle the exception. For example, the common weak network problem will affect onTPAuth and onSelfAuth. Once a request timeout occurs, only these two life cycles can be retried or all life cycles can be re-executed. For some sensitive information, the validity period can be set to only a few seconds.
[0120] In addition, the life cycle is called in sequence. If a problem occurs in a certain link, the subsequent process will be suspended until the problem in the current link is solved (retry, restart or terminate after reaching the maximum number of times), thereby avoiding the impact on the business caused by, including but not limited to, the most likely network stability problems.
[0121] It should be noted that the above five lifecycle functions can choose to retry or restart according to actual business needs, and can stop automatically after the preset upper limit of retries and restarts is reached, or stop after the user confirms through the passed callback method.
[0122] The login control method provided by this application can be adapted to all login services on the market that follow the OAuth2.0 standard. For those that do not follow the OAuth standard, this solution can also support it, for example, developers can omit unnecessary life cycles. Or for unnecessary life cycles, you can also not declare the call, the system will postpone the execution of the next one, reducing unnecessary code. And the code organization method is more flexible, and the order in which the life cycles appear in the code does not affect the order of execution.
[0123] Corresponding to the login control method of the above embodiment, the present application also provides a login control device, which includes a unit for implementing the technical solution of any embodiment in the present application.
[0124] The present application also provides a control system for logging in, which includes a memory and a processor, wherein a computer program is stored in the memory; and the processor is used to execute the program data to implement the steps of the following method:
[0125] Receive the user's login request and call the first life cycle function to determine whether the user's login state is valid;
[0126] If the user's login status is invalid, the second life cycle function is called to trigger the operation of the second life cycle;
[0127] After successfully executing the second life cycle operation, the third life cycle function is called to send a request instruction to the third-party server to obtain a third-party access token;
[0128] Determine whether the third-party access token sent by the third-party server is successfully received;
[0129] If a third-party access token is received from a third-party server, the fourth lifecycle function is called to pre-process the third-party access token and the local data preset by the user to obtain the target data;
[0130] Call the fifth life cycle function to log in the target data on the developer server;
[0131] Determine whether the developer service token sent by the developer server is successfully received;
[0132] If the developer service token sent by the developer server is received, it means that the login is successful.
[0133] It can be understood that the processor is also used to execute program data to implement the technical solution of any embodiment of the present application.
[0134] The computer program implements the login control method provided by any one of the aforementioned method embodiments.
[0135] See also Figure 3 , Figure 3 The structure of an embodiment of a computer-readable storage medium provided by the present application is shown in FIG. 7 . The computer-readable storage medium 70 is used to store a computer program 71. When the computer program 71 is executed by a processor, it is used to implement the following method steps:
[0136] Receive the user's login request and call the first life cycle function to determine whether the user's login state is valid;
[0137] If the user's login status is invalid, the second life cycle function is called to trigger the operation of the second life cycle;
[0138] After successfully executing the second life cycle operation, the third life cycle function is called to send a request instruction to the third-party server to obtain a third-party access token;
[0139] Determine whether the third-party access token sent by the third-party server is successfully received;
[0140] If a third-party access token is received from a third-party server, the fourth lifecycle function is called to pre-process the third-party access token and the local data preset by the user to obtain the target data;
[0141] Call the fifth life cycle function to log in the target data on the developer server;
[0142] Determine whether the developer service token sent by the developer server is successfully received;
[0143] If the developer service token sent by the developer server is received, it means that the login is successful.
[0144] It can be understood that when the computer program 71 is executed by the processor, it is also used to implement the technical solution of any embodiment of the present application.
[0145] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation described above is only illustrative, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as two units or components can be combined or integrated into another system, or some features can be ignored or not executed.
[0146] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on two network units. Some or all of the units may be selected according to actual needs to achieve the purpose of this embodiment.
[0147] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0148] If the integrated units in the above other embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to perform all or part of the steps of each implementation method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.
[0149] The above are only implementation methods of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. A login control method, characterized in that: The login process includes multiple preset life cycles, namely the first life cycle, the second life cycle, the third life cycle, the fourth life cycle and the fifth life cycle. Each life cycle has a corresponding life cycle function. The method includes: Receive the user's login request and call the first life cycle function to determine whether the user's login state is valid; If the user's login status is invalid, the second life cycle function is called to trigger the operation of the second life cycle; After successfully executing the second life cycle operation, the third life cycle function is called to send a request instruction to the third-party server to obtain a third-party access token; Determine whether the third-party access token sent by the third-party server is successfully received; If a third-party access token sent by a third-party server is received, the fourth lifecycle function is called to pre-process the third-party access token and the local data preset by the user to obtain the target data; Calling the fifth life cycle function to log the target data on the developer server; Determine whether the developer service token sent by the developer server is successfully received; If the developer service token sent by the developer server is received, it means that the login is successful.
2. The login control method according to claim 1, characterized in that: The calling of the fourth life cycle function pre-processes the three-party access token and the local data preset by the user to obtain the target data, including: The fourth life cycle function is called to encrypt and / or decrypt the three-party access token and the local data preset by the user to obtain the target data.
3. The login control method according to claim 1, characterized in that: The determining whether the developer service token sent by the developer server is successfully received also includes: If the developer service token sent by the developer server is not received, the process returns to the retry operation step of calling the fourth lifecycle function based on the three-party access token to log in to the developer server.
4. The login control method according to claim 3, characterized in that: Before returning to the retry operation step of calling the fourth lifecycle function based on the three-party access token to log in on the developer server, the method further includes: Determine whether the number of retry operations reaches the preset number of retry times; If the number of retry operations reaches the preset number of retry operations, the process returns to the restart operation step of calling the first life cycle function to determine whether the user's login state is valid.
5. The login control method according to claim 4, characterized in that: The determining whether the number of retry operations reaches a preset number of retry operations also includes: If the number of retry operations reaches the preset number of retry operations, the retry operation is automatically stopped, or, Call the passed callback method to obtain the user's stop instruction; The retry operation is terminated based on the stop instruction of the user.
6. The login control method according to claim 1, characterized in that: The determining whether the developer service token sent by the developer server is successfully received also includes: If the developer service token sent by the developer server is not received, the process returns to the restart operation step of calling the first life cycle function to determine whether the user's login state is valid.
7. The login control method according to claim 1, characterized in that: The calling of the second life cycle function to trigger the operation of the second life cycle includes: Calling the second life cycle function to send a confirmation instruction for the third-party service login to the user; The successful execution of the second life cycle operation includes: Successfully obtained the user's confirmation instruction.
8. A login control device, characterized in that: The registered control device comprises a unit for executing the method according to any one of claims 1-7.
9. A logging control system, characterized in that: The control system of the login includes a memory and a processor, the memory is used to store program data, and the processor is used to execute the program data to implement the login control method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program data, and when the program data is executed by a processor, it is used to implement the login control method as described in any one of claims 1-7.