An applet authorization processing method, device and equipment

Abstract

The embodiments of the present specification disclose a kind of applet authorization processing method, device and equipment.Scheme includes: entering the centralization scene page of specified application, the centralization scene page has the multiple applets respectively of the multiple applets that the specified application accesses Entrance;In the centralization scene page, the uniform authorization request corresponding to the multiple applets is initiated to the current user;If the current user agrees to carry out pre-authorization in response to the uniform authorization request, then trigger corresponding authorization data generation;After the pre-authorization, if the current user enters the corresponding applet in the multiple applets from the entrance in the centralization scene page, then in the corresponding applet, according to the authorization data, directly obtain the specified information of the current user, for the current user to carry out the business of the corresponding applet, and do not request authorization to the current user in the corresponding applet.

Description

Technical Field

[0001] This specification relates to the field of mini-program technology, and in particular to a method, apparatus and device for mini-program authorization processing. Background Technology

[0002] With the development of internet technology and the widespread use of smartphones, more and more businesses are being conducted through various applications, which has led to the emergence of some large and medium-sized comprehensive platform applications.

[0003] Comprehensive platform applications can embed their own services, such as sub-applications of service providers or applications of other small and medium-sized service providers, into the comprehensive platform application in the form of mini-programs. The comprehensive platform application is regarded as the parent application, and the mini-programs can run on the parent application. This allows for a more lightweight service delivery to users, eliminating the need for users to download and install the corresponding mini-program clients separately. This improves the user experience and helps to obtain more traffic through the parent application.

[0004] In this context, parent applications often integrate with many mini-programs, meaning some users can frequently access different mini-programs within the parent application. Currently, mini-programs typically require users to authorize information such as location, profile picture / nickname, phone number, discounts, and messages. Mini-programs request authorization via pop-ups. In this situation, users accessing different mini-programs within a short period are frequently disturbed by these authorization request pop-ups, impacting user experience and consequently affecting the effectiveness of mini-programs in acquiring and converting traffic. This could even lead to user churn for the parent application itself.

[0005] Therefore, in scenarios where the parent application integrates multiple mini-programs, a mini-program authorization solution with a better user experience is needed. Summary of the Invention

[0006] This specification provides one or more embodiments of a mini-program authorization processing method, apparatus, device, and storage medium to solve the following technical problem: in scenarios where a parent application has access to multiple mini-programs, a mini-program authorization scheme with a better user experience is needed.

[0007] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0008] This specification provides one or more embodiments of a mini-program authorization processing method, including:

[0009] Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application;

[0010] In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user;

[0011] If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated.

[0012] After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0013] This specification provides one or more embodiments of a mini-program authorization processing device, comprising:

[0014] The centralized scene entry module leads to the centralized scene page of the specified application, which has separate entry points for multiple mini-programs accessed by the specified application.

[0015] The unified authorization request module initiates a unified authorization request corresponding to the multiple mini-programs to the current user on the centralized scene page.

[0016] The authorization data triggering module generates corresponding authorization data if the current user agrees to pre-authorization in response to the unified authorization request.

[0017] The mini-program quick processing module, after the prior authorization, if the current user enters the corresponding mini-program from the entry point in the centralized scene page, then in the corresponding mini-program, it directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0018] This specification provides one or more embodiments of a mini-program authorization processing device, comprising:

[0019] At least one processor; and,

[0020] A memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform:

[0022] Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application;

[0023] In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user;

[0024] If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated.

[0025] After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0026] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0027] Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application;

[0028] In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user;

[0029] If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated.

[0030] After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0031] The above-mentioned at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: Considering that when the current user enters the centralized scene page of a specified application (as the parent application), there is a high probability that they will enter the mini-program through different mini-program entry points provided by the page, and may also exit the mini-program and return to the page, and then enter other mini-programs, thus using multiple different mini-programs in a short period of time, therefore, when the user initially arrives at the centralized scene page, it can represent multiple mini-programs and uniformly request the user for pre-authorization, instead of separately requesting authorization from the user in the mini-programs that the user may further enter from here, thereby greatly reducing the disturbance of authorization pop-ups to the user; Moreover, when using With prior authorization from the user, this authorization can be easily controlled by the parent application, preventing abuse by mini-programs. It ensures that a mini-program can only truly use its authorized permissions after the user actually enters it from a centralized scenario page. If the user has not yet entered the mini-program, even if prior authorization has been granted, the mini-program may still be denied access to its authorized permissions. Furthermore, the effectiveness of prior authorization can be consolidated within the jurisdiction of the centralized scenario page, meaning that if the user enters the mini-program from a channel outside the centralized scenario page, the mini-program may still be denied access to its authorized permissions, thus improving security. Therefore, the above solution effectively improves user experience while ensuring security. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 A flowchart illustrating a method for processing WeChat mini-program authorization provided in one or more embodiments of this specification;

