Method, system and equipment for realizing third-party application authorized login and medium

Abstract

The invention provides a method and system for realizing authorized login of a third-party application, electronic equipment and a storage medium, and aims to solve the problems of poor development efficiency and flexibility of account opening, and the method comprises the following steps: developing a first script authorized and docked by a first application, and storing the first script in a database of a second application; setting a second script, wherein the second script can judge the first script needing to be executed in the next step according to calculation of preset parameters; acquiring an authorization code of the first application; calling an authorized login interface of a second application through a preset parameter carried by the front-end equipment, and loading a second script; preset parameters are introduced to call an interface of the second script, the first script is queried and loaded through calculation of the preset parameters, and the preset parameters comprise an authorization code of the first application and a calling party source; and the authorization code is introduced to call a method specified by the first script to obtain user information of the first application, and account fusion is completed. The development efficiency and the publishing flexibility can be improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of computers and network authorization, and particularly to a method for implementing third-party application authorization login, a system for implementing third-party application authorization login, an electronic device, and a computer-readable storage medium. Background Art

[0002] With the rapid development of the digital age and the wide application of low-code platforms, the threshold for application development has gradually decreased, the development cost has been significantly reduced, and the development efficiency has been greatly improved. However, different applications often have their own independent user systems. To improve the promotion efficiency of applications, it is usually necessary to integrate the user systems of multiple applications.

[0003] Currently, the authorization login process usually adopts a fixed mode for user system integration, mainly including the following two methods: one is to obtain an authorization token through an authorization code, then use the authorization token to obtain user information, and finally integrate the user information with the system account; the other is to directly use the authorization token to obtain user information and issue a system token after integrating the information. Regardless of which method is adopted, each time a new account connection is implemented, code development, testing, and online operations are required, increasing the development cost and maintenance complexity of the system. In the face of diverse user systems, each new docking or system modification requires a complete service release and testing cycle, which undoubtedly increases the system complexity and maintenance cost. Summary of the Invention

[0004] To at least solve the problems in the prior art that code development, testing, and online operations are required for account connection, and the development efficiency and flexibility are poor. The present disclosure provides a method for implementing third-party application authorization login, a system for implementing third-party application authorization login, an electronic device, and a computer-readable storage medium; by configuring corresponding scripts to complete the interface integration and online of account connection, it not only ensures the stability of the system, but also significantly improves the development efficiency and release flexibility.

[0005] In a first aspect, the present disclosure provides a method for implementing third-party application authorization login, the method comprising:

[0006] Develop a first script for the authorization docking of the first application, the internal logic of which includes obtaining the user information of the first application through the authorization code for authorization login of the first application and returning it; after the script development and debugging are completed, save the first script to the database of the second application;

[0007] Set a second script for calculating the authorization type, and the second script determines the first script to be executed next according to the calculation of preset parameters;

[0008] Obtain the authorization code of the first application, which is generated by the first application after the user logs in to the first application to apply for authorized login to the second application;

[0009] Call the authorized login interface of the second application through the front-end device carrying preset parameters, and load the second script;

[0010] Pass in the preset parameters to call the getType interface of the second script, and query and load the first script through the calculation of the preset parameters. The preset parameters include the authorization code of the first application and the caller source;

[0011] Pass in the authorization code to call the method specified by the first script to obtain the user information of the first application, and complete the account integration.

[0012] Further, the saving of the first script to the database of the second application includes:

[0013] Save the content of the script, the business code of the script, and the type code of the script to the database of the second application.

[0014] Further, the method further includes:

[0015] Define the business code of the second script for calculating the authorization type as system, and the type code as oauthType;

[0016] The loading of the second script includes:

[0017] Pass in the business code and type code to query the corresponding script in the database, and obtain the content of the script according to the business code and type code;

[0018] Calculate the MD5 value according to the content of the script;

[0019] Query in the cache whether there is a loaded class according to the MD5 of the script. If not, proceed to the next step;

[0020] If there is no loaded class in the cache, load the corresponding script to call the method in the script through the specified method name, and save the relationship between the class of the corresponding script and the MD5 value.

[0021] Further, the passing in of the preset parameters to call the getType interface of the second script and querying and loading the first script through the calculation of the preset parameters includes:

[0022] Pass in the preset parameters, which also include the device type, device model, and timestamp, and call the getType method of the second script;

[0023] Calculate and return the business code and type code of the subsequent first script through the defined rules for the preset parameters;

[0024] Query the database script according to the service code and type code of the first script obtained, and load the first script.

[0025] Further, calling the method specified by the first script with the authorization code to obtain the user information of the first application and complete the account integration includes:

[0026] Call the getUserInfo method of the first script corresponding to the type code with the authorization code, obtain the user information of the third party, and process the interface response and assemble it into a fixed format for return;

