WO2026037143A1 - Mini‑program authorization processing - Google Patents

Abstract

Disclosed in embodiments of the present disclosure are a mini-program authorization processing method, apparatus and device. The solution comprises: entering a centralized scenario page of a specified application, the centralized scenario page having respective entry points of a plurality of mini-programs integrated by the specified application; in the centralized scenario page, initiating to a current user a unified authorization request corresponding to the plurality of mini-programs; if the current user agrees to perform pre-authorization in response to the unified authorization request, triggering the generation of corresponding authorization data; and after the pre-authorization, if the current user enters a corresponding mini-program among the plurality of mini-programs from the corresponding entry point in the centralized scenario page, directly acquiring specified information of the current user in the corresponding mini-program on the basis of the authorization data, so as to perform a service of the corresponding mini‑program for the current user, without requesting authorization from the current user within the corresponding mini‑program.

Description

Mini Program Authorization Processing Technical Field

This disclosure relates to the field of mini-program technology, and in particular to mini-program authorization processing.

Background Technology

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.

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.

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.

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

This disclosure 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 accesses multiple mini-programs, a mini-program authorization scheme with a better user experience is needed.

To address the aforementioned technical problems, one or more embodiments of this disclosure provide a method for processing mini-program authorization, comprising: entering a centralized scene page of a specified application, the centralized scene page having entry points for multiple mini-programs accessed by the specified application; in the centralized scene page, initiating a unified authorization request corresponding to the multiple mini-programs to the current user; if the current user agrees to pre-authorization in response to the unified authorization request, triggering the generation of corresponding authorization data; after the pre-authorization, if the current user enters a corresponding mini-program from the entry point in the centralized scene page, the specified information of the current user 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, without requesting authorization from the current user in the corresponding mini-program.

This disclosure provides a mini-program authorization processing device according to one or more embodiments, comprising: a centralized scene entry module, which enters a centralized scene page of a specified application, the centralized scene page having separate entry points for multiple mini-programs accessed by the specified application; a unified authorization request module, which initiates a unified authorization request corresponding to the multiple mini-programs to the current user in the centralized scene page; an authorization data triggering module, which triggers the generation of corresponding authorization data if the current user agrees to pre-authorization in response to the unified authorization request; and a mini-program quick processing module, which, after pre-authorization, if the current user enters a corresponding mini-program from the entry point in the centralized scene page, directly obtains the specified information of the current user in the corresponding mini-program 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.

This disclosure provides a mini-program authorization processing device according to one or more embodiments, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform: entering a centralized scene page of a specified application, the centralized scene page having separate entry points for multiple mini-programs accessed by the specified application; in the centralized scene page, initiating a unified authorization request corresponding to the multiple mini-programs to the current user; if the current user agrees to pre-authorization in response to the unified authorization request, triggering the generation of corresponding authorization data; after the pre-authorization, if the current user enters a corresponding mini-program from the entry point in the centralized scene page, the specified information of the current user 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, without requesting authorization from the current user in the corresponding mini-program.

This disclosure provides a non-volatile computer storage medium storing computer-executable instructions, which are configured to: enter a centralized scene page of a specified application, the centralized scene page having entry points for multiple mini-programs accessed by the specified application; in the centralized scene page, initiate a unified authorization request to the current user corresponding to the multiple mini-programs; if the current user agrees to pre-authorization in response to the unified authorization request, trigger the generation of corresponding authorization data; after the pre-authorization, if the current user enters the corresponding mini-program 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.

The above-described at least one technical solution adopted in one or more embodiments of this disclosure can achieve the following beneficial effects: Considering that when a user enters the centralized scene page of a specified application (as the parent application), there is a high probability that the user will enter a mini-program through different mini-program entry points provided on 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 prior 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

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

Figure 1 is a flowchart illustrating a method for processing mini-program authorization according to one or more embodiments of this disclosure;

Figure 2 is a flowchart illustrating a scheme for obtaining specified user information in a mini-program according to one or more embodiments of this disclosure;