[0034] Figure 2 A flowchart illustrating a scheme for obtaining specified user information in a mini-program, provided for one or more embodiments of this specification;

[0035] Figure 3 A flowchart illustrating a quick authorization processing scheme for a mini-program in an application scenario provided by one or more embodiments of this specification;

[0036] Figure 4 Provided for one or more embodiments of this specification Figure 3 Some page effect illustrations of the Chinese solution;

[0037] Figure 5 A flowchart illustrating a risk defense scheme in conjunction with pre-authorization, provided for one or more embodiments of this specification;

[0038] Figure 6 A flowchart illustrating a user protection scheme for a mini-program provided in one or more embodiments of this specification;

[0039] Figure 7 A schematic diagram of the structure of a mini-program authorization processing device provided in one or more embodiments of this specification;

[0040] Figure 8 This is a schematic diagram of the structure of a mini-program authorization processing device provided for one or more embodiments of this specification. Detailed Implementation

[0041] This specification provides an embodiment of a method, apparatus, device, and storage medium for processing WeChat mini-program authorization.

[0042] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0043] As mentioned in the background section, currently, for some large and medium-sized comprehensive platform applications, users entering mini-programs in centralized scenarios may experience issues such as frequent pop-ups and lengthy, confusing processes. This also brings more negative impacts, including: high process overhead for both platforms and merchants, and wasted operational costs. For example, for mini-programs entered in centralized scenarios, when the mini-program is from a lesser-known merchant, the authorization approval rate is low due to users' lack of understanding of the scenario and brand endorsement, resulting in a poor experience; low platform satisfaction affects user return visits and retention. For example, for well-known mini-programs where users have specific needs, although the authorization approval rate may not be affected in the first instance due to targeted consumption and brand endorsement, it may affect users' overall satisfaction with the platform compared to other platforms that may perform better, thereby impacting the platform's competitiveness.

[0044] To address these issues, this application, in scenarios with centralized traffic distribution on a platform, can quickly request prior authorization from users, minimizing the need for separate authorization requests for each mini-program. This reduces the intrusion of multiple pop-up windows and eliminates the need for cumbersome adaptation modifications to mini-programs, thereby improving user experience, platform satisfaction, and traffic conversion rates. Based on this overall approach, the solution outlined in this application will be further explained below.

[0045] Regarding authorization, based on the principles of legality, legitimacy, and minimum necessity in personal information protection, and to safeguard users' right to know and autonomy, when a third party or other non-information holder needs to obtain information stored by a user on the current platform to complete a service, the user's full consent must be obtained. For example, suppose a user wants to use a ride-hailing service provided by another platform on the current platform. Currently, users generally have two options: one is to enter a new mobile phone number to register a new account; the other is to quickly log in using their current platform account. In this case, the user agrees to authorize the other platform to access their account information on the current platform.

[0046] Figure 1 This is a flowchart illustrating a method for authorizing a mini-program, provided in one or more embodiments of this specification. The execution entity of this process may include the client of the specified application (the mini-program accessed by the client can also be considered as part of the client), and may also include the corresponding server. In the case of the client, the hardware execution entity may also include the device on which the client is located, such as the user's smartphone or tablet.

[0047] Figure 1 The process includes the following steps:

[0048] S102: Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs accessed by the specified application.

[0049] In one or more embodiments of this specification, the designated application may be the parent application mentioned in the background art, especially a large or medium-sized platform application with high traffic, which drives traffic to multiple mini-programs that are connected in cooperation through one or more centralized scene pages, so as to increase the number of users accessing these mini-programs.

[0050] The centralized scenarios mentioned here are essentially centralized traffic distribution scenarios, which are centralized traffic entry points provided by the platform to other partners. Centralized scenario pages can especially be the homepage within that scenario. For example, the main pages of business scenarios such as consumer circles, citizen centers, game centers, and medical centers provided by a payment platform are similar to the public areas after entering the main gate of an offline commercial complex, where users can freely choose to go to the shops they are interested in (similar to mini-programs).

[0051] The entry points for each mini-program are typically presented as links with corresponding icons, cards, or text on centralized application pages. Users can click to jump to the corresponding mini-program. It should be noted that after jumping to the mini-program, the user is generally still in the designated application. However, depending on the cooperation method and technical implementation, the user can also leave the designated application. In this case, the solution proposed in this application can continue to be implemented based on cooperation between applications or assistance at the operating system level, and the number of entities implementing the solution can be increased accordingly.

[0052] S104: In the centralized scene page, initiate a unified authorization request to the current user corresponding to the multiple mini-programs.

[0053] In one or more embodiments of this specification, a pop-up window is displayed to the current user on a centralized scene page. This pop-up window initiates a unified authorization request corresponding to multiple mini-programs, allowing the current user to authorize the request by interacting with the pop-up window. Besides pop-ups, other methods can also be used, such as banners, tags, or additional small-screen notifications. While these methods may potentially be somewhat disruptive to the user, this application aims to use this potential disruption to avoid repeatedly disturbing the user in different mini-programs, making it a very worthwhile approach overall.