[0027] Complete the account integration according to the returned information.

[0028] Further, the method further includes:

[0029] When querying and loading the first script through the calculation of preset parameters, execute the custom grayscale rule, convert a part of the service code and type code of the subsequent first script returned according to the timestamp and device ID information into a new first script, and the other part into the original first script, so that the subsequent executed first script is loaded according to the corresponding type code;

[0030] After the grayscale online verification is correct, replace the original first script running online with the new first script.

[0031] In a second aspect, the present disclosure provides a system for implementing third-party application authorization login, the system includes:

[0032] A development module, which is set to develop a first script for the authorization docking of the first application, and its internal logic includes obtaining the user information of the first application through the authorization code for authorization login of the first application and returning it; after the script development and debugging are completed, save the first script to the database of the second application;

[0033] A setting module, which is set to set a second script for calculating the authorization type, and the second script determines the first script to be executed next according to the calculation of preset parameters;

[0034] An authorization code acquisition module, which is set to acquire the authorization code of the first application, and the authorization code is generated by the first application after the user logs in to the first application to apply for authorization to log in to the second application;

[0035] A first loading module, which is set to call the authorization login interface of the second application through the front-end device carrying preset parameters and load the second script;

[0036] The second loading module is configured to call the getType interface of the second script by passing in preset parameters, query and load the first script through calculation of the preset parameters, where the preset parameters include the authorization code of the first application and the source of the caller;

[0037] The user information acquisition module is configured to call the method specified by the first script by passing in the authorization code to acquire the user information of the first application and complete account integration.

[0038] Further, the development module is specifically configured to:

[0039] Save the content of the script, the service code of the script, and the type code of the script into the database of the second application.

[0040] In a third aspect, the present disclosure provides an electronic device, including a memory and a processor. A computer program is stored in the memory. When the processor runs the computer program stored in the memory, the processor executes the method for implementing third-party application authorization login as described in any one of the first aspect.

[0041] In a fourth aspect, the present disclosure provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method for implementing third-party application authorization login as described in any one of the first aspect is implemented.

[0042] Advantageous effects:

[0043] The method for implementing third-party application authorization login, the system for implementing third-party application authorization login, the electronic device, and the storage medium provided by the present disclosure can optimize the existing authorization login process. By abstracting the common parts in the process, the docking logic of the third-party interface is implemented through script execution. Each time a new account system is docked, there is no need to modify the existing code or republish the service. Only by configuring the corresponding script can the interface integration and online launch be completed. This method not only ensures the stability of the system but also significantly improves the development efficiency and release flexibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 It is a schematic diagram of a user login process using an authorization code;

[0045] Figure 2 It is a schematic diagram of a user account information integration process;

[0046] Figure 3 It is a schematic diagram of a process of a method for implementing third-party application authorization login provided in Embodiment 1 of the present disclosure;

[0047] Figure 4 It is a schematic diagram of an internal processing flow of a Groovy script provided in an embodiment of the present disclosure;

[0048] Figure 5 A schematic diagram of a script entry process provided by an embodiment of the present disclosure;

[0049] Figure 6 A schematic diagram of a script loading process provided by an embodiment of the present disclosure;

[0050] Figure 7 A schematic diagram of a process for obtaining the loading of a first script provided by an embodiment of the present disclosure;

[0051] Figure 8 A schematic diagram of a complete process for docking a new application provided by Embodiment II of the present disclosure;

[0052] Figure 9 An architecture diagram of a system for implementing third-party application authorization login provided by Embodiment III of the present disclosure;

[0053] Figure 10 An architecture diagram of an electronic device provided by Embodiment IV of the present disclosure. Detailed implementation manners

[0054] To enable those skilled in the art to better understand the technical solutions of the present disclosure, the present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments and drawings described herein are only for explaining the present invention and not for limiting the present invention.

[0055] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to be used to describe a specific order or sequence; and, without conflict, the embodiments and features in the embodiments of the present disclosure can be combined with each other arbitrarily.

[0056] Among them, the terms used in the embodiments of the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure. The singular forms of "a", "the", and "said" used in the embodiments of the present disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0057] In subsequent descriptions, the suffixes such as "module", "component", or "unit" used to represent elements are only for the convenience of description of the present disclosure and have no specific meaning in themselves. Therefore, "module", "component", or "unit" can be used interchangeably.

[0058] The following first briefly introduces the relevant concepts or technologies that may be involved in the embodiments of the present application:

[0059] As a powerful dynamic scripting language, Groovy has the advantage of handling simple processes and is especially suitable for scenarios with rapid iteration. Its hot reloading and just-in-time compilation features enable developers to adjust the system and update functions without redeploying the service. This not only effectively improves development efficiency but also optimizes the release process, facilitating more flexible responses to changes in system requirements in complex scenarios such as multi-user system integration and OAuth2 authorization login.