Figure 3 is a flowchart illustrating a quick authorization processing scheme for mini-programs in an application scenario provided by one or more embodiments of this disclosure;

Figure 4 is a schematic diagram of some page effects of the scheme in Figure 3 provided by one or more embodiments of this disclosure;

Figure 5 is a flowchart illustrating a risk defense scheme in conjunction with pre-authorization provided by one or more embodiments of this disclosure;

Figure 6 is a flowchart illustrating a user protection scheme for a mini-program provided by one or more embodiments of this disclosure;

Figure 7 is a schematic diagram of the structure of a mini-program authorization processing device provided in one or more embodiments of the present disclosure;

Figure 8 is a schematic diagram of the structure of a mini-program authorization processing device provided in one or more embodiments of this disclosure.

Detailed Implementation

This disclosure provides a method, apparatus, device, and storage medium for processing mini-program authorization.

To enable those skilled in the art to better understand the technical solutions in this disclosure, the technical solutions in the embodiments of this disclosure 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 disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

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.

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.

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.

Figure 1 is a flowchart illustrating a mini-program authorization processing method provided by one or more embodiments of this disclosure. 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 where the client is located, such as the user's smartphone, tablet, etc.

The process in Figure 1 includes the following steps.

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

In one or more embodiments of this disclosure, 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.

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).

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.

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

In one or more embodiments of this disclosure, 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.

In one or more embodiments of this disclosure, 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 a designated application. That is, in essence, the user is authorizing a 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.

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

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.

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.

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.

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.

In one or more embodiments of this disclosure, as mentioned above, the designated application can control the authorized permissions. Specifically, for example, 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.

Using the method shown in Figure 1, considering that when 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, the method can request prior authorization from the user on behalf of multiple mini-programs when the user initially arrives at the centralized scene page. This avoids requesting authorization separately from each mini-program the user might subsequently enter from there, greatly reducing the intrusion of authorization pop-ups on the user. Furthermore, if the user agrees to the prior authorization, this... The authorization can be easily controlled centrally by the parent application, preventing abuse by mini-programs. It 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 permission if the user has not yet entered the mini-program. Furthermore, the effectiveness 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 permission to use its authorized permissions, thus improving security. Therefore, the above solution effectively improves user experience while ensuring security.

Based on the method in Figure 1, this disclosure also provides some specific implementation schemes and extension schemes of the method, which will be further explained below.

This disclosure provides a flowchart illustrating a scheme for obtaining specified user information in a mini-program, as shown in Figure 2, through one or more embodiments.

The process shown in Figure 2 includes the following steps.

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.

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.

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.

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.

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.

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).

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.

In one or more embodiments of this disclosure, the authorization request initiated by the corresponding mini-program is directed 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. This way, when implementing this solution, it can minimize the need for the corresponding mini-program to also make modifications; only the specified application needs to make the modifications. This is more user-friendly for service providers of multiple mini-programs.

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.

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

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

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

The scheme shown in Figure 2 allows for precise and reliable control over whether a user's experience might be disrupted by authorization requests within the mini-program by maintaining a corresponding relationship that reflects the prior authorization status and performing corresponding verifications when the user actually enters the mini-program. At the same time, if necessary, users can also proactively control this in advance to improve their experience.

Based on the above description, one or more embodiments of this disclosure 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 the scheme, as shown in Figures 3 and 4 respectively.

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.

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.

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.

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.

In Figure 4, some information has been obscured without affecting understanding. From left to right, four sub-figures are visible. In the first figure, the user is on the main page of a centralized scenario called "xx Store." This page has a pop-up window for quick authorization management, which indicates that the requested permissions include the user's location and promotional information within the app (with a description of the intended use of this information). The user can click the "Allow" button to grant authorization. If the user agrees, the page shown in the second figure will be displayed. This page also prompts the user to manage quick authorization as needed, such as canceling quick authorization at any time via a quick authorization switch. The third figure exemplifies the access path to the quick authorization management page, and the fourth figure shows the quick authorization switch within the quick authorization management page. Of course, as explained above, if needed, more granular quick authorization switches for each mini-program can be added to the quick authorization management page.

