Small program authorization processing method, device and equipment
By uniformly initiating authorization requests and generating pre-authorization data in the centralized scenario page of the parent application, the problem of poor user experience when the parent application connects to multiple mini-programs is solved, achieving more efficient authorization processing and improving user experience and security.
Patent Information
- Application Number
- CN202511603390.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-13
- Publication Date
- 2026-01-23
AI Technical Summary
In scenarios where a parent application integrates multiple mini-programs, users experience poor performance due to frequent authorization request pop-ups, which impacts traffic acquisition and user churn.
In a centralized scenario page, a unified authorization request is initiated to the user to generate pre-authorization data. Once the user agrees, the authorization information is directly obtained when entering the mini program, avoiding repeated authorization requests within the mini program.
It reduces the intrusiveness of authorization pop-ups, improves user experience, enhances security and platform competitiveness, and reduces the risk of mini-programs abusing permissions.
Smart Images

Figure CN121389159A_ABST
Abstract
Description
[0001] This application is a divisional application of the invention patent application No. 202411111916.4, filed on August 13, 2024, with the Chinese Patent Office, and entitled "A Mini-Program Authorization Processing Method, Device and Equipment", the entire contents of which are incorporated herein by reference. TECHNICAL FIELD
[0002] The present specification relates to the technical field of mini-programs, and in particular to a mini-program authorization processing method, device and equipment. BACKGROUND
[0003] With the development of Internet technology and the popularization of smart phones, more and more businesses are carried out through various applications, which has also generated some large and medium-sized comprehensive platform applications.
[0004] Some sub-applications of the service provider to which the comprehensive platform application belongs, or applications of other small and medium-sized service providers, will provide services in the form of mini-programs, which are embedded in the comprehensive platform application. The comprehensive platform application is regarded as a parent application, and the mini-program can be run relying on the parent application, so as to provide services to users more lightweightly, and users do not need to download and install these small application clients separately, thereby improving the user experience and helping to obtain more traffic through the parent application.
[0005] Under such circumstances, the parent application often accesses many mini-programs, and some users can also frequently access different mini-programs in the parent application. The current mini-program usually needs to provide authorization of geographic location, avatar nickname, mobile phone number, discount, message, etc. when used. The mini-program will request the user's authorization through a pop-up window. In this case, the user who accesses different mini-programs in a short time will be frequently disturbed by the authorization request pop-up window of different mini-programs, thereby affecting the user experience, and further affecting the effectiveness of the mini-program in obtaining and converting traffic, and even the parent application itself may also lose users.
[0006] Based on this, in the scenario where the parent application accesses multiple mini-programs, a mini-program authorization scheme with better user experience is needed. SUMMARY
[0007] One or more embodiments of the present specification provide a mini-program authorization processing method, device, equipment and storage medium to solve the technical problem that in the scenario where the parent application accesses multiple mini-programs, a mini-program authorization scheme with better user experience is needed.
[0008] To solve the above technical problem, one or more embodiments of the present specification are implemented as follows: The mini-program authorization processing method provided by one or more embodiments of the present specification comprises: enter a centralized scene page of a specified application, the centralized scene page having entrances of a plurality of applets respectively accessed by the specified application; in the centralized scene page, initiate a unified authorization request corresponding to the plurality of applets to a current user; if the current user agrees to pre-authorization in response to the unified authorization request, trigger corresponding authorization data generation; after the pre-authorization, if the current user enters a corresponding applet of the plurality of applets from the entrance in the centralized scene page, directly obtain specified information of the current user in the corresponding applet according to the authorization data, for performing a business of the corresponding applet for the current user, without requesting authorization of the current user in the corresponding applet.
[0009] One or more embodiments of the present specification provide an applet authorization processing apparatus, comprising: a centralized scene entering module, which enters a centralized scene page of a specified application, the centralized scene page having entrances of a plurality of applets respectively accessed by the specified application; a unified authorization request module, which initiates a unified authorization request corresponding to the plurality of applets to a current user in the centralized scene page; an authorization data triggering module, which triggers corresponding authorization data generation if the current user agrees to pre-authorization in response to the unified authorization request; an applet shortcut processing module, which, after the pre-authorization, directly obtains specified information of the current user in a corresponding applet of the plurality of applets according to the authorization data if the current user enters the corresponding applet from the entrance in the centralized scene page, for performing a business of the corresponding applet for the current user, without requesting authorization of the current user in the corresponding applet.
[0010] One or more embodiments of the present specification provide an applet authorization processing device, comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable 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 a centralized scene page of a specified application, the centralized scene page having entrances of a plurality of applets respectively accessed by the specified application; in the centralized scene page, initiate a unified authorization request corresponding to the plurality of applets to a current user; if the current user agrees to the pre-authorization in response to the unified authorization request, triggering corresponding authorization data generation; After the pre-authorization, if the current user enters a corresponding mini-program in the plurality of mini-programs from the entrance in the centralized scene page, specified information of the current user is directly obtained in the corresponding mini-program according to the authorization data, for performing a business of the corresponding mini-program for the current user, without requesting authorization of the current user in the corresponding mini-program.
[0011] One or more embodiments of the specification provide a non-volatile computer storage medium, which stores computer executable instructions, the computer executable instructions are configured to: enter a centralized scene page of a specified application, the centralized scene page has entrances of a plurality of mini-programs respectively accessed by the specified application; in the centralized scene page, a unified authorization request corresponding to the plurality of mini-programs is initiated to a current user; if the current user agrees to the pre-authorization in response to the unified authorization request, triggering corresponding authorization data generation; After the pre-authorization, if the current user enters a corresponding mini-program in the plurality of mini-programs from the entrance in the centralized scene page, specified information of the current user is directly obtained in the corresponding mini-program according to the authorization data, for performing a business of the corresponding mini-program for the current user, without requesting authorization of the current user in the corresponding mini-program.
[0012] The above at least one technical solution adopted by one or more embodiments of the present specification can achieve the following beneficial effects: considering that if the current user enters the centralized scene page of the specified application (as the parent application), there is a great probability that the user will enter the applet provided by the different applet entry of the page, and it is also possible to exit the applet back to the page and enter other applets, so multiple different applets are used in a short period of time. Therefore, when the user initially arrives at the centralized scene page, the user can be uniformly requested to perform pre-authorization on behalf of multiple applets, and the user can be individually requested to authorize the user in the applet that the user may further enter from the page. Therefore, the authorization pop-up window greatly reduces the disturbance to the user. Furthermore, in the case where the user agrees to the pre-authorization, such authorization can be conveniently controlled by the parent application, preventing the abuse of applets, so that the applet can only use the authorized limit after the user actually enters the applet from the centralized scene page. If the user has not entered the applet, the applet can still be prevented from using the authorized limit even if the user has performed pre-authorization. In addition, the validity of the pre-authorization can be converged within the jurisdiction of the centralized scene page, so that the applet can still be prevented from using the authorized limit if the user enters the applet from a channel other than the centralized scene page. Therefore, the security is improved. Therefore, the above solution can effectively improve the user experience and take into account the security. BRIEF DESCRIPTION OF DRAWINGS
[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.
[0014] Figure 1 A flowchart of a small program authorization processing method provided by one or more embodiments of the present specification; Figure 2 A flowchart of a scheme for obtaining specified information of a user in an applet provided by one or more embodiments of the present specification; Figure 3 A flowchart of a small program quick authorization processing scheme in an application scenario provided by one or more embodiments of the present specification; Figure 4 Some page effect diagrams of the scheme provided by one or more embodiments of the present specification Figure 3 Figure 5 A flowchart of a risk defense scheme cooperating with pre-authorization provided for one or more embodiments of the present specification; Figure 6 A flowchart of a user protection scheme of a mother application for a miniprogram provided for one or more embodiments of the present specification; Figure 7 A structural diagram of a miniprogram authorization processing apparatus provided for one or more embodiments of the present specification; Figure 8 A structural diagram of a miniprogram authorization processing apparatus provided for one or more embodiments of the present specification. DETAILED DESCRIPTION
[0015] The embodiments of the present specification provide a miniprogram authorization processing method, apparatus, device and storage medium.
[0016] In order for those skilled in the art to better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be described clearly and completely below in conjunction with the drawings in the embodiments of the present specification. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments of the present specification, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the present application.
[0017] As mentioned in the background, for some large and medium-sized comprehensive platform applications, users enter miniprograms in a centralized scenario, which may have experience problems such as frequent pop-up windows and long and confusing processes. This also brings more negative effects, including: platform and merchant process loss, waste of operating costs, for example, when the miniprogram is a non-famous merchant, the user does not understand the scene and has no brand endorsement, and the experience is poor, the authorization pass rate is low; low platform satisfaction, affecting user revisit and retention, for example, users entering the centralization have demands for famous miniprograms, although due to targeted consumption and brand endorsement, the authorization pass rate may not be affected, but compared with other platforms that may do better, it may affect the overall satisfaction of users with the platform, thereby affecting the competitiveness of the platform.
[0018] In order to solve these problems, the present application can quickly request pre-authorization from users in the scenario of platform centralized traffic distribution, and try to avoid separate authorization requests by each miniprogram, thereby reducing the disturbance of multiple pop-up windows, and without the need for miniprograms to make troublesome adaptation and modification, which helps to improve user experience, platform satisfaction and conversion rate. Based on such overall idea, the scheme of the present application will be further described below.
[0019] Regarding authorization, based on the legal and legitimate principles of personal information protection, the minimum necessary principle, the right to know and the right of autonomy of users, when a third party or other non-information holder needs to obtain the information left by the user in the current platform to complete the service, the full consent of the user is required. For example, assuming that the user wants to use the car-hailing service provided by other platforms on the current platform, currently, the user generally has two choices, one is to choose to input a new mobile phone number to register a new account, and the other is to choose to use the current platform account to quickly log in, in this case, the user agrees to authorize the account information of the current platform to the other platform.
[0020] Figure 1 A flowchart of a small program authorization processing method provided for one or more embodiments of the present specification. The execution subject of the flowchart can include the client of the specified application (here, the small program accessed in the client can also be considered as a whole with the client), and can also include the corresponding server. For the case of the client, the hardware execution subject also includes the device where the client is located, such as the user's smartphone, tablet computer, etc.
[0021] Figure 1 The flowchart in the above embodiment includes the following steps: S102: Enter the centralized scene page of the specified application, and the centralized scene page has an entry for each of the small programs accessed by the specified application.
[0022] In one or more embodiments of the present specification, the specified application can be the parent application mentioned in the background technology, and can be a large and medium-sized platform application with large traffic, which guides the flow of one or more centralized scene pages for the cooperation of multiple small programs to improve the access volume of users to these small programs.
[0023] The centralized scene mentioned here is essentially a centralized traffic distribution scene, which is a centralized traffic entrance provided by the platform for other cooperation parties, and the centralized scene page can be the home page under the scene. For example, the business scene home pages of the consumption circle, citizen center, game center, medical center, etc. provided by a payment platform, which is similar to the public area after entering the commercial complex in the offline, and the user can freely choose to go to the store (similar to the small program) of his interest.
[0024] The separate entrances of the applets are usually presented in the form of links with corresponding icons, cards or texts in the centralized scene page, and the user can jump into the corresponding applet by clicking. It should be noted that after jumping into the applet, the user is generally still in the specified application, but according to different cooperation modes and technical implementation modes, the user can also be separated from the specified application. In this case, the scheme of the present application can be continued to be implemented based on the cooperation between applications or the assistance at the operating system level, and the execution subject of the scheme can be increased accordingly.
[0025] S104: In the centralized scene page, a unified authorization request corresponding to the plurality of applets is initiated to the current user.
[0026] In one or more embodiments of the present specification, in the centralized scene page, a pop-up window is popped up to the current user, and a unified authorization request corresponding to the plurality of applets is initiated through the popped window, so that the current user authorizes by interacting with the popped window. In addition to the pop-up window mode, other modes such as banner, mark, additional small screen notification and the like can also be used. Of course, these modes may actually disturb the user to a certain extent, but the present application is exactly for this one-time possible disturbance to exchange for no need to disturb the user again in different applets in the future, so it is very cost-effective overall.
[0027] In one or more embodiments of the present specification, the authorization requested by the unified authorization request is called pre-authorization, that is, the authorization performed before the current user enters each applet, but it should be noted that although the authorized permission is uniformly for the plurality of applets, it is also controlled by the specified application. That is, in essence, the user is authorizing the specified application, and the specified application can control when the permission takes effect and which applet the permission takes effect according to the need, so as to avoid authorization generalization and multiple applets abusing the permission. In addition, even the specified application itself can also limit the specific conditions under which the specified application can use the permission according to the pre-negotiation with the user or the security policy of the platform itself.
[0028] S106: If the current user agrees to pre-authorization in response to the unified authorization request, the corresponding authorization data generation is triggered.
[0029] 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.
[0030] 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.
[0031] The specified information requires the current user's authorization to be accessed. This information 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.
[0032] 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.
[0033] In one or more embodiments of the present specification, the aforementioned designated application can control the authorized permission, for example, after the pre-authorization, the corresponding small program is not allowed to directly obtain the specified information of the current user before the current user enters the corresponding small program from the entrance of the centralized scene page, and the corresponding small program can obtain the specified information of the current user only after entering the corresponding small program. In addition, if the current user enters the corresponding small program from other channels other than the centralized scene page, the use of the authorized permission can also be prohibited. In this case, the pre-authorization performed by the user is actually more strictly for the centralized scene page. This helps to protect the information security of the user.
[0034] By the method of Figure 1 , it is considered that if the current user enters the centralized scene page of the designated application (as the parent application), there is a high probability that the user will enter the small program through different small program entrances provided by the page, and it is also possible to exit the small program and return to the page, and then enter other small programs, so that multiple different small programs are used in a short period of time. Therefore, when the user initially arrives at the centralized scene page, the pre-authorization can be uniformly requested from the user on behalf of multiple small programs, and the user is not separately requested to authorize in the small program that the user may further enter from the page. Therefore, the authorization pop-up window greatly reduces the disturbance to the user. Furthermore, in the case where the user agrees to the pre-authorization, such authorization can be conveniently controlled by the parent application, preventing the abuse of small programs, so that the small program can actually use the authorized permission only after the user actually enters the small program from the centralized scene page. If the user has not entered the small program, the small program can still be prohibited from using the authorized permission even if the user has performed the pre-authorization. In addition, the validity of the pre-authorization can be converged within the jurisdiction of the centralized scene page, so that the small program can still be prohibited from using the authorized permission if the user enters the small program from a channel other than the centralized scene page. Therefore, the security is improved. Therefore, the above-mentioned scheme can effectively improve the user experience and take into account the security.
[0035] Based on the method of Figure 1 , the present specification also provides some specific embodiments and extension schemes of the method, which will be described below.
[0036] The present specification one or more embodiments provides a flowchart of a scheme for obtaining the specified information of the user in the small program, as shown in Figure 2 .
[0037] Figure 2 The flowchart in S202: After the pre-authorization, determine the generated corresponding authorization data, which includes the correspondence between the user identifier of the current user, the centralized scene identifier corresponding to the centralized scene page, and the authorized state information.
[0038] The corresponding applet identifier can also be added to the above correspondence, so that the above correspondence can be maintained separately for a certain applet.
[0039] The pre-authorization is by default for all applets in the centralized scene corresponding to the centralized scene identifier, but not all users can trust these applets, and some applets may even be repelled by users, so the user can be provided with separate management means. For example, after pre-authorization, the current user can be shown authorization setting options corresponding to multiple applets, and if the current user receives an operation authorization setting option, sets to cancel authorization for any one of the multiple applets, determines that the pre-authorization is invalid for the any one applet (for example, the identifier of the any one applet can be removed from the above correspondence), so that the any one applet is not allowed to directly obtain the specified information of the current user according to the authorization data, and the other applets in the multiple applets that have not been canceled are still allowed to directly obtain the specified information of the current user according to the authorization data; similarly, the user can also make the above settings in advance.
[0040] S204: When entering the corresponding applet in the multiple applets from the entrance in the centralized scene page, send the centralized scene identifier corresponding to the centralized scene page to the server for verification.
[0041] The server can verify whether the received corresponding centralized scene identifier matches the generated authorization data, and determine whether to allow the corresponding applet to directly obtain the user's information according to the matching result. For example, if it is determined through matching that the centralized scene identifier contained in a certain generated authorization data is the corresponding centralized scene identifier currently received by the server, and both sides such as user identifier, authorization range, etc. match, then the corresponding applet can be allowed to directly obtain the user's information, otherwise it can be rejected. The action of this verification can also be performed on the user terminal, and for this case, the authorization data can be saved on the user terminal in advance, so that efficient verification can be performed.
[0042] The verification here can also be simplified, for example, only the centralized scene corresponding to the received centralized scene identifier is verified to support pre-authorization, and if it supports, the verification is passed. Thus, it can be more efficient to determine whether the current applet entry channel is the channel (i.e., from a specific centralized scene) that this solution is aimed at.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] The verifications in steps S204 and S208 can be performed together or at different times.
[0047] S210: If so, the user's information is sent to the corresponding mini-program.
[0048] If the verification fails, the corresponding mini-program can be allowed to pop up a request for authorization from the current user.
[0049] 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.
[0050] 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 .
[0051] In this scheme, one or more centralized scenarios, such as "xx store", "consumption circle", etc., can be determined in advance in the app (i.e., the designated application described above), which access a plurality of merchant mini-programs. A corresponding distinguishing identifier can be set for each centralized scenario, for example, referred to as a centralized scenario channel identifier, such as values A, B, C, etc. When the user jumps from the centralized scenario main page to a mini-program therein, the corresponding scenario channel identifier can be carried by the current client to the server.
[0052] Initially, it is assumed that the user has not yet authorized, at this time when entering the centralized scenario, the app can invoke a quick authorization management pop-up window to request the user to perform the unified pre-authorization in the scenario. If the user agrees to authorize, a quick authorization relationship can be created for the user as the above authorization data, saved locally or on the server. The example quick authorization relationship includes, for example, scenario channel identifier (A / B / C) + user identifier + opening state + pop-up window exemption authorization range. If the user refuses to authorize, the pop-up window is closed.
[0053] After the user agrees to authorize, if the user has not yet jumped from the centralized scenario to a certain merchant mini-program, the merchant mini-program still cannot obtain the user data corresponding to the permission (i.e., the specified information described above). That is, for the merchant mini-program, the permission has not yet taken effect in essence, thereby helping to reduce the risk of misuse of user data by the merchant.
[0054] When the user jumps from the centralized scenario to a certain merchant mini-program, the merchant mini-program initiates an authorization request, the system checks whether the user has opened the quick authorization and the authorization range contains the request range of the merchant, and checks the success. Then the user data corresponding to the permission is directly returned, otherwise, an authorization request pop-up window can be invoked for the user to confirm the authorization.
[0055] In Figure 4The illustrations have some information obscured to maintain clarity. 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 displays a quick authorization management pop-up, 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 permissions. If the user agrees, the page shown in the second image will appear, prompting the user to manage quick authorizations as needed, such as canceling them 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 the quick authorization management 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.
[0056] 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.
[0057] 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 .
[0058] Figure 5 The process 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.
[0059] 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.).
[0060] 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.
[0061] S504: generating a user information risk link according to the time sequence relationship of each business opportunity node.
[0062] In one or more embodiments of the present specification, the user information risk link is generated by arranging and linking each business opportunity node according to the time sequence relationship (where link branches may occur to cover business behaviors in a longer time range in the corresponding applet). The business behaviors reflected on the user information risk link for the specified information may contain potential risks, so the user can be given as a reference to make the user more clearly understand where the specified information is actually used.
[0063] Considering that the professionalism of the user information risk link in actual application may be different, it may not be fully understood by users, so intelligent analysis means can be used to help generate a user information risk link that is more friendly to users. For example, assuming that the above unified authorization request carries the expected use of the specified information of the current user (such as Figure 4 The first subgraph in the above belongs to this case), the detected each business opportunity node can be matched and analyzed with the expected use to obtain a use deviation result, and the user information risk link is generated according to the use deviation result and the time sequence relationship of each business opportunity node.
[0064] S506: In response to the request of the current user, the information risk link is displayed to the current user.
[0065] The information risk link can not be displayed by default, and the user can actively operate to call out the information risk link if the user wants to observe. Alternatively, the information risk link can also be actively displayed to the user when it is automatically detected that there is a risk.
[0066] S508: receiving the risk blocking point indicated by the current user in the information risk link.
[0067] Not only does the above provide a means for the user to discover risks, but it also further provides a flexible and timely solution to risks. The user can select a business opportunity node that the user considers to be at risk or that the system prompts to be at risk in the information risk link, and then the business opportunity node is used as a risk blocking point.
[0068] S510: blocking the path in the information risk link after the risk blocking point, and rolling back the business involved in the information risk link to the risk blocking point or before the risk blocking point in the corresponding applet.
[0069] To protect user privacy more reliably and achieve business rollback with less impact, one or more embodiments of the present specification also provide a flowchart of a user protection scheme of a parent application for a miniprogram, see Figure 6 .
[0070] Figure 6 The flow in the above includes the following steps: S602: Before directly obtaining the specified information of the current user in the corresponding miniprogram according to the authorization data, the specified application generates a corresponding disguised user for the current user and generates the disguised feature information of the disguised user according to the business characteristics of the corresponding miniprogram and the specified original information of the current user.
[0071] In one or more embodiments of the present specification, the specified application will remap the real account of the current user to generate a new account to represent the current user, i.e., become a disguised user. Moreover, according to the business characteristics of the corresponding miniprogram, the specified original information of the current user is also disguised as much as possible under the condition that the corresponding miniprogram is basically sufficient for normal business, to obtain the disguised feature information of the disguised user. For example, for a food delivery miniprogram, the minimum requirement for the user is the delivery address, so other information can be blurred or confused with other users as much as possible, and the delivery address can also be lightly blurred (for example, blurred to the floor but not specific to the house number; for example, blurred to a dynamic address pre-accepted by a user within tens of meters or even dozens of meters of the actual delivery address; etc.), thereby achieving disguise.
[0072] S604: When directly obtaining the specified information of the current user in the corresponding miniprogram according to the authorization data, specifically, directly obtaining the disguised feature information of the disguised user in the corresponding miniprogram according to the authorization data, for the current user to perform the business of the corresponding miniprogram.
[0073] Thus, for the designated application, the corresponding applet can not only normally complete the business, but also avoid accurate grasping of user information. Moreover, assuming that the risk blocking rollback operation is supported, the designated application can generate two or more pseudo users for the same applet of the same user, and generate pseudo feature information for them respectively. Initially, only one of the pseudo users is provided to the applet. If the pseudo user is subject to risk blocking rollback, the remaining business logic is copied or replaced to a remaining pseudo user after rollback, so that the applet continues to complete the business for the remaining pseudo user. Of course, in this scheme, the remaining pseudo user can also be replaced by a real user, for example, a real user can be enabled for the applet after determining that there is a high probability of no risk. In this way, the pseudo user can help the real user to explore the risk and more reliably establish a business path with a high probability of no risk, so that the applet can complete the business, thereby more strongly protecting user privacy and security.
[0074] Based on the same idea, one or more embodiments of the present specification also provide a device and equipment corresponding to the above method, as shown in Figure 7 、 Figure 8 The device and equipment can correspondingly execute the above method and related optional solutions.
[0075] Figure 7 A structural schematic diagram of an applet authorization processing device provided by one or more embodiments of the present specification is provided, and the device comprises: A centralized scene entering module 702 enters a centralized scene page of a designated application, and the centralized scene page has entrances of a plurality of applets respectively accessed by the designated application; A unified authorization request module 704 initiates a unified authorization request corresponding to the plurality of applets to a current user in the centralized scene page; An authorization data triggering module 706 triggers corresponding authorization data generation if the current user agrees to pre-authorization in response to the unified authorization request; An applet shortcut processing module 708 directly obtains specified information of the current user in the corresponding applet according to the authorization data if the current user enters the corresponding applet of the plurality of applets from the entrance in the centralized scene page after the pre-authorization, and the specified information is used to perform business of the corresponding applet for the current user, without requesting authorization of the current user in the corresponding applet.
[0076] Optionally, the authorization data triggering module 706, after the pre-authorization, does not allow the corresponding applet to directly obtain the specified information of the current user before the current user enters the corresponding applet from the entrance in the centralized scene page.
[0077] Optionally, the unified authorization request module 704, in the centralized scene page, pops up a window to the current user, initiates a unified authorization request corresponding to the plurality of applets through the popped window, so that the current user authorizes by interacting with the popped window; The applet shortcut processing module 708 directly obtains the information of the user according to the authorization data in the corresponding applet, without popping up a window to request authorization to obtain the specified information of the current user in the corresponding applet.
[0078] Optionally, the applet shortcut processing module 708, when entering the corresponding applet in the plurality of applets from the entrance in the centralized scene page, sends the centralized scene identifier corresponding to the centralized scene page to the server, so that the server checks whether the received corresponding centralized scene identifier matches the generated authorization data, and determines whether to allow the corresponding applet to directly obtain the information of the user according to the matching result.
[0079] Optionally, the corresponding authorization data includes a corresponding relationship between the user identifier of the current user, the centralized scene identifier corresponding to the centralized scene page, and the authorized state information; The applet shortcut processing module 708, when entering the corresponding applet in the plurality of applets from the entrance in the centralized scene page, initiates an authorization request through the corresponding applet without corresponding pop-up window; In response to the authorization request, the server checks whether the user corresponding to the authorization request has been authorized according to the user identifier and the authorized state information contained in the generated authorization data, and whether the authorization range of the requested authorization is reasonable; If so, the information of the user is sent to the corresponding applet.
[0080] Optionally, the authorization data triggering module 706, after the pre-authorization, displays the authorization setting options corresponding to the plurality of applets to the current user; If the current user receives an operation authorization setting option, sets the authorization cancellation for any applet in the plurality of applets, it is determined that the pre-authorization is invalid for the any applet, so that the any applet is not allowed to directly obtain the specified information of the current user according to the authorization data, and other applets in the plurality of applets that have not been cancelled are still allowed to directly obtain the specified information of the current user according to the authorization data.
[0081] Optionally, the applet shortcut processing module 708 detects a business time node related to the specified information of the current user in the corresponding applet after directly obtaining the specified information of the current user in the corresponding applet according to the authorization data. According to the time sequence relationship of each business time node, a user information risk link is generated. In response to a request of the current user, the information risk link is displayed to the current user.
[0082] Optionally, the unified authorization request carries an intended use of the specified information of the current user. The applet shortcut processing module 708 matches and analyzes each business time node and the intended use to obtain a use deviation result. According to the use deviation result and the time sequence relationship of each business time node, a user information risk link is generated.
[0083] Optionally, the applet shortcut processing module 708 receives a risk blocking point indicated by the current user in the information risk link after displaying the information risk link to the current user. The path after the risk blocking point in the information risk link is blocked, and the business related to the information risk link in the corresponding applet is rolled back to the risk blocking point or before the risk blocking point.
[0084] Optionally, the applet shortcut processing module 708 generates a corresponding pseudo user for the current user and generates pseudo feature information of the pseudo user according to the business characteristics of the corresponding applet and the specified original information of the current user through the specified application before directly obtaining the specified information of the current user in the corresponding applet according to the authorization data. The directly obtaining the specified information of the current user in the corresponding applet according to the authorization data specifically includes: Directly obtaining the pseudo feature information of the pseudo user in the corresponding applet according to the authorization data, for performing the business of the corresponding applet for the current user.
[0085] Figure 8 A structural schematic of an applet authorization processing device is provided for one or more embodiments of the present specification, and the device comprises: at least one processor; and, a memory in communication connection with the at least one processor; wherein, the memory stores instructions executable 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 a centralized scene page of a specified application, the centralized scene page having entrances of a plurality of applets respectively accessed by the specified application; in the centralized scene page, initiate a unified authorization request corresponding to the plurality of applets to a current user; if the current user agrees to pre-authorization in response to the unified authorization request, trigger corresponding authorization data generation; after the pre-authorization, if the current user enters a corresponding applet in the plurality of applets from the entrance in the centralized scene page, directly obtains specified information of the current user in the corresponding applet according to the authorization data, for performing a business of the corresponding applet for the current user, without requesting authorization to the current user in the corresponding applet.
[0086] Based on the same idea, one or more embodiments of the present specification also provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are configured to: enter a centralized scene page of a specified application, the centralized scene page having entrances of a plurality of applets respectively accessed by the specified application; in the centralized scene page, initiate a unified authorization request corresponding to the plurality of applets to a current user; if the current user agrees to pre-authorization in response to the unified authorization request, trigger corresponding authorization data generation; after the pre-authorization, if the current user enters a corresponding applet in the plurality of applets from the entrance in the centralized scene page, directly obtains specified information of the current user in the corresponding applet according to the authorization data, for performing a business of the corresponding applet for the current user, without requesting authorization to the current user in the corresponding applet.
[0087] In the 1990s, it was possible to distinguish whether an improvement in a technology was a hardware improvement (e.g., an improvement in the circuit structure of a diode, transistor, switch, etc.) or a software improvement (an improvement in a method flow). However, as technology has advanced, many improvements in method flows today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into a hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A designer programs a digital system "integrated" on a PLD by himself / herself, without having to ask a chip manufacturer to design and manufacture a special integrated circuit chip. Moreover, instead of manually manufacturing an integrated circuit chip, this programming is now mostly implemented using "logic compiler" software, which is similar to a software compiler used when developing a program, and the original code before compilation must also be written in a specific programming language, which is called a hardware description language (HDL), and there are many types of HDL, 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, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that it is only necessary to logically program a method flow using the above-mentioned hardware description languages and program it into an integrated circuit to easily obtain a hardware circuit that implements the logical method flow.
[0088] The controller can be implemented in any suitable way, for example, the controller can take the form of a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code, the controller can equally well be implemented to perform the same functions using logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, etc. by means of logic programming of the method steps. The controller can thus be considered a hardware component, and the means included therein for performing the various functions can be considered structures within the hardware component. Alternatively, the means for performing the various functions can even be considered both software modules implementing the method and structures within the hardware component.
[0089] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
[0090] For the sake of description, the above apparatuses are described in functional division and are described respectively as various units. Of course, the functions of the units can be implemented in the same or multiple software and / or hardware in the implementation of the specification.
[0091] Those skilled in the art will understand that the embodiments of the specification can be provided as a method, a system or a computer program product. Therefore, the embodiments of the specification can take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the embodiments of the specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0092] 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, generate instructions 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.
[0093] 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.
[0094] 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.
[0095] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0096] 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.
[0097] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.
[0098] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not only include those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.
[0099] The specification can be described in the general context of computer-executable instructions, such as program modules, executed by computers. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The specification can also be practiced in a distributed computing environment, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.
[0100] Each embodiment in the specification is described in a progressive manner, and the same or similar parts between each embodiment can be referred to each other. Each embodiment focuses on the difference from other embodiments. In particular, for device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.
[0101] The above-described embodiments of the application have special structure and can achieve the desired results. Other embodiments can have different structures and achieve the same results. The purpose of the above-described embodiments is to illustrate the principles of the application and not to limit the scope of the application. The scope of the application is defined by the claims and their equivalents. Other embodiments are within the scope of the claims.
[0102] The above description is merely illustrative of the embodiments of the present application and is not intended to limit the scope of the present application. Various modifications can be made by those skilled in the art based upon the teachings disclosed herein. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of the present application shall fall within the scope of the claims of the present application.
Claims
1. A method for applet authorization processing, comprising: directly obtaining specified information of a current user in a corresponding applet according to authorization data, the specified information including information related to user privacy, for the current user to conduct a service of the corresponding applet; detecting a service timing node of the specified information of the current user in the corresponding applet; generating a user information risk link according to a time sequence relationship of each service timing node; in response to a request of the current user, displaying the information risk link to the current user.
2. The method of claim 1, wherein the directly obtaining specified information of a current user comprises: directly obtaining specified information of a current user without requesting authorization from the current user in the corresponding applet; before the directly obtaining specified information of a current user in a corresponding applet according to authorization data, the method further comprises: entering a centralized scene page of a specified application, the centralized scene page having multiple applets accessed by the specified application respectively as an entry; in the centralized scene page, initiating a unified authorization request corresponding to the multiple applets to the current user; if the current user agrees to conduct a pre-authorization in response to the unified authorization request, triggering corresponding authorization data generation; after the pre-authorization, if the current user enters the corresponding applet from the entry in the centralized scene page.
3. The method of claim 2, after the pre-authorization, the method further comprises: before the current user enters the corresponding applet from the entry in the centralized scene page, the corresponding applet is not allowed to directly obtain specified information of the current user.
4. The method of claim 2, wherein the initiating a unified authorization request corresponding to the multiple applets to the current user in the centralized scene page comprises: in the centralized scene page, a pop-up window is popped up to the current user, and the unified authorization request corresponding to the multiple applets is initiated through the pop-up window, so that the current user conducts authorization by interacting with the pop-up window; the directly obtaining specified information of the current user in the corresponding applet according to the authorization data comprises: in the corresponding applet, the information of the current user is directly obtained according to the authorization data without a pop-up window request for authorization to obtain specified information of the current user in the corresponding applet.
5. The method of claim 2, wherein the entering the corresponding applet from the entry in the centralized scene page comprises: when entering the corresponding applet from the entry in the centralized scene page, a centralized scene identifier corresponding to the centralized scene page is sent to a server, so that the server checks whether the received corresponding centralized scene identifier matches the generated authorization data, and determines whether to allow the corresponding applet to directly obtain the information of the user according to the matching result. 6.The method of claim 5, wherein the corresponding authorization data comprises a correspondence between a user identifier of the current user, a centralized scene identifier corresponding to the centralized scene page, and authorized state information. The obtaining, in the corresponding applet, of the specified information of the current user according to the authorization data comprises: When entering the corresponding applet from the portal in the centralized scene page, initiating an authorization request through the corresponding applet without a corresponding pop-up window; In response to the authorization request, checking, at the local or the server, whether the user corresponding to the authorization request has been authorized and whether the authorization range of the requested authorization is reasonable according to the user identifier and the authorized state information contained in the generated authorization data. If so, sending the information of the user to the corresponding applet. 7.The method of claim 2, after the pre-authorization, the method further comprises: showing the current user with authorization setting options corresponding to the plurality of applets; If it is received that the current user sets to cancel the authorization for any applet of the plurality of applets by operating the authorization setting option, determining that the pre-authorization is invalid for the any applet, so as to not allow the any applet to directly obtain the specified information of the current user according to the authorization data, while still allowing other applets of the plurality of applets that have not been canceled to directly obtain the specified information of the current user according to the authorization data. 8.The method of claim 2, wherein the unified authorization request carries an intended use of the specified information of the current user. The generating of a user information risk link according to the time sequence relationship of each business opportunity node comprises: matching and analyzing each business opportunity node with the intended use to obtain a use deviation result; generating a user information risk link according to the use deviation result and the time sequence relationship of each business opportunity node. 9.The method of claim 2, after the information risk link is shown to the current user, the method further comprises: receiving a risk blocking point indicated by the current user in the information risk link; blocking the path in the information risk link after the risk blocking point, and rolling back the business involved in the information risk link to the risk blocking point or before the risk blocking point in the corresponding applet. 10.The method of claim 2, before the directly obtaining, in the corresponding applet, of the specified information of the current user according to the authorization data, the method further comprises: generating, by the specified application, a corresponding pseudo user for the current user and generating pseudo feature information of the pseudo user according to the business characteristics of the corresponding applet and the specified original information of the current user; The directly obtaining, in the corresponding applet, of the specified information of the current user according to the authorization data comprises: In the corresponding applet, according to the authorization data, the camouflage feature information of the camouflage user is directly obtained, which is used for the current user to perform the business of the corresponding applet.
11. An applet authorization processing apparatus, comprising: An applet shortcut processing module, in the corresponding applet, according to the authorization data, directly obtaining the specified information of the current user, which is used for the current user to perform the business of the corresponding applet, and the specified information includes information related to user privacy; Detecting the business time node of the specified information of the current user in the corresponding applet; According to the time sequence relationship of each business time node, a user information risk link is generated; In response to the request of the current user, the information risk link is displayed to the current user.
12. The apparatus of claim 11, wherein the applet shortcut processing module directly obtains the specified information of the current user without requesting authorization from the current user in the corresponding applet; Before the applet shortcut processing module directly obtains the specified information of the current user according to the authorization data in the corresponding applet, it further comprises: A centralized scenario entering module, which enters the centralized scenario page of a specified application, and the centralized scenario page has entrances of multiple applets accessed by the specified application respectively; A unified authorization request module, which initiates a unified authorization request corresponding to the multiple applets to the current user in the centralized scenario page; An authorization data triggering module, if the current user agrees to perform pre-authorization in response to the unified authorization request, the corresponding authorization data is triggered to generate; The applet shortcut processing module, after the pre-authorization, if the current user enters the corresponding applet from the entrance in the centralized scenario page.
13. The apparatus of claim 12, wherein the authorization data triggering module, after the pre-authorization, does not allow the corresponding applet to directly obtain the specified information of the current user before the current user enters the corresponding applet from the entrance in the centralized scenario page.
14. The apparatus of claim 12, wherein the unified authorization request module, in the centralized scenario page, pops up a window to the current user, initiates a unified authorization request corresponding to the multiple applets through the popped window, so that the current user performs authorization by interacting with the popped window; The applet shortcut processing module, in the corresponding applet, according to the authorization data, directly obtains the information of the user without popping up a window to the current user in the corresponding applet to request authorization to obtain the specified information of the current user. 15.The apparatus of claim 12, wherein the applet shortcut processing module is configured to, when entering a corresponding applet from the portal in the centralized scenario page, send a centralized scenario identifier corresponding to the centralized scenario page to a server, so that the server checks whether the received corresponding centralized scenario identifier matches generated authorization data, and determines whether to allow the corresponding applet to directly obtain the information of the user according to a matching result. 16.The apparatus of claim 15, wherein the corresponding authorization data comprises a corresponding relationship among a user identifier of the current user, a centralized scenario identifier corresponding to the centralized scenario page, and authorized state information. The applet shortcut processing module is configured to, when entering a corresponding applet from the portal in the centralized scenario page, initiate an authorization request through the corresponding applet without a corresponding pop-up window. In response to the authorization request, the server or the local side checks whether the user corresponding to the authorization request has been authorized and whether the authorization range of the requested authorization is reasonable according to the user identifier and the authorized state information contained in the generated authorization data. If so, the information of the user is sent to the corresponding applet. 17.The apparatus of claim 12, wherein the authorization data triggering module is configured to, after the pre-authorization, display authorization setting options corresponding to the plurality of applets to the current user. If it is received that the current user sets to cancel the authorization for any applet in the plurality of applets by operating the authorization setting options, it is determined that the pre-authorization is invalid for the any applet, so that the any applet is not allowed to directly obtain specified information of the current user according to the authorization data, and other applets in the plurality of applets that have not been canceled are still allowed to directly obtain the specified information of the current user according to the authorization data. 18.The apparatus of claim 12, wherein the unified authorization request carries an intended use of the specified information of the current user. The applet shortcut processing module is configured to match and analyze each of the business time nodes and the intended use to obtain a use deviation result. According to the use deviation result and a time sequence relationship of each of the business time nodes, a user information risk link is generated. 19.The apparatus of claim 12, wherein the applet shortcut processing module is configured to, after displaying the information risk link to the current user, receive a risk blocking point indicated by the current user in the information risk link. The path after the risk blocking point in the information risk link is blocked, and the business involved in the information risk link is rolled back to the risk blocking point or before the risk blocking point in the corresponding applet.
20. The apparatus of claim 12, wherein the applet shortcut processing module, before directly obtaining the specified information of the current user in the corresponding applet according to the authorization data, generates a corresponding pseudo user for the current user and generates pseudo characteristic information of the pseudo user according to the business characteristics of the corresponding applet and the specified original information of the current user through the specified application. The directly obtaining the specified information of the current user in the corresponding applet according to the authorization data specifically includes: directly obtaining the pseudo characteristic information of the pseudo user in the corresponding applet according to the authorization data, for the current user to perform the business of the corresponding applet.
21. An applet authorization processing device, comprising: at least one processor; and, a memory in communication connection with the at least one processor; wherein the memory stores instructions executable 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: directly obtaining the specified information of the current user in the corresponding applet according to the authorization data, for the current user to perform the business of the corresponding applet, the specified information including information related to user privacy; detecting the business timing nodes of the specified information related to the current user in the corresponding applet; generating a user information risk link according to the time sequence relationship of each business timing node; in response to the request of the current user, displaying the information risk link to the current user.