[0054] In one or more embodiments of this specification, the authorization requested by the unified authorization request is called pre-authorization, which means that authorization is performed in advance before the current user enters each mini-program. However, it should be noted that although the authorization here is uniformly applied to these multiple mini-programs, it is also subject to the control of the designated application. That is, in essence, the user is authorizing the designated application, which can control when the granted permission takes effect and which mini-program it applies to as needed. This avoids authorization generalization and abuse of permissions by multiple mini-programs. In addition, even the designated application itself can restrict the specific conditions under which the designated application can use the permission based on prior negotiation with the user or the platform's own security policy.

[0055] S106: If the current user agrees to pre-authorization in response to the unified authorization request, the corresponding authorization data is generated.

[0056] Taking a unified authorization request via a pop-up window as an example, the current user can click the corresponding button in the pop-up window to indicate whether they agree to or refuse prior authorization. If the user agrees, authorization data will be generated to describe the authorization status or serve as authorization credentials for subsequent permission verification. This authorization data can be generated on the current user's terminal or on the corresponding server, depending on whether local or remote verification is required. The authorization data can indicate the authorized status, the specific centralized scenario or page for which the authorization was granted, and more, such as the effective time range or scope of authorized business.

[0057] S108: After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the specified information of the current user is directly obtained in the corresponding mini-program according to the authorization data, and used to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0058] The specified information requires the current user's authorization to access and typically involves user privacy, such as the user's location, profile picture / nickname, phone number, and discounts. Without prior authorization, if the current user enters one of multiple mini-programs from a centralized page, and that mini-program wants to access the specified information, it needs to initiate an authorization request (usually via a pop-up) within the mini-program itself, as described in the background. Only after the user agrees to the authorization can the specified information be accessed. However, in step S108, "direct access" means that the specified information can be accessed without disturbing the user (e.g., via a pop-up) within the corresponding mini-program to request authorization. Based on the verification of the authorization data, if the verification passes, the information can be accessed.

[0059] Furthermore, the specified information can be timely and dynamically updated information, such as real-time geographical location, real-time order information, and real-time user behavior, so that the mini-program can provide more targeted and timely services to meet the user's needs.

[0060] In one or more embodiments of this specification, as mentioned above, the designated application can control the authorized permissions. Specifically, after prior authorization, the corresponding mini-program may not be allowed to directly obtain the user's specified information before the current user enters the mini-program from the centralized scene page; such information can only be obtained after entry. Furthermore, if the current user enters the corresponding mini-program from a channel other than the centralized scene page, the authorized permissions may also be disallowed. In this case, the prior permissions granted by the user are actually quite strict and targeted at the centralized scene page, thus helping to protect the user's information security.

[0061] pass Figure 1 This method takes into account that if a user enters the centralized scene page of a specified application (as the parent application), there is a high probability that they will enter different mini-programs through different entry points provided on that page, and may also exit the mini-program and return to the same page, only to enter other mini-programs, thus using multiple different mini-programs in a short period of time. Therefore, when the user initially arrives at the centralized scene page, a unified request for prior authorization can be made to the user on behalf of multiple mini-programs, instead of requesting authorization separately for each mini-program the user may subsequently enter from there. This greatly reduces the intrusion of authorization pop-ups on the user. Furthermore, if the user agrees to the prior authorization, this method... The permissions can be easily and centrally controlled by the parent application to prevent abuse of mini-programs. This ensures that a mini-program can only truly use its authorized permissions after a user actually enters it from a centralized scenario page. Even if the user has granted prior authorization, the mini-program may still be denied access to its authorized permissions before entering the mini-program. Furthermore, the validity of prior authorization can be consolidated within the jurisdiction of the centralized scenario page, meaning that if a user enters the mini-program from a channel outside the centralized scenario page, the mini-program may still be denied access to its authorized permissions, thus improving security. Therefore, the above solution effectively improves user experience while ensuring security.

[0062] based on Figure 1 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0063] This specification provides a flowchart illustrating one or more embodiments of a scheme for obtaining specified user information in a mini-program, such as... Figure 2 As shown.

[0064] Figure 2 The process includes the following steps:

[0065] S202: After the prior authorization, determine the corresponding authorization data generated. The corresponding authorization data includes the user identifier of the current user, the centralized scene identifier corresponding to the centralized scene page, and the correspondence between the authorized status information.

[0066] You can also add the corresponding mini-program identifier to the above correspondence so that you can maintain the above correspondence for a specific mini-program.