The solution shown in Figure 3 is practical because the number of centralized scenarios is limited and controllable, thus avoiding the problem of excessive data expansion and high technical costs.

In one or more embodiments of this disclosure, under the case of prior authorization, the user actually entrusts more of the security responsibility to the designated application. In order to enable the user to more clearly perceive and deal with the risks, one or more embodiments of this disclosure also provide a flowchart of a risk defense scheme in conjunction with prior authorization, see Figure 5.

The process shown in Figure 5 includes the following steps.

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.

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.).

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.

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

In one or more embodiments of this disclosure, by arranging and linking the various business timing nodes according to their temporal relationships (where link branches may appear to cover business behaviors over a longer period of time within the corresponding mini-program), a visually concise user information risk link is generated. The business behaviors related to the specified information reflected on the user information risk link may contain potential risks. Therefore, this can be provided to users as a reference, enabling them to more clearly understand where the specified information is used.

Considering that the level of sophistication in the manifestation of user information risk links may vary in practical applications, and therefore may not be fully understood by all users, intelligent analysis methods can be used to help generate more user-friendly user information risk links. For example, assuming that the unified authorization request mentioned above carries the expected use of the specified information of the current user (such as the first subgraph in Figure 4), the detected business timing nodes can be matched and analyzed with the expected use to obtain the use deviation result. Based on the use deviation result and the temporal relationship of each business timing node, a user information risk link can be generated.

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

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.

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

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.

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.

To more reliably protect user privacy and achieve business rollback with less impact, one or more embodiments of this disclosure also provide a flowchart of a user protection scheme for a mini-program in a parent application, as shown in Figure 6.

The process shown in Figure 6 includes the following steps.

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.

In one or more embodiments of this disclosure, a designated application remaps the current user's real account to generate a new account to represent the current user, thus becoming 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 application also attempts to disguise the current user's original information to obtain the disguised user's 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. 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.

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.

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.

Based on the same approach, one or more embodiments of this disclosure also provide apparatus and devices corresponding to the above methods, as shown in Figures 7 and 8. The apparatus and devices are capable of executing the above methods and related optional solutions accordingly.

Figure 7 is a schematic diagram of a mini-program authorization processing device provided in one or more embodiments of this disclosure. The device includes: a centralized scene entry module 702, which enters a centralized scene page of a specified application, the centralized scene page having separate entry points for multiple mini-programs accessed by the specified application; a unified authorization request module 704, which initiates a unified authorization request corresponding to the multiple mini-programs to the current user in the centralized scene page; an authorization data triggering module 706, which triggers the generation of corresponding authorization data if the current user agrees to pre-authorization in response to the unified authorization request; and a mini-program quick processing module 708, which, after pre-authorization, if the current user enters the corresponding mini-program from the entry point in the centralized scene page, directly obtains the specified information of the current user in the corresponding mini-program 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.

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.

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; the mini-program quick processing module 708 directly obtains the user's information in the corresponding mini-program based on the authorization data, without popping up a window for authorization to the current user in the corresponding mini-program to obtain the current user's specified information.

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.

Optionally, the corresponding authorization data includes the correspondence between the current user's user identifier, the centralized scene identifier corresponding to the centralized scene page, and the authorized status information; the mini-program quick processing module 708, when entering the corresponding mini-program among the multiple mini-programs from the entry point in the centralized scene page, initiates an authorization request through the corresponding mini-program without responding to a pop-up window; responding to the authorization request locally or on the server side, it 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, it sends the user's information to the corresponding mini-program.

Optionally, the authorization data triggering module 706, after the pre-authorization, displays the authorization settings options corresponding to the multiple mini-programs to the current user; if it receives that the current user cancels the authorization for any of the multiple mini-programs by operating the authorization settings options, it determines that the pre-authorization is invalid for any of the mini-programs, so that no mini-program is allowed to directly obtain the current user's specified information based on the authorization data, while other mini-programs among the multiple mini-programs that have not been canceled are still allowed to directly obtain the current user's specified information based on the authorization data.

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 business timing nodes in the corresponding mini-program that involve the specified information of the current user; generates a user information risk link based on the temporal relationship of each business timing node; and displays the information risk link to the current user in response to the current user's request.