[0060] The existing authorization login process mainly realizes the authorization login process through authorization codes, such as Figure 1 shown below:

[0061] ① The front end passes in the authorization code and identityType and calls the login interface of Application B. The identityType field identifies which application provides this authorization code, and then the corresponding request interface and address can be found;

[0062] ② Application B identifies the corresponding application party according to identityType, obtains the interface for getting the authorization token from the configuration, and passes in the authorization code in the interface to obtain the authorization token;

[0063] ③ After receiving the request and confirming that the authorization code is correct, Application A returns the authorization token;

[0064] ④ Application B identifies the corresponding application party according to identityType, obtains the interface for getting user information from the configuration, and passes in the authorization token in the interface to obtain user information;

[0065] ⑤ After receiving the request and verifying that the authorization token is correct, Application A returns the user information. The user information generally includes the user's mobile phone number, email, openid, etc.;

[0066] ⑥ After obtaining the user information returned by Application A, Application B will perform account fusion;

[0067] ⑦ After Application B completes the account fusion, it will generate a token for Application B based on this user information;

[0068] ⑧ Return the token, which can be used to access the interfaces of Application B;

[0069] Subsequent user information fusion mainly associates the users of the two systems by identifying the unique information of the users, such as the mobile phone number or email. The process of account fusion is as Figure 2 shown below:

[0070] ① Obtain the basic information of the user, mainly openid (such as the unique ID of the user in Application A), mobile phone number or email for associating the two systems, and personalized data such as the avatar and region;

[0071] ②Query in Application B based on the openid to check if the user ID of associated Application A can be found. If it can be queried, it means the user has already authorized the login. Then, based on the user ID of Application A, the user information of Application A can be queried for the login operation and a token is generated;

[0072] ③If there is no user ID of associated Application A, check if there is a corresponding user in the system based on the mobile phone number / email. If there is, associate the user ID of this user with the openid for convenient future login. At the same time, the login operation can be performed based on the user information and a token is generated;

[0073] ④If there is no corresponding user in the system based on the mobile phone number / email, a user needs to be created first based on the mobile phone number / email, then the user ID is associated with the openid, and then the login operation is performed based on the user information to generate a token.

[0074] Currently, the integration of user systems usually involves cumbersome code development, testing, and online deployment processes. Each new docking or system modification requires a complete service release and testing cycle, increasing the complexity of the system and the maintenance cost.

[0075] The following uses specific embodiments to elaborate in detail on the technical solutions of the present disclosure and how the technical solutions of the present disclosure solve the technical problems existing in the prior art. It can be understood that in the embodiments of the present application, the execution subject can execute some or all of the steps in the embodiments of the present application. These steps or operations are only examples, and the embodiments of the present application can also execute other operations or various deformations of the operations. In addition, each step can be executed in a different order presented in the embodiments of the present application, and it is possible not to execute all the operations in the embodiments of the present application. And, these several specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0076] Figure 1 As shown in the flowchart of a method for implementing third-party application authorization login provided in Embodiment 1 of the present disclosure, Figure 1 the method includes:

[0077] Step S101: Develop a first script for the first application authorization docking, the internal logic of which includes obtaining the user information of the first application through the authorization code for authorization login of the first application and returning it; after the script development and debugging are completed, save the first script to the database of the second application;

[0078] Step S102: Set a second script for calculating the authorization type, and the second script determines the first script to be executed next based on the calculation of preset parameters;

[0079] Step S103: Obtain the authorization code of the first application, which is generated by the first application after the user logs in to the first application to apply for authorized login to the second application;

[0080] Step S104: Call the authorized login interface of the second application through the front-end device carrying preset parameters, and load the second script;

[0081] Step S105: Invoke the getType interface of the second script by passing in the preset parameters, query and load the first script through the calculation of the preset parameters. The preset parameters include the authorization code of the first application and the calling party source;

[0082] Step S106: Invoke the method specified in the first script by passing in the authorization code to obtain the user information of the first application, and complete the account integration.

[0083] Account connection between applications usually uses the OAuth 2.0 protocol to implement authorization and authentication. OAuth 2.0 is an open standard that allows users to authorize third-party applications to access the resources stored on other service providers without sharing usernames and passwords. According to Figure 1 and Figure 2 the processes of authorization code authorization login and authorization token authorization login, it can be seen that the account system connection processes for different third parties are generally the same. The main differences are the signature of the third-party interface, as well as the parameter passing and response structure. Therefore, the embodiments of the present disclosure optimize and transform the commonly used Oauth2 process for account connection between applications, and achieve fast docking and flexible online deployment by combining the Groovy script method. Through the method of combining Groovy scripts for hot loading, each time docking with a third party only requires configuration, which reduces the development and online deployment work. Hot loading means that during the running of the code, new code can be loaded directly without stopping the service. The embodiments of the present disclosure directly load the Groovy script code into the virtual machine environment based on the Java virtual machine, so that the code can take effect directly.