[0067] Pre-authorization by default applies to all mini-programs within a centralized scenario corresponding to the centralized scenario identifier. However, users may not trust all of these mini-programs, and may even dislike a particular mini-program. Therefore, a separate management method can be provided to users. For example, after pre-authorization, authorization settings options for multiple mini-programs can be displayed to the current user. If the current user cancels authorization for any of the multiple mini-programs by operating the authorization settings options, it is determined that the pre-authorization is invalid for that mini-program (for example, the identifier of that mini-program can be removed from the above correspondence). This prevents any mini-program from directly obtaining the current user's specified information based on the authorization data, while still allowing other mini-programs among the multiple mini-programs that have not had their authorization canceled to directly obtain the current user's specified information based on the authorization data. Similarly, users can also make the above settings in advance.

[0068] S204: When entering the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the centralized scene identifier corresponding to the centralized scene page is sent to the server for verification by the server.

[0069] The server can verify whether the received centralized scenario identifier matches the generated authorization data, and determine whether to allow the corresponding mini-program to directly access user information based on the matching result. For example, if the matching determines that the centralized scenario identifier contained in a generated authorization data is the same as the centralized scenario identifier currently received by the server, and both parties also match in aspects such as user identifier and authorization scope, then the corresponding mini-program can be allowed to directly access user information; otherwise, it can be rejected. This verification can also be performed on the user's terminal. In this case, the authorization data can be pre-stored on the user's terminal for efficient verification.

[0070] The verification process here can be simplified. For example, it can only verify whether the centralized scenario corresponding to the received centralized scenario identifier supports prior authorization. If it does, the verification passes. This allows for a more efficient determination of whether the current mini-program entry channel is the channel targeted by this solution (i.e., entering from a specific centralized scenario).

[0071] S206: When entering a corresponding mini-program from the entry point in the centralized scene page, an authorization request is initiated through the corresponding mini-program without responding to a pop-up window.

[0072] In one or more embodiments of this specification, the authorization request initiated by the corresponding mini-program is targeted at the specified application and is imperceptible to the current user, without disturbing the user. When implementing this solution, the authorization request pop-up of the corresponding mini-program can be intercepted first. Then, depending on whether prior authorization has been performed, it can be decided whether the intercepted pop-up needs to be displayed to the user. In this way, when implementing this solution, it is possible to minimize the need for the corresponding mini-program to also make modifications; only the specified application needs to make modifications. This is more user-friendly for service providers of multiple mini-programs.

[0073] S208: In response to the authorization request, either locally or on the server, the system verifies whether the user corresponding to the authorization request has been authorized and whether the scope of the requested authorization is reasonable, based on the user identifier and authorized status information contained in the generated authorization data.

[0074] The verifications in steps S204 and S208 can be performed together or at different times.

[0075] S210: If so, the user's information is sent to the corresponding mini-program.

[0076] If the verification fails, the corresponding mini-program can be allowed to pop up a request for authorization from the current user.

[0077] pass Figure 2 The solution can precisely and reliably control whether the user's experience may be disturbed by authorization requests in the mini program by maintaining the corresponding relationship that reflects the pre-authorization status and performing corresponding verification when the user actually enters the mini program. At the same time, if necessary, the user can also take the initiative to control it in advance to improve their experience.

[0078] Based on the above description, one or more embodiments of this specification also provide a flowchart of a quick authorization processing scheme for mini-programs in an application scenario, as well as some page effect diagrams of this scheme, which can be found in the following examples. Figure 3 , Figure 4 .

[0079] In this solution, one or more centralized scenarios can be pre-defined within the app (i.e., the designated application mentioned above), such as "xx Store" or "Consumer Circle," each of which integrates multiple merchant mini-programs. A distinct identifier can be set for each centralized scenario, for example, called a centralized scenario channel identifier, with values ​​such as A, B, and C. When a user navigates from the main page of a centralized scenario to a mini-program within it, the current client can carry the corresponding scenario channel identifier to the server.

[0080] Initially, assuming the user has not yet authorized access, when entering a centralized scenario, the app can invoke a quick authorization management pop-up to request the user to grant unified pre-authorization for that scenario. If the user agrees to authorize, a quick authorization relationship can be created for that user as the aforementioned authorization data, stored locally or on the server. An example quick authorization relationship might include: scenario channel identifier (A / B / C) + user identifier + activation status + pop-up-free authorization scope. If the user refuses authorization, the pop-up will close.

[0081] Even after a user grants authorization, if the user has not yet been redirected from the centralized scenario to a specific merchant mini-program, that merchant mini-program will still be unable to obtain the user data corresponding to the relevant permissions (i.e., the specified information mentioned above). In other words, for that merchant mini-program, the permission is not actually effective, thus helping to reduce the risk of merchants abusing user data.

[0082] When a user jumps from a centralized scenario to a merchant's mini-program, the merchant's mini-program initiates an authorization request. The system verifies whether the user has enabled quick authorization and whether the authorization scope includes the merchant's request scope. If the verification is successful, the system directly returns the user data corresponding to the permission. Otherwise, an authorization request pop-up window can be invoked so that the user can confirm the authorization.