Optionally, the unified authorization request carries the intended use of the specified information of the current user; the mini-program quick processing module 708 matches and analyzes each of the business timing nodes with the intended use to obtain the use deviation result; and generates a user information risk link based on the use deviation result and the temporal relationship of each of the business timing nodes.

Optionally, after the information risk link is displayed to the current user, the mini-program quick processing module 708 receives the risk blocking point indicated by the current user in the information risk link; blocks the path after the risk blocking point in the information risk link; and rolls back the business involved in the information risk link to the risk blocking point or before it in the corresponding mini-program.

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 and fake user feature information 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; the step of directly obtaining the specified information of the current user in the corresponding mini-program based on the authorization data specifically includes: directly obtaining the fake user feature information in the corresponding mini-program based on the authorization data, for use in performing the business of the corresponding mini-program for the current user.

Figure 8 is a schematic diagram of the structure of a mini-program authorization processing device provided in one or more embodiments of this disclosure. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to: enter a centralized scene page of a specified application, the centralized scene page having separate entry points for multiple mini-programs accessed by the specified application; in the centralized scene page, initiate a unified authorization request corresponding to the multiple mini-programs to the current user; if the current user agrees to pre-authorization in response to the unified authorization request, trigger the generation of corresponding authorization data; after the pre-authorization, if the current user enters a corresponding mini-program 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 this information 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.

Based on the same idea, one or more embodiments of this disclosure also provide a non-volatile computer storage medium storing computer-executable instructions, the computer-executable instructions being configured to: enter a centralized scene page of a specified application, the centralized scene page having entry points for multiple mini-programs accessed by the specified application; in the centralized scene page, initiate a unified authorization request to the current user corresponding to the multiple mini-programs; if the current user agrees to pre-authorization in response to the unified authorization request, trigger the generation of corresponding authorization data; after the pre-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, based on the authorization data, directly obtain the specified information of the current user for performing the business of the corresponding mini-program for the current user, without requesting authorization from the current user in the corresponding mini-program.

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 improvements to the methodology 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 an improvement to the methodology 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 a digital system themselves to "integrate" it onto a PLD, 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 is not just one type of HDL, but many, such as ABEL (Advanced Boolean Expression Language) and AHDL (Altera Hardware Description Language). Hardware description languages such as Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language) are commonly used, with VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog being the most prevalent currently. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these languages and then programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

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, ASICs, 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.

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, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing this disclosure, the functions of each unit can be implemented in one or more software and/or hardware.

Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, embodiments of this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this disclosure can take the form of a computer program product embodied 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.

This disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. 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 means for implementing the functions specified in one or more flowchart illustrations and/or one or more block diagrams.

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 that implement the functions specified in one or more flowcharts and/or one or more block diagrams.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and/or one or more block diagrams.

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

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.

Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by 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.

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.

This disclosure 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 disclosure 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.

The various embodiments in this disclosure 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.

The foregoing has described specific embodiments of this disclosure. 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 results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

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

Claims (21)

A method for handling WeChat Mini Program authorization includes: 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. The method of claim 1, further comprising, after the prior authorization: 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. 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. 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. 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. The method of claim 1, further comprising, after the prior authorization: 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. The method as described in claim 1, after directly obtaining the specified information of the current user based on the authorization data in the corresponding mini-program, 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. 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. 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. The method as described in claim 1 or 7, prior to directly obtaining the specified information of the current user based on the authorization data in the corresponding mini-program, 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. 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. 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. 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. The device as described in 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 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. 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. 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. 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 the 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. The apparatus of claim 17, wherein the unified authorization request carries an intended use of the specified information of 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. The device as described in 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. The device as described in 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. A mini-program authorization processing device, comprising: At least one processor; and, 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.