[0084] The first application in the embodiments of the present disclosure is equivalent to Figure 1 and Figure 2 Application A in, and the second application is equivalent to Application B; during the application authorization process, for the second application (such as Weibo), it can be authorized to log in with the first application (i.e., the third-party application, such as Alipay, WeChat, Baidu, etc.). In this scenario, the second application is an application platform that can dock with many third parties and can be logged in through many third parties. For example, to log in to Weibo with Alipay, by opening the login page of Weibo and clicking the Alipay authorized login button, it will automatically jump to Alipay to confirm authorized login, and after successful authorization, you will log in to Weibo. Thus, the authorized login of the third-party application is achieved.

[0085] Both the first script and the second script are Groovy scripts; the development process of Groovy scripts is as Figure 4 shown, including:

[0086] ① When using Groovy scripts in the code, the method name needs to be specified. Therefore, when writing Groovy, the name of the method has been determined, and the Groovy script is developed directly using this name;

[0087] ② When calling the Groovy script, parameters are passed in. For the convenience of extension, the JSON format is directly defined for passing in, and all the parameters that the system can access are put into the JSON parameters for passing in, such as parameters like authorization codes;

[0088] ③ The Groovy script writes the processing logic, including assembling parameters, signature calculation, calling external requests, and other calculation logics;

[0089] ④ Process the interface response result and return the final result of the script through JSON.

[0090] When a new application needs to integrate the account system, it is necessary to develop a script (the first script) for the authorization docking of the first application (third party). Obtain the authorization token through the authorization code of the first application, then use the authorization token to obtain user information, and finally parse and return the parameters. After the script development and debugging are completed, it is saved into the system of the second application. After the script is developed, it can be entered into the system after going online or adjusting after going online, as Figure 5 shown.

[0091] At this time, since the second script has not been set yet, the first script will not be triggered;

[0092] By setting the second script for calculating the authorization type, the second script determines the first script to be executed next based on the calculation of preset parameters, thereby serving to load subsequent scripts. During the application development process, by modifying the second script, subsequent different service scripts can be docked, so that user information can be obtained through the subsequent first script, realizing the authorization login for different third parties; the preset parameters include the authorization code of the first application and the source of the calling party.

[0093] To obtain the authorization code of the first application, the user first logs in to the first application and then applies for authorization to log in to the second application. As a result, the first application generates an authorization code that can be used for authorized login. After obtaining the authorization code, the front-end device passes in the authorization code, the calling party source, the device type (the device type of the front-end device), the device model (of the front-end device), the timestamp, and other information to call the authorization login interface of the second application. The second script has hot loading enabled, and at this time, the second script will be automatically loaded. The second script determines the first script to be called based on the passed-in parameters, that is, it calls the getType interface of the second script by passing in preset parameters, and queries and loads the first script through the calculation of the preset parameters. The first script runs and obtains the user information of the third party based on the authorization code of the third party (by calling the interface of the third party through the authorization code); after obtaining the user information, the account fusion can be performed to generate the token of the second application.

[0094] In the embodiments of the present disclosure, by optimizing the existing authorization login process, the common parts in the process are abstracted, and the docking logic of the third-party interface is implemented through script execution. Each time a new account system is docked, there is no need to modify the existing code or republish the service. Only by configuring the corresponding script can the interface integration and online deployment be completed. This method not only ensures the stability of the system but also significantly improves the development efficiency and release flexibility.

[0095] Further, the saving of the first script to the database of the second application includes:

[0096] Save the content of the script, the service code of the script, and the type code of the script to the database of the second application.

[0097] When saving, it includes other parameters such as the content content of the script, the service_code of the script, and the type of the type code. These parameters of the service code and the type code are required in the subsequent query script and can be freely defined.

[0098] The service code and the type code are two key fields used to uniquely identify a certain script or business logic. Their function is to help the system quickly locate and load the corresponding script content in the database or other storage; Service code: Identifies the business module to which the script belongs (such as system, order, payment). Type code: Identifies the specific type or use of the script (such as oauthType, calculatePrice, refund). Through the combination of the service code and the type code, a script can be uniquely identified to achieve dynamic loading and execution.

[0099] Further, the method further includes:

[0100] Define the second script service code for calculating the authorization type as system, and the type code as oauthType;

[0101] The loading of the second script includes:

[0102] Pass in the service code and type code to query the corresponding script in the database, and obtain the content of the script according to the service code and type code;