[0083] exist Figure 4The illustrations show some information obscured, but this doesn't affect understanding. From left to right, four sub-images are visible. In the first image, the user is on the main page of a centralized scenario called "xx Store." This page has a pop-up for quick authorization management, requesting permissions including the user's location and in-app promotional information (with an indication of the intended use of this information). The user can click the "Allow" button to grant permission. If the user agrees, the page shown in the second image will appear, prompting the user to manage quick authorization as needed, such as canceling it at any time via a quick authorization switch. The third image exemplifies the access path to the quick authorization management page, and the fourth image shows the quick authorization switches within that page. Of course, as explained above, more granular quick authorization switches for each mini-program can be added to the quick authorization management page if needed.

[0084] pass Figure 3 The proposed solution, due to the limited and controllable number of centralized scenarios, can avoid the problem of excessive data expansion and high technical costs, making it highly practical.

[0085] In one or more embodiments of this specification, under the pre-authorization scenario, the user essentially delegates more security responsibility to the designated application. To enable users to more clearly perceive and respond to risks, one or more embodiments of this specification also provide a flowchart illustrating a risk defense scheme in conjunction with pre-authorization. See [link to flowchart]. Figure 5 .

[0086] Figure 5 The process includes the following steps:

[0087] S502: After directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data, detect the business timing node involving the specified information of the current user in the corresponding mini-program.

[0088] After obtaining the specified information of the current user, the corresponding mini-program will execute one or more time-sequential business processes based on the user's real-time operations and the mini-program's own business logic. The currently executed business process can be divided into multiple business timing nodes according to a set method (such as dividing according to different business data used, different functions called, different business types of returned data, or interactive user interface elements, etc.).

[0089] This solution mainly focuses on business timing nodes related to specified information. For example, it can detect and filter business timing nodes that directly or indirectly use specified information as relevant business timing nodes.

[0090] S504: Generate a user information risk link based on the temporal relationship of each of the aforementioned business timing nodes.

[0091] In one or more embodiments of this specification, by arranging and linking the various business timing nodes according to their temporal relationships (where branching may occur to cover business behaviors over a longer period within the corresponding mini-program), a visually concise user information risk chain is generated. The business behaviors related to the specified information reflected on the user information risk chain may contain potential risks. Therefore, this can serve as a reference for users, enabling them to more clearly understand where the specified information is used.

[0092] Considering that the level of sophistication in how user information risk chains manifest may vary in practical applications, and therefore may not be fully understood by all users, intelligent analysis techniques can be used to help generate more user-friendly user information risk chains. For example, suppose the aforementioned unified authorization request carries the intended use of specified information about the current user (e.g., ...). Figure 4 If the first subgraph in the image falls into this category, then the detected business timing nodes can be matched and analyzed with the intended use to obtain the use deviation results. Based on the use deviation results and the temporal relationship of each business timing node, a user information risk link can be generated.

[0093] S506: In response to the current user's request, the information risk link is displayed to the current user.

[0094] The information risk path doesn't have to be displayed by default; users can actively request and access it if they wish. Alternatively, the information risk path can be proactively displayed to users only when a risk is automatically detected.

[0095] S508: Receive the risk blocking point indicated by the current user in the information risk link.

[0096] It not only provides users with means to discover risks, but also offers flexible and timely solutions for responding to risks. Users can select business nodes in the information risk chain that they believe are at risk, or that the system alerts them to, and thus use these nodes as risk prevention points.

[0097] S510: Block the path in the information risk link that is after the risk blocking point, and roll back the business involved in the information risk link to the risk blocking point or before it in the corresponding mini-program.

[0098] To more reliably protect user privacy and achieve business rollback with less impact, one or more embodiments of this specification also provide a flowchart illustrating a user protection scheme for the mini-program within the parent application. (See attached diagram.) Figure 6 .

[0099] Figure 6 The process includes the following steps:

[0100] S602: Before directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data, the specified application generates a corresponding fake user for the current user and generates the fake user's fake feature information based on the business characteristics of the corresponding mini-program and the specified original information of the current user.

[0101] In one or more embodiments of this specification, the designated application will remap the current user's real account to generate a new account to represent the current user, i.e., a fake user. Furthermore, based on the business characteristics of the corresponding mini-program, and under the condition that the mini-program can basically function normally, the designated original information of the current user is also disguised as much as possible to obtain the disguised user's disguised characteristic information. For example, for a food delivery mini-program, which at a minimum requires the user's delivery address, other information can be obscured or confused with other users' information as much as possible. The delivery address can also be slightly obscured (e.g., obscured to the floor instead of the specific house number; or obscured to a pre-accepted dynamic address tens or even hundreds of meters away from the actual delivery address; etc.), thereby achieving disguise.

[0102] S604: When the specified information of the current user is directly obtained in the corresponding mini-program based on the authorization data, specifically, the disguised user's disguised feature information is directly obtained in the corresponding mini-program based on the authorization data, and used to perform the business of the corresponding mini-program for the current user.

[0103] In this way, for the designated application, the corresponding mini-program can complete its business normally while avoiding the mini-program's precise acquisition of user information. Furthermore, assuming the aforementioned risk-blocking rollback operation is supported, the same mini-program for the same user can generate two or more fake users, and generate distinctive fake user characteristics for each. Initially, only one fake user is provided to the mini-program. If a risk-blocking rollback occurs for that fake user, the remaining business logic after the rollback is copied or replaced to one of the remaining fake users, allowing the mini-program to continue its business with that remaining fake user. Of course, in this solution, the remaining fake user can also be replaced with a real user. For example, after determining that there is a high probability of no risk, a real user can be enabled for the mini-program. In this way, fake users can help real users test risks and more reliably establish business paths with a high probability of no risk, enabling the mini-program to conduct its business and thus providing stronger protection for user privacy and security.

[0104] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 7 , Figure 8 As shown. The apparatus and equipment are capable of performing the above methods and related alternatives accordingly.

[0105] Figure 7 This specification provides a schematic diagram of the structure of a mini-program authorization processing device according to one or more embodiments. The device includes:

[0106] The centralized scene entry module 702 enters the centralized scene page of the specified application, which has separate entry points for multiple mini-programs accessed by the specified application.

[0107] The unified authorization request module 704 initiates a unified authorization request corresponding to the multiple mini-programs to the current user in the centralized scene page;

[0108] The authorization data triggering module 706, if the current user responds to the unified authorization request and agrees to perform prior authorization, triggers the generation of corresponding authorization data;

[0109] The mini-program quick processing module 708, after the prior authorization, if the current user enters the corresponding mini-program from the entry point in the centralized scene page, then in the corresponding mini-program, it directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0110] Optionally, the authorization data triggering module 706, after the pre-authorization, does not allow the corresponding mini-program to directly obtain the specified information of the current user before the current user enters the corresponding mini-program from the entry point in the centralized scene page.

[0111] Optionally, the unified authorization request module 704 pops up a window for the current user in the centralized scene page and initiates a unified authorization request corresponding to the multiple mini-programs through the pop-up window, so that the current user can authorize by interacting with the pop-up window;

[0112] The mini-program quick processing module 708 directly obtains the user's information in the corresponding mini-program based on the authorization data, without requesting authorization from the current user through a pop-up window in the corresponding mini-program to obtain the specified information of the current user.

[0113] Optionally, when the mini-program quick processing module 708 enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, it sends the centralized scene identifier corresponding to the centralized scene page to the server so that the server can verify whether the received corresponding centralized scene identifier matches the generated authorization data, and determine whether to allow the corresponding mini-program to directly obtain the user's information based on the matching result.

[0114] Optionally, the corresponding authorization data includes the user identifier of the current user, the centralized scene identifier corresponding to the centralized scene page, and the correspondence between the authorized status information;

[0115] When the mini-program quick processing module 708 enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, it initiates an authorization request through the corresponding mini-program without responding to the pop-up window.

[0116] In response to the authorization request, either locally or on the server, the system verifies whether the user corresponding to the authorization request has been authorized and whether the scope of the requested authorization is reasonable, based on the user identifier and authorized status information contained in the generated authorization data.

[0117] If so, the user's information will be sent to the corresponding mini-program.

[0118] Optionally, the authorization data triggering module 706 displays the authorization settings options corresponding to the multiple mini-programs to the current user after the prior authorization;

[0119] If the current user cancels authorization for any of the multiple mini-programs by using the authorization settings, it is determined that the prior authorization is invalid for that mini-program. This prevents any mini-program from directly obtaining the current user's specified information based on the authorization data, while still allowing other mini-programs among the multiple mini-programs that have not been canceled to directly obtain the current user's specified information based on the authorization data.

[0120] Optionally, the mini-program quick processing module 708, after directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data, detects the business timing node in the corresponding mini-program that involves the specified information of the current user;

[0121] Based on the temporal relationship of each of the aforementioned business opportunity nodes, a user information risk chain is generated;

[0122] In response to the current user's request, the information risk link is displayed to the current user.

[0123] Optionally, the unified authorization request carries the intended use of the specified information of the current user;

[0124] The mini-program quick processing module 708 matches and analyzes each of the business timing nodes with the expected purpose to obtain the purpose deviation result;

[0125] Based on the usage deviation results and the temporal relationship of each of the aforementioned business timing nodes, a user information risk link is generated.

[0126] Optionally, the mini-program quick processing module 708, after displaying the information risk link to the current user, receives the risk blocking point indicated by the current user in the information risk link;