[0103] Calculate the MD5 value according to the content of the script;

[0104] Query in the cache whether there is a loaded class according to the MD5 of the script. If not, proceed to the next step;

[0105] If there is no loaded class in the cache, load the corresponding script, call the method in the script through the specified method name, and save the relationship between the class of the corresponding script and the MD5 value.

[0106] The process of the script being loaded and used is as Figure 6 shown, including:

[0107] ① Pass in parameters to query the corresponding script in the database, and obtain the content of the script according to the service code and type code;

[0108] ② Calculate the MD5 value according to the content of the script. Since md5 is basically non-repeating, different scripts can be identified;

[0109] ③ Query in the cache whether there is a loaded class according to the MD5 of the script. If not, proceed to the next step;

[0110] ④ If there is no loaded class in the cache, the corresponding script needs to be loaded, and the relationship between the class and the MD5 value is saved. The use of the cache here is mainly to speed up subsequent processing and prevent memory overflow caused by excessive class loading;

[0111] ⑤ Call the method in the script through the specified method name. For example, call the getType method to obtain the next script to be executed. When calling the method, a JSON-formatted parameter needs to be passed in. The parameter can pass in both the parameters passed in by the caller and the custom request headers, which is convenient for the horizontal expansion of the script;

[0112] ⑥ The script executes the specified method, and after processing, it needs to return data in JSON format according to the defined parameter key.

[0113] The second script service code: system (indicating the system module), type code: oauthType (indicating OAuth2.0 authorization); according to these two parameters, query the script in the database to automatically load the second script.

[0114] Further, the incoming preset parameters call the getType interface of the second script, and query and load the first script through the calculation of the preset parameters, including:

[0115] Input the preset parameters, where the preset parameters further include device type, device model, and timestamp, and call the getType method of the second script;

[0116] Calculate the service code and type code of the subsequent first script by returning according to the defined rules for the preset parameters;

[0117] Query the database script according to the obtained service code and type code of the first script, and load the first script.

[0118] The process of obtaining the loading of the first script is as Figure 7 shown

[0119] Through the second script service code system and type code oauthType for calculating the authorization type defined in advance, the second script can be queried in the database according to these two parameters, and the loaded class can be obtained in the way of Figure 6 ;

[0120] Input parameters to call the getType interface of the script to obtain the first script for exchanging the next authorization code for user information, where the input parameters include authorization code, caller source, device information, etc., and the specific required parameters need to be adjusted according to the rules calculated for the required parameters set in advance; getType interface: Define a fixed method getType in the Groovy script to process the incoming JSON parameters and return type information;

[0121] Calculate the parameters of the script to be executed next, that is, the service code and type code of the subsequent first script, according to the defined rules for the authorization code and the caller source;

[0122] Return the type code type (used to query the script for exchanging the next authorization code for user information), and the type code corresponding to the first script for obtaining user information by the subsequent authorization code is the value returned by the above result; The first script can be loaded in the way of Figure 6 according to the returned service code and type code.

[0123] Further, inputting the authorization code to call the specified method of the first script to obtain the user information of the first application and complete the account integration, including:

[0124] Input the authorization code to call the getUserInfo method of the first script corresponding to the type code to obtain the user information of the third party, and process the interface response and assemble it into a fixed format for return;

[0125] Complete the account integration according to the returned information.

[0126] Query the database script according to the obtained service code and type code, and use Figure 7 the method of loading class U (in programming or software engineering, class U may refer to a specific class. Here, it is the first script determined according to the type code) to load the script into the virtual machine environment;

[0127] Pass in the authorization code to call the getUserInfo method of class U to obtain the user information of the third party (i.e., in the first application system), and process the interface response to assemble it into a fixed format for return {"openid":"xxxx","phone":"xxx","email":"xxx"}. If personal information such as nickname, address, and avatar is also involved in the system, it will be returned together.

[0128] The getUserInfo method is used to obtain user information from a data source (such as a database, API, or mock data) according to the passed-in user ID or other parameters and return it in JSON format.

[0129] According to the existing information, perform account integration according to the Figure 2 process to generate a token for the second application. That is:

[0130] Obtain the basic information of the user, mainly the openid (such as the unique user ID of the first application), mobile phone number or email for associating the two systems, and personalized data such as avatar and region;

[0131] In the second application, determine whether the associated user ID of the first application can be queried. If it can be queried, it means that the user has authorized to log in. Query the user information of the first application according to the user ID of the first application for login operations and generate a token;

[0132] If it cannot be queried, view whether there is a corresponding user in the system according to the user information (mobile phone number / email). If there is, associate the user ID and openid of the user, and perform login operations according to the user information to generate a token;