[0127] The path in the information risk link that is after the risk blocking point is blocked, and the business involved in the information risk link is rolled back to the risk blocking point or before it in the corresponding mini-program.

[0128] Optionally, before directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data, the mini-program quick processing module 708 generates a corresponding fake user for the current user and generates the fake user's fake feature information through the specified application based on the business characteristics of the corresponding mini-program and the specified original information of the current user;

[0129] The step of directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data specifically includes:

[0130] Based on the authorization data, the disguised user's disguised feature information is directly obtained in the corresponding mini-program and used to perform the business of the corresponding mini-program for the current user.

[0131] Figure 8 This specification provides a schematic diagram of the structure of a mini-program authorization processing device according to one or more embodiments. The device includes:

[0132] At least one processor; and,

[0133] A memory communicatively connected to the at least one processor; wherein,

[0134] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform:

[0135] Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application;

[0136] In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user;

[0137] If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated.

[0138] After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0139] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0140] Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application;

[0141] In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user;

[0142] If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated.

[0143] After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

[0144] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0145] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0146] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0147] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0148] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0149] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0150] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0151] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0152] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0153] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0154] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0155] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0156] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0157] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0158] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0159] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for handling WeChat Mini Program authorization, comprising: Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application; In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user; If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated. After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

2. The method of claim 1, wherein after the prior authorization, the method further comprises: Before the current user enters the corresponding mini-program from the entry point in the centralized scene page, the corresponding mini-program is not allowed to directly obtain the current user's specified information.

3. The method as described in claim 1, wherein in the centralized scene page, initiating a unified authorization request corresponding to the multiple mini-programs to the current user specifically includes: In the centralized scene page, a pop-up window is displayed to the current user, and a unified authorization request corresponding to the multiple mini-programs is initiated through the pop-up window so that the current user can authorize the request by interacting with the pop-up window. The step of directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data specifically includes: The user's information is obtained directly in the corresponding mini-program based on the authorization data, without requesting authorization from the current user to obtain the specified information of the current user through a pop-up window in the corresponding mini-program.

4. The method as described in claim 1, wherein entering the corresponding mini-program among the plurality of mini-programs from the entry point in the centralized scene page specifically includes: When entering the corresponding mini-program from the entry point in the centralized scene page, the centralized scene identifier corresponding to the centralized scene page is sent to the server so that the server can verify whether the received corresponding centralized scene identifier matches the generated authorization data, and determine whether to allow the corresponding mini-program to directly obtain the user's information based on the matching result.

5. The method as described in claim 4, wherein the corresponding authorization data includes the user identifier of the current user, the centralized scene identifier corresponding to the centralized scene page, and the correspondence between the authorized status information; The step of obtaining the specified information of the current user in the corresponding mini-program based on the authorization data specifically includes: When entering the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, an authorization request is initiated through the corresponding mini-program without responding to the pop-up window; In response to the authorization request, either locally or on the server, the system verifies whether the user corresponding to the authorization request has been authorized and whether the scope of the requested authorization is reasonable, based on the user identifier and authorized status information contained in the generated authorization data. If so, the user's information will be sent to the corresponding mini-program.

6. The method of claim 1, wherein after the prior authorization, the method further comprises: Display the authorization settings options corresponding to the multiple mini-programs to the current user; If the current user cancels authorization for any of the multiple mini-programs by using the authorization settings, it is determined that the prior authorization is invalid for that mini-program. This prevents any mini-program from directly obtaining the current user's specified information based on the authorization data, while still allowing other mini-programs among the multiple mini-programs that have not been canceled to directly obtain the current user's specified information based on the authorization data.

7. The method as described in claim 1, wherein after directly obtaining the specified information of the current user based on the authorization data in the corresponding mini-program, the method further includes: Detect the business timing nodes in the corresponding mini-program that involve the specified information of the current user; Based on the temporal relationship of each of the aforementioned business opportunity nodes, a user information risk chain is generated; In response to the current user's request, the information risk link is displayed to the current user.

8. The method of claim 7, wherein the unified authorization request carries the intended use of the specified information of the current user; The step of generating a user information risk link based on the temporal relationship of each of the aforementioned business opportunity nodes specifically includes: The matching analysis between each of the aforementioned business timing nodes and the intended use yields the use deviation results; Based on the usage deviation results and the temporal relationship of each of the aforementioned business timing nodes, a user information risk link is generated.

9. The method of claim 7, wherein after displaying the information risk link to the current user, the method further includes: Receive the risk blocking point indicated by the current user in the information risk link; The path in the information risk link that is after the risk blocking point is blocked, and the business involved in the information risk link is rolled back to the risk blocking point or before it in the corresponding mini-program.