[0133] If no corresponding user is found in the system according to the user information, first create a user according to the user information (mobile phone number / email), then associate the user ID and openid, and then perform login operations according to the user information to generate a token.

[0134] Furthermore, the method further includes:

[0135] When the first script is queried and loaded through the calculation of preset parameters, a custom grayscale rule is executed. The service code and type code of the subsequent first script returned are converted into a new first script and the original first script respectively according to the timestamp and device ID information, so that the subsequent executed first script is loaded according to the corresponding type code.

[0136] After the grayscale online verification is correct, the new first script replaces the original first script running online.

[0137] Gray Release (or Canary Release) is a strategy for gradually releasing new features or updates to users, aiming to reduce risks through small-scale testing; implementing gray release for authorization login in Groovy scripts can gradually release new features to user groups and combine monitoring and feedback mechanisms to ensure stability.

[0138] The embodiments of the present disclosure also support gray release during the online process; as Figure 7 shown, when calculating the parameters of the script to be executed next for the authorization code and the caller source through defined rules, a custom grayscale rule is executed. For example, the service code of the authorization login script for the first application in the online version is oauth2, and the type code is typeA. The modified version also has a service code of oauth2, and the type code is typeA2. At this time, calculations can be performed based on device information, caller source, and authorization code, and a part of the requests can be modified to the type code of oauth2. An application scenario of this process is as follows: The second application has been docked with the authorization login of the first application, but the first application has been upgraded. Therefore, a new docking script has been written, but it cannot be guaranteed that the new docking script has no problems when going online. Therefore, a part of the requests can be transferred to the new docking script according to information such as the timestamp and device ID, and a part still executes the original script (the request forwarding rule can be customized, for example, requests with a timestamp that is a multiple of 3 are forwarded, or requests with a device ID of xxx are forwarded).

[0139] After the account connection is completed, when the gray release verification is correct, modify the second script to redirect all traffic to the new first script.

[0140] The embodiments of the present disclosure optimize and transform the commonly used Oauth2 process for account connection between applications, and combine Groovy scripts to achieve fast docking and flexible online deployment, while supporting gray release during the online process. Generally speaking, there is no code intrusion into the system. After writing the scripts for third-party applications, multiple third-party account connections and online deployments can be quickly achieved. This method not only ensures the stability of the system but also significantly improves development efficiency and release flexibility.

[0141] Embodiment 2 of the present disclosure also provides a method for implementing third-party application authorization login, as Figure 8 shown Figure 8 is the complete flowchart for a new application to be docked.

[0142] As can be seen from the figure, to connect the accounts of a new system, only a script X for external docking needs to be developed and the existing authorization type calculation script T needs to be modified. During the online process, no operation and maintenance participation in the release is required, and no intrusion into the existing system will be caused. No matter when the release is made, it will not affect the stable operation of the system. Next, each step in the above figure will be explained in detail:

[0143] ① When a new application needs to connect its account system, script X needs to be developed. The script X needs to have a method getUserInfo, and the returned parameter structure is as follows: {"openid":"xxxx","phone":"xxx","email":"xxx"}. Other parameters such as avatar / address and other information can be added according to the system needs. The internal logic includes calculating the signature of the external interface, assembling the request parameters, obtaining the authorization token through the authorization code, then using the authorization token to obtain user information, and finally parsing the returned parameters for return. After the script development and debugging are completed, it is saved in the system of application B. At this time, since script T has not been modified, script X will not be triggered yet;

[0144] ② If the logic of script X is reached, then the script T for calculating the authorization type needs to be modified. Script T will judge according to the calculation of the parameters, and judge the service code and type code of the script that needs to be executed by the next script, so as to load the subsequent scripts. For example, if the incoming caller source is appA, then the returned service code is oauth2 and the type code is appA. These two parameters can find script X. If the caller source is appn, then the returned service code is oauth2 and the type code is appn, and script N can be found. If it is not the online of a new user system, but the gray-scale online of script modification, a part of the traffic can be returned to the new type code appn2 according to parameters such as device type / calling time, and other requests still return the type code appn;

[0145] ③ The user first logs in to application A, and then applies for authorization to log in to application B. As a result, application A will generate an authorization code, and this authorization code can be used for authorization login;

[0146] ④ Pass in information such as the authorization code, caller source, device type, device model, timestamp, etc. and call the authorization login interface;

[0147] ⑤According to service_code = system and type = oauthType, the script T for calculating the authorization type can be retrieved. Class T is loaded through the process of Figure 7 .

[0148] ⑥Pass in information parameters such as the authorization code, the source of the calling party, the device type, the device model, and the timestamp, and call the getType method of class T. This method name is fixed, and the subsequent service_codecode and type are calculated and returned according to the defined rules;