10. The method as described in claim 1 or 7, wherein before directly obtaining the specified information of the current user based on the authorization data in the corresponding mini-program, the method further includes: Based on the specified application, the corresponding mini-program's business characteristics, and the specified original information of the current user, a fake user is generated for the current user, along with the fake user's disguised feature information. The step of directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data specifically includes: Based on the authorization data, the disguised user's disguised feature information is directly obtained in the corresponding mini-program and used to perform the business of the corresponding mini-program for the current user.

11. A mini-program authorization processing device, comprising: The centralized scene entry module leads to the centralized scene page of the specified application, which has separate entry points for multiple mini-programs accessed by the specified application. The unified authorization request module initiates a unified authorization request corresponding to the multiple mini-programs to the current user on the centralized scene page. The authorization data triggering module generates corresponding authorization data if the current user agrees to pre-authorization in response to the unified authorization request. The mini-program quick processing module, after the prior authorization, if the current user enters the corresponding mini-program from the entry point in the centralized scene page, then in the corresponding mini-program, it directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

12. The apparatus of claim 11, wherein the authorization data triggering module, after the prior authorization, before the current user enters the corresponding mini-program from the entry point in the centralized scene page, does not allow the corresponding mini-program to directly obtain the specified information of the current user.

13. The apparatus of claim 11, wherein the unified authorization request module, in the centralized scene page, pops up a window for the current user and initiates a unified authorization request corresponding to the multiple mini-programs through the pop-up window, so that the current user can authorize by interacting with the pop-up window; The mini-program quick processing module directly obtains the user's information based on the authorization data in the corresponding mini-program, without requesting authorization from the current user through a pop-up window in the corresponding mini-program to obtain the current user's specified information.

14. The apparatus of claim 11, wherein the mini-program quick processing module, when entering the corresponding mini-program among the plurality of mini-programs from the entry point in the centralized scene page, sends the centralized scene identifier corresponding to the centralized scene page to the server, so that the server verifies whether the received corresponding centralized scene identifier matches the generated authorization data, and determines whether to allow the corresponding mini-program to directly obtain the user's information based on the matching result.

15. The apparatus of claim 14, wherein the corresponding authorization data includes the user identifier of the current user, the centralized scene identifier corresponding to the centralized scene page, and the correspondence between the authorized status information; When the mini-program quick processing module enters the corresponding mini-program from the entry point in the centralized scene page, it initiates an authorization request through the corresponding mini-program without responding to the pop-up window. In response to the authorization request, either locally or on the server, the system verifies whether the user corresponding to the authorization request has been authorized and whether the scope of the requested authorization is reasonable, based on the user identifier and authorized status information contained in the generated authorization data. If so, the user's information will be sent to the corresponding mini-program.

16. The apparatus of claim 11, wherein the authorization data triggering module displays the authorization setting options corresponding to the plurality of mini-programs to the current user after the prior authorization; If the current user cancels authorization for any of the multiple mini-programs by using the authorization settings, it is determined that the prior authorization is invalid for that mini-program. This prevents any mini-program from directly obtaining the current user's specified information based on the authorization data, while still allowing other mini-programs among the multiple mini-programs that have not been canceled to directly obtain the current user's specified information based on the authorization data.

17. The apparatus of claim 11, wherein the mini-program quick processing module, after directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data, detects a business timing node in the corresponding mini-program that involves the specified information of the current user; Based on the temporal relationship of each of the aforementioned business opportunity nodes, a user information risk chain is generated; In response to the current user's request, the information risk link is displayed to the current user.

18. The apparatus of claim 17, wherein the unified authorization request carries an intended use of the specified information for the current user; The mini-program quick processing module matches and analyzes each of the business timing nodes with the expected purpose to obtain the purpose deviation result; Based on the usage deviation results and the temporal relationship of each of the aforementioned business timing nodes, a user information risk link is generated.

19. The apparatus of claim 17, wherein the mini-program quick processing module, after displaying the information risk link to the current user, receives a risk blocking point indicated by the current user in the information risk link; The path in the information risk link that is after the risk blocking point is blocked, and the business involved in the information risk link is rolled back to the risk blocking point or before it in the corresponding mini-program.

20. The apparatus of claim 11 or 17, wherein the mini-program quick processing module, before directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data, generates a corresponding fake user for the current user through the specified application, based on the business characteristics of the corresponding mini-program and the specified original information of the current user, and generates the fake user's fake feature information; The step of directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data specifically includes: Based on the authorization data, the disguised user's disguised feature information is directly obtained in the corresponding mini-program and used to perform the business of the corresponding mini-program for the current user.

21. A mini-program authorization processing device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Enter the centralized scene page of the specified application, which has separate entry points for multiple mini-programs connected to the specified application; In the centralized scene page, a unified authorization request corresponding to the multiple mini-programs is initiated to the current user; If the current user responds to the unified authorization request and agrees to pre-authorization, then the corresponding authorization data is generated. After the prior authorization, if the current user enters the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, the corresponding mini-program directly obtains the specified information of the current user based on the authorization data, and uses it to perform the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

Images