[0149] ⑦Query the database script based on the service_code and type obtained in the previous step, and load class U in the way of Figure 7 .

[0150] ⑧Pass in the authorization code and call the getUserInfo method of class U to obtain the user information of the third party, and process the interface response and assemble it into a fixed format for return {"openid":"xxxx","phone":"xxx","email":"xxx"}. If personal information such as nickname, address, and avatar is also involved in the system, it will also be returned;

[0151] ⑨Generate the token of application B for account integration according to the existing information according to the process of Figure 2 .

[0152] ⑩At this point, the account connection has been completed. After the gray-scale online verification is correct, modify the script to redirect all traffic to the new script.

[0153] This embodiment of the present disclosure combines Groovy scripts to achieve rapid connection of third-party accounts, and can be accessed without modifying the code of the service. It simplifies the release process of the operation and maintenance personnel, and at the same time can improve the stability of the online service by using the gray-scale online method.

[0154] Embodiment 3 of the present disclosure also provides a system for implementing third-party application authorization login. As shown in Figure 9 , the system includes:

[0155] The development module 11 is configured to develop the first script for the first application authorization docking. The internal logic includes obtaining the user information of the first application through the authorization code for authorization login of the first application and returning it; after the script development and debugging are completed, save the first script to the database of the second application;

[0156] The setting module 12 is configured to set the second script for calculating the authorization type. The second script determines the first script to be executed next according to the calculation of the preset parameters;

[0157] The authorization code acquisition module 13 is configured to acquire the authorization code of the first application, which is generated by the first application after the user logs in to the first application to apply for authorized login to the second application;

[0158] The first loading module 14 is configured to call the authorized login interface of the second application by carrying preset parameters through the front-end device and load the second script;

[0159] The second loading module 15 is configured to call the getType interface of the second script by passing in preset parameters, query and load the first script through the calculation of the preset parameters, and the preset parameters include the authorization code of the first application and the caller source;

[0160] The user information acquisition module 16 is configured to call the method specified in the first script by passing in the authorization code to acquire the user information of the first application and complete the account integration.

[0161] Further, the development module is specifically configured as:

[0162] Save the content of the script, the service code of the script, and the type code of the script to the database of the second application.

[0163] Further, the setting module 12 is also configured as:

[0164] Define the service code of the second script for calculating the authorization type as system and the type code as oauthType;

[0165] The first loading module 14 is specifically configured as:

[0166] Pass in the service code and type code to query the corresponding script in the database, and obtain the content of the script according to the service code and type code;

[0167] Calculate the MD5 value according to the content of the script;

[0168] Query in the cache whether there is a loaded class according to the MD5 of the script. If not, proceed to the next step;

[0169] If there is no loaded class in the cache, load the corresponding script, call the method in the script through the specified method name, and save the relationship between the class of the corresponding script and the MD5 value.

[0170] Further, the second loading module 15 is specifically configured as:

[0171] Pass in preset parameters, which also include device type, device model, and timestamp, and call the getType method of the second script;

[0172] Calculate and return the service code and type code of the subsequent first script for the preset parameters according to the defined rules;

[0173] Query the database script according to the service code and type code of the first script obtained, and load the first script.

[0174] Furthermore, the user information acquisition module 16 is specifically set as:

[0175] Invoke the getUserInfo method of the first script corresponding to the type code with the authorization code passed in, obtain the user information of the third party, and process the interface response and assemble it into a fixed format for return;

[0176] Complete the account integration according to the returned information.

[0177] Furthermore, the system further includes a replacement module 17;

[0178] The second loading module 15 is further set to execute a custom grayscale rule when querying and loading the first script by calculating the preset parameters, convert a part of the service code and type code of the subsequent first script into a new first script according to the timestamp and device ID information, and convert the other part into the original first script, so that the subsequent executed first script is loaded according to the corresponding type code;

[0179] The replacement module 17 is set to replace the original first script running online with the new first script when the grayscale online verification is correct.

[0180] The system for implementing third-party application authorization login in this embodiment of the disclosure is used to implement the methods for implementing third-party application authorization login in the first and second method embodiments, so the description is relatively simple. For specific details, please refer to the relevant descriptions in the previous method embodiments and will not be elaborated here.

[0181] In addition, as Figure 10 shown, Embodiment 4 of the present disclosure further provides an electronic device, including a memory 100 and a processor 200. A computer program is stored in the memory 100. When the processor 200 runs the computer program stored in the memory 100, the processor 200 executes the above various possible methods.

[0182] Among them, the memory 100 is connected to the processor 200. The memory 100 can adopt flash memory or read-only memory or other memories, and the processor 200 can adopt a central processing unit or a single-chip microcomputer.

[0183] In addition, the present disclosure embodiment also provides a computer-readable storage medium, on which a computer program is stored, and the computer program is executed by the processor to execute the above various possible methods.

[0184] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, computer program modules, or other data. The computer-readable storage medium includes, but is not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), digital versatile disc (DVD, Digital Video Disc) or other optical disc storage, magnetic cassettes, tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0185] It can be understood that the above embodiments are merely exemplary embodiments adopted to illustrate the principles of the present disclosure. However, the present disclosure is not limited thereto. For those of ordinary skill in the art, various modifications and improvements can be made without departing from the spirit and essence of the present disclosure, and these modifications and improvements are also regarded as the protection scope of the present disclosure.

Claims

1. A method for implementing third-party application authorized login, characterized in that: The method comprises: Develop a first script for authorization docking with the first application, wherein the internal logic includes obtaining user information of the first application through the authorization code of the first application for authorized login, and returning the information; after the script development and debugging is completed, the first script is saved in the database of the second application; Setting a second script for calculating the authorization type, wherein the second script determines the first script to be executed next based on calculation of preset parameters; Obtaining an authorization code for the first application, the authorization code being generated by the first application after the user logs in to the first application to apply for authorization to log in to the second application; Calling the authorization login interface of the second application with preset parameters through the front-end device, and loading the second script; The getType interface of the second script is called by passing in preset parameters, and the first script is queried and loaded by calculating the preset parameters, wherein the preset parameters include the authorization code of the first application and the source of the caller; The authorization code is passed in to call the method specified by the first script to obtain the user information of the first application, thereby completing the account fusion.

2. The method according to claim 1, characterized in that The step of saving the first script to a database of the second application includes: The script content, the script business code, and the script type code are saved in the database of the second application.

3. The method according to claim 2, characterized in that The method further comprises: The second script defines the calculation authorization type. The business code is system and the type code is oauthType. The loading of the second script comprises: Enter the business code and type code to query the script corresponding to the database, and obtain the content of the script based on the business code and type code; Calculate the MD5 value based on the content of the script; Check the cache for any loaded classes based on the script's MD5. If not, proceed to the next step. If there is no loaded class in the cache, the corresponding script is loaded to call the method in the script through the specified method name, and the relationship between the class and the MD5 value of the corresponding script is saved.

4. The method according to claim 2, characterized in that: The inputting of preset parameters calls the getType interface of the second script, and the first script is queried and loaded by calculating the preset parameters, including: Pass in preset parameters, which also include device type, device model and timestamp, and call the getType method of the second script; Calculate the preset parameters according to the defined rules and return the business code and type code of the subsequent first script; The database script is queried according to the acquired business code and type code of the first script, and the first script is loaded.

5. The method according to claim 4, characterized in that The method specified by the first script is called by passing the authorization code to obtain the user information of the first application to complete the account fusion, including: The authorization code is passed in to call the getUserInfo method of the first script corresponding to the type code to obtain the third-party user information, and the interface response is processed and assembled into a fixed format for return; Complete the account integration based on the returned information.

6. The method according to claim 4, characterized in that The method further comprises: When the first script is found and loaded by calculating the preset parameters, the custom grayscale rule is executed, and the business code and type code of the subsequent first script returned are partially converted into a new first script according to the timestamp and device ID information, and the other part is converted into the original first script, so that the first script executed subsequently is loaded according to the corresponding type code; After the grayscale online verification is correct, the new first script will replace the original first script running online.

7. A system for implementing third-party application authorized login, characterized in that: The system comprises: A development module is configured to develop a first script for authorization docking with the first application, wherein the internal logic includes obtaining user information of the first application through the authorization code of the first application for authorization login, and returning the information; and saving the first script to a database of the second application after the script development and debugging is completed; A setting module, which is configured to set a second script for calculating the authorization type, wherein the second script determines the first script to be executed next according to the calculation of preset parameters; An authorization code acquisition module, configured to acquire an authorization code of the first application, wherein the authorization code is generated by the first application after a user logs into the first application to apply for authorization to log into a second application; A first loading module, which is configured to call the authorization login interface of the second application through the front-end device with preset parameters, and load the second script; A second loading module is configured to call the getType interface of the second script by passing in preset parameters, query the first script by calculating the preset parameters, and load the first script, wherein the preset parameters include the authorization code of the first application and the source of the caller; The user information acquisition module is configured to pass in the authorization code and call a method specified by the first script to acquire the user information of the first application, thereby completing the account fusion.

8. The system according to claim 7, characterized in that The development module is specifically configured as follows: The script content, the script business code, and the script type code are saved in the database of the second application.

9. An electronic device, characterized in that: The method comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor runs the computer program stored in the memory, the processor executes the method for realizing authorized login of a third-party application as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for implementing authorized login of a third-party application according to any one of claims 1 to 6 is implemented.

Images