Permission calling method and device, computer equipment and storage medium
By generating a unified sandbox environment in the portal APP and generating module confirmation and permission confirmation pop-up windows, the compliance and development efficiency problems of portal APP when calling permissions between multifunction modules is solved, and the flexibility of user experience and application is improved.
Patent Information
- Application Number
- CN202411749022.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-28
- Publication Date
- 2025-03-25
AI Technical Summary
The existing portal APP has problems such as compliance, development efficiency and user experience in permission management. Especially when permission calls between multifunction modules, it is impossible to ensure that each module clearly informs the user of the required permissions, resulting in compliance issues. In addition, each development team needs to manage the pop-up logic by itself, which increases the risk of inconsistency in development volume and logic.
By obtaining the module information of multiple functional modules to be deployed in the user terminal, a unified sandbox environment is generated, and a module confirmation pop-up window and permission confirmation pop-up window are generated based on the module identification of each functional module in the sandbox environment, ensuring that the user clearly knows the permissions required by each functional module, and performs user confirmation every time the permission call.
It improves the transparency and compliance of permission calls, reduces the development amount of permission calling logic managed by the development team of each functional module, ensures the consistency of permission calling logic, and enhances the flexibility of user experience and application.
Smart Images
Figure CN119691796A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of research and development frameworks, and in particular to a permission invocation method, apparatus, computer equipment, and storage medium. Background Art
[0002] With the gradual improvement of software application development laws, the current software development process pays more and more attention to user privacy and user permissions. Application software providers are not allowed to collect any data involving user privacy without permission. If users must provide some special capabilities to use a certain function, users must be informed of the functions they need to use in advance. For lightweight apps that generally have clear divisions, directly using the system's permission pop-up box is enough to deal with it, but it is not enough for portal apps.
[0003] Portal apps usually integrate a lot of independent functional modules, and each functional module is most likely developed by a different team. Existing portal apps either use the pop-up boxes and pop-up box permission judgment provided by the system for all internal functional modules, or each functional module manages its own pop-up box logic. For the first type, it is often impossible to prompt users in different modules for the same permissions. For example, if the recording permission is applied for in functional module A and used for the first time in functional module B, there will be non-compliance issues, that is, the user is directly using the recording function without being clearly informed that the user needs to use the recording. For the second type, the development teams of different modules will need to manage their own logic, resulting in an increase in development volume and inconsistent logic.
[0004] Therefore, a permission calling method is urgently needed to solve at least one of the above problems. Summary of the invention
[0005] The present application provides a permission calling method, apparatus, computer equipment and readable storage medium, aiming to solve the existing portal APP, where either all internal functional modules uniformly use the pop-up box and pop-up box permission judgment provided by the system, or each functional module manages its own pop-up box logic. For the first type, it often results in the same permission in different modules and it is impossible to prompt the user in each module. For example, the recording permission has been applied for in functional module A. When it is used for the first time in functional module B, there will be a non-compliance problem, that is, the user is not clearly informed that the recording function is used directly. For the second type, the development teams of different modules will need to manage their own logic, resulting in an increase in the amount of development and inconsistent logic.
[0006] In a first aspect, the present application provides a permission calling method, comprising:
[0007] Acquire module information of multiple functional modules to be deployed in the user terminal; the module information at least includes a module identifier corresponding to the functional module, an operating system type, a protocol type, and a permission type to be called;
[0008] Generate sandbox environments based on multiple operating system types, protocol types, and permission types;
[0009] When any function module initiates a first call request corresponding to any permission type, a module confirmation pop-up window is generated in the sandbox environment according to the module identifier corresponding to each function module and sent to the user terminal;
[0010] After receiving confirmation information corresponding to the module confirmation pop-up window returned by the user terminal, generating a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal;
[0011] After receiving the confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, respond to the first call request so that the function module corresponding to the first call request completes the permission call to the user terminal.
[0012] In some embodiments, a sandbox environment is generated based on multiple operating system types, protocol types, and permission types, including: generating a blank environment; generating mapping information corresponding to each permission type based on module identification, operating system type, and protocol type; and adding each mapping information to the blank environment to generate a sandbox environment.
[0013] Exemplarily, the method also includes: if a target module identifier and a target permission identifier to be called are received from an external device, determining the target module from multiple functional modules based on the target module identifier and multiple module identifiers; generating a second calling request corresponding to the external device in a sandbox environment based on the mapping information corresponding to the target module and the target permission identifier and sending it to the user terminal, so that the external device can complete the call to the target module after confirmation by the user terminal.
[0014] In some embodiments, the permission types include at least application permissions and hardware permissions; after responding to the call request, it also includes: after receiving a second call request, obtaining the module identifier and permission type corresponding to the second call request; determining whether the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request; if the module identifier corresponding to the module confirmation pop-up window does not include the module identifier corresponding to the second call request, regenerating the module confirmation pop-up window to the user terminal according to the module identifier corresponding to the second call request.
[0015] Exemplarily, if the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request, the method also includes: determining whether the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request; if the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request, responding to the second call request.
[0016] In some embodiments, the permission confirmation pop-up window includes multiple sub-permissions corresponding to the permission type; before responding to the first call request, it also includes: if it is determined according to the confirmation information corresponding to the permission confirmation pop-up window that the user terminal has authorized some sub-permissions among multiple sub-permissions, the response to the first call request is completed according to the authorized sub-permissions, so that the function module corresponding to the first call request completes the permission call to the user terminal according to the authorized sub-permissions.
[0017] In some embodiments, before responding to the first call request, the method also includes: obtaining terminal information corresponding to the user terminal; generating permission identification information based on the terminal information and the permission type corresponding to the first call request; if it is confirmed in the user terminal that the permission module corresponding to the permission identification information is closed, generating a permission enabling prompt based on the permission identification information and the confirmation information corresponding to the permission confirmation pop-up window; and sending the permission enabling prompt to the user terminal to prompt that the permission module needs to be enabled in order to complete the response to the first call request.
[0018] In a second aspect, the present application provides a permission calling device, including:
[0019] An information acquisition unit, used to acquire module information of multiple functional modules to be deployed in the user terminal; the module information at least includes a module identifier corresponding to the functional module, an operating system type, a protocol type, and a permission type to be called;
[0020] An environment generation unit, used to generate a sandbox environment according to multiple operating system types, protocol types, and permission types;
[0021] A pop-up window generating unit, configured to generate a module confirmation pop-up window to a user terminal according to a module identifier corresponding to each functional module in a sandbox environment when any functional module initiates a first call request corresponding to any permission type;
[0022] The permission confirmation unit is used to generate a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal after receiving the confirmation information corresponding to the module confirmation pop-up window returned by the user terminal;
[0023] The call completion unit is used to respond to the first call request after receiving the confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, so that the function module corresponding to the first call request completes the permission call to the user terminal.
[0024] In a third aspect, the present application further provides a computer device, including:
[0025] Memory and processor;
[0026] The memory is used to store computer programs;
[0027] The processor is used to execute the computer program and implement the steps of the permission calling method described in the first aspect when executing the computer program.
[0028] In a fourth aspect, the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor implements the steps of the permission calling method described in the first aspect above.
[0029] The embodiment of the present application provides a permission calling method, device, computer equipment and readable storage medium. The method first obtains the module information of multiple function modules to be deployed in the user terminal. The module information includes at least: the module identification corresponding to the function module, the operating system type, the protocol type and the permission type to be called. Then, a unified sandbox environment is generated according to the multiple operating system types, protocol types and permission types obtained. The sandbox environment is used to isolate and manage the permission calling logic of each function module to ensure that each module follows a unified standard and process when calling permissions. Then, when any function module initiates a permission calling request (first call request), a module confirmation pop-up window is generated in the sandbox environment according to the module identification of the function module, and it is sent to the user terminal. The module confirmation pop-up window is used to inform the user of the specific information of the function module currently requesting permission calling. Further, after the user terminal returns the confirmation information of the module confirmation pop-up window, a permission confirmation pop-up window is generated and sent to the user terminal. The permission confirmation pop-up window is used to clearly inform the user of the specific permissions that need to be called and request the user's consent. Finally, after the user terminal returns the confirmation information of the permission confirmation pop-up window, the first call request is responded to so that the function module can complete the permission call to the user terminal.
[0030] The method provided thereby has at least the following beneficial effects:
[0031] 1. Improved compliance: By generating a module confirmation pop-up window and a permission confirmation pop-up window each time a permission is called, it ensures that users know clearly what permissions the module requires each time they use a new functional module, thereby improving the transparency and compliance of permission calls and avoiding the problem of directly using permissions without clearly informing users.
[0032] 2. Improved development efficiency: Generate a unified sandbox environment, reducing the amount of development work that each functional module development team needs to do to manage their own permission call logic. The sandbox environment provides a standardized permission call process, allowing the development team to focus more on function development rather than permission management.
[0033] 3. User experience optimization: Users can clearly understand the permission requirements of each functional module, and will receive clear prompts every time they call it, which helps to enhance user trust and satisfaction. At the same time, the design of pop-up windows can be more consistent, reducing the inconsistency of users when using different modules.
[0034] 4. Logical consistency: By unifying the management permission call logic, the consistency of each functional module when calling permissions is ensured, avoiding inconsistencies caused by the respective management logic of different module development teams.
[0035] 5. Enhanced flexibility: This method supports multiple operating system types and protocol types, allowing portal apps to efficiently and consistently manage permission calls in different terminals and environments, enhancing the flexibility and adaptability of the application.
[0036] In summary, this permission calling method effectively solves the compliance, development efficiency and user experience problems of existing portal apps in permission management by generating a unified sandbox environment and standardized permission calling process, and has high practical value and promotion potential.
[0037] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0039] Figure 1 This is a flowchart showing the steps of a permission calling method provided by an embodiment of the present application;
[0040] Figure 2 This is a schematic flow chart of the steps of a method for generating a sandbox environment provided in an embodiment of the present application;
[0041] Figure 3 This is a schematic flow chart of the steps of a first call request response method provided by an embodiment of the present application;
[0042] Figure 4It is a structural diagram of a permission calling device provided in an embodiment of the present application;
[0043] Figure 5 It is a schematic block diagram of the structure of a computer device provided in one embodiment of the present application.
[0044] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. DETAILED DESCRIPTION
[0045] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0046] The flowcharts shown in the accompanying drawings are only examples and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may also be decomposed, combined or partially merged, so the actual execution order may change according to actual conditions.
[0047] It should be understood that, in order to facilitate the clear description of the technical solutions of the embodiments of the present invention, in the embodiments of the present invention, the words "first", "second", etc. are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art can understand that the words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not necessarily limit the difference.
[0048] It should be understood that the terms used in this application specification are only for the purpose of describing specific embodiments and are not intended to limit the application. As used in this application specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.
[0049] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.
[0050] In conjunction with the accompanying drawings, some embodiments of the present application are described in detail below. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.
[0051] With the gradual improvement of software application development laws, the current software development process pays more and more attention to user privacy and user permissions. Application software providers are not allowed to collect any data involving user privacy without permission. If users must provide some special capabilities to use a certain function, users must be informed of the functions they need to use in advance. For lightweight apps that generally have clear divisions, directly using the system's permission pop-up box is enough to deal with it, but it is not enough for portal apps.
[0052] Portal apps usually integrate a lot of independent functional modules, and each functional module is most likely developed by a different team. Existing portal apps either use the pop-up boxes and pop-up box permission judgment provided by the system for all internal functional modules, or each functional module manages its own pop-up box logic. For the first type, it is often impossible to prompt users in different modules for the same permissions. For example, if the recording permission is applied for in functional module A and used for the first time in functional module B, there will be non-compliance issues, that is, the user is directly using the recording function without being clearly informed that the user needs to use the recording. For the second type, the development teams of different modules will need to manage their own logic, resulting in an increase in development volume and inconsistent logic.
[0053] Therefore, a permission calling method is urgently needed to solve at least one of the above problems.
[0054] To solve the above problems, please refer to Figure 1 , Figure 1 This is a schematic flow chart of a permission calling method provided by an embodiment of the present application. The permission calling method can be implemented by a computer device, which can be deployed on a single server or a server cluster. It can also be deployed on a handheld terminal, a laptop computer, a wearable device or a robot, etc.
[0055] It should be noted that the acquisition of any information mentioned in the provided method is in compliance with relevant regulations and is carried out with the user's consent, and will not infringe on the user's privacy or violate relevant laws and regulations.
[0056] At the same time, the method provided by this application can be applied to scenarios such as the financial field where permissions are frequently called. In other fields that require a large number of permissions calls, it can also improve the flexibility of permission calls while ensuring compliance. Therefore, the financial field is only a specific example of this application, and the specific application scope of the method provided by this application is not limited.
[0057] To solve the above problems, please refer to Figure 1 Specifically, Figure 1 As shown, the provided permission calling method includes steps S101 to S105. The details are as follows:
[0058] Step S101. Obtain module information of multiple functional modules to be deployed in the user terminal; the module information at least includes a module identifier corresponding to the functional module, an operating system type, a protocol type, and a permission type to be called.
[0059] Specifically, it first involves collecting the basic information of all the function modules to be deployed in the portal APP installed on the user terminal. The module information should at least include the unique identifier of each function module (module identifier), the type of target operating system (such as Android, iOS), the communication protocol type (such as HTTP, HTTPS), and the type of permissions that the module intends to call (such as recording permissions, camera permissions, etc.).
[0060] Suppose there is a comprehensive financial APP, which contains multiple functional modules such as course playback, online discussion, content submission, etc. The method needs to collect information from these modules. For example, the course playback module hopes to call network access rights (to load online videos) and recording rights (to achieve video caching and downloading), while the online discussion module may need to access the user's microphone and camera permissions.
[0061] By centrally collecting this information, we can provide a basis for permission management and calling in subsequent steps, ensuring that each functional module follows a unified logic when applying for permissions. It also helps developers better understand and plan the overall permission requirements of the application.
[0062] Step S102: Generate a sandbox environment according to multiple operating system types, protocol types, and permission types.
[0063] Specifically, the sandbox environment refers to a test environment isolated from the real environment, which is used to simulate various possible application scenarios to ensure that the application's behavior is safe and controllable. In this step, based on the collected operating system type, protocol type, and permission type, an independent and secure operating environment is created for each functional module, enabling them to request and verify permissions under the conditions of simulating the real operating system and network protocol.
[0064] Taking the aforementioned financial app as an example, according to the requirements of the course playback module and the online discussion module, the system will create sandbox environments for these two modules, simulate Android and iOS operating systems, and use HTTP or HTTPS protocols for network communication. In these environments, the permission call process can be safely tested to ensure that it meets expectations.
[0065] The use of a sandbox environment effectively isolates the interactions between functional modules, avoiding possible conflicts during permission calls. It also provides a safe experimental field for the development and testing phases, reducing unnecessary access to users' actual data and device resources.
[0066] Step S103: when any function module initiates a first call request corresponding to any permission type, a module confirmation pop-up window is generated in the sandbox environment according to the module identifier corresponding to each function module and sent to the user terminal.
[0067] Specifically, when a function module attempts to call a specific permission for the first time, the application will check whether the module has obtained the corresponding permission confirmation. If not, a confirmation pop-up window will be automatically triggered in the sandbox environment. The pop-up window should contain the basic information of the function module (such as name, icon, etc.) and the list of permissions it requested to clearly inform the user of the upcoming operation.
[0068] For example, when the course playback module tries to use the recording permission for the first time, if the module has never requested this permission before, the system will generate a confirmation pop-up window in the sandbox environment, prompting the user: "The course playback function requires access to the recording permission to implement video caching and downloading functions. Do you allow it?".
[0069] The purpose of this step is to enhance the user experience, ensure that users have a clear understanding of the application's behavior, and avoid unnecessary abuse of permissions. At the same time, the way to generate pop-up windows in a sandbox environment can also help developers foresee the differences in pop-up window behaviors under different operating systems, so as to prepare for adaptation in advance.
[0070] Step S104: after receiving the confirmation information corresponding to the module confirmation pop-up window returned by the user terminal, generating a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal.
[0071] Specifically, once the user confirms the permission request for a certain function module, the application needs to further request the user to confirm the specific use of the permission. In this step, the application will generate a more specific permission confirmation pop-up window based on the user's selection, allowing the user to clearly agree or refuse.
[0072] Continuing with the previous example, when the user clicks to allow the module to use permissions, he or she will immediately receive a more specific permission confirmation pop-up window, such as: "You have chosen to allow the course playback function to access the recording permissions. Confirm again, do you allow it to read the recording files on your device?"
[0073] Through this step, the application can ensure that users have a clear understanding of the needs of each specific permission and can make an informed choice. This design not only protects the privacy and security of users, but also complies with the current laws and regulations on data privacy protection in many countries.
[0074] Step S105. After receiving the confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, respond to the first call request so that the function module corresponding to the first call request completes the permission call to the user terminal.
[0075] Specifically, based on the user's final confirmation, the application will execute or refuse to execute the permission call request. If the user agrees to the authorization, the application will activate the permission for the corresponding functional module, allowing it to access the required resources under controlled conditions; if the user refuses, the application will record the user's choice and make corresponding prompts on the front end to ensure that the user understands the result of the operation.
[0076] If the user agrees to the course playback function's request to read the recording file, then when the course playback module needs to actually use the recording file, it will be able to call this permission smoothly. However, if the user refuses, the application should handle this situation reasonably, for example, limiting certain functions of the course playback or prompting the user about the impact of this decision on the function.
[0077] This step ensures that the application's permissions are completely based on the user's authorization, improving the application's transparency and user control. At the same time, properly handling user rejections can prevent abnormal behavior in the application and improve user satisfaction.
[0078] In summary, this permission calling method not only improves the security and user experience of terminal applications, but also simplifies the development process and reduces development costs by centrally managing permission requests, providing clear user prompts, and ensuring the security and legality of permission calls.
[0079] In some embodiments, Figure 2 As shown, a sandbox environment is generated according to multiple operating system types, protocol types, and permission types, including steps S102a to S102c.
[0080] Step S102a. Generate a blank environment;
[0081] By generating a basic blank environment without any specific configuration, this blank environment is the basis of the sandbox environment and is used to add specific mapping information of each functional module later.
[0082] Suppose we need to generate a sandbox environment for a financial app. First, create a blank virtual environment. This blank environment can be a virtual machine, container, or other isolated operating environment, but it does not contain any specific operating system, protocol, or permission configuration. Generating a blank environment can simplify the initialization steps of the sandbox environment and avoid repeatedly setting basic configurations in each environment. At the same time, it provides a unified and clean basic environment for all functional modules, ensuring that each module is tested and permissioned at the same starting point.
[0083] Step S102b generates mapping information corresponding to each permission type according to the module identification, operating system type and protocol type;
[0084] According to the unique identifier of each functional module, the type of the target operating system and the type of communication protocol, specific permission mapping information is generated. These mapping information define how to call and verify permissions in a specific module of a specific operating system.
[0085] For example, for the course playback module, the mapping information is as follows: module identifier: coursePlayer, operating system type: Android, protocol type: HTTPS, permission type: network access permission, recording permission; for the online discussion module, the mapping information is as follows: module identifier: onlineDiscussion, operating system type: iOS, protocol type: HTTP, permission type: microphone permission, camera permission.
[0086] By generating mapping information, we can ensure that the permission call requests of each functional module are accurately configured and managed under a specific operating system and protocol. The permission mapping information of each module is generated independently to avoid permission call conflicts between different modules. By pre-generating mapping information, the development team can focus on the development of core functions without having to repeatedly process the logic of permission requests.
[0087] Step S102c: Add each mapping information to the blank environment to generate a sandbox environment.
[0088] The permission mapping information generated in step S102b is added to the blank environment, thereby constructing a complete sandbox environment that can simulate the behavior of each functional module requesting and verifying permissions under a specific protocol of a specific operating system.
[0089] For example, the mapping information of the course playback module and the online discussion module are added to the blank environment generated previously to form two independent sandbox environments.
[0090] By adding mapping information to a blank environment, an environment that highly simulates the real operating system can be customized for each functional module to improve the accuracy of the test. The use of a sandbox environment ensures the security of permission call testing and avoids high-risk operations in a real environment. Developers can efficiently test and verify permission call logic in a sandbox environment, reducing the time cost of repeated deployment and testing on real devices.
[0091] The above steps describe in detail how to build a sandbox environment that highly simulates the real environment through three steps: generating a blank environment, generating mapping information, and adding the mapping information to the blank environment. This method not only ensures the accuracy and security of permission calls, but also simplifies the development and testing process, improves user experience and application compliance. Specifically, the generation of a blank environment simplifies the initialization steps, the generation of permission mapping information ensures that the permission requests of each module are accurately configured, and adding the mapping information to the blank environment realizes the customization and security of the environment.
[0092] Exemplarily, the method also includes: if a target module identifier and a target permission identifier to be called are received from an external device, determining the target module from multiple functional modules based on the target module identifier and multiple module identifiers; generating a second calling request corresponding to the external device in a sandbox environment based on the mapping information corresponding to the target module and the target permission identifier and sending it to the user terminal, so that the external device can complete the call to the target module after confirmation by the user terminal.
[0093] By receiving the target module identifier and target permission identifier to be called sent by the external device. According to the received target module identifier and the module identifiers of multiple functional modules, the target module is determined. In the sandbox environment, a second call request corresponding to the external device is generated according to the mapping information corresponding to the target module and the target permission identifier, and sent to the user terminal. After the user terminal receives the second call request, the user confirms or rejects it. According to the user's confirmation information, the call request of the external device is responded to, so that the external device can complete the permission call to the target module.
[0094] For example, there is a financial APP that contains a course playback module and an online discussion module. Now, an external device (for example, a smart speaker) wants to call the recording permission of the course playback module. The following is the specific processing process: The smart speaker sends a request, including a target module identifier (coursePlayer) and a target permission identifier (recording i ng). After receiving the request, the computer device determines that the target module is a course playback module among multiple known functional modules according to the target module identifier coursePlayer. In the sandbox environment, a second call request is generated according to the mapping information of the course playback module and the target permission identifier recording i ng. The generated call request may contain information such as permission description and call method, and is sent to the user terminal through a secure channel. After the user terminal receives the second call request, a confirmation pop-up window is displayed, for example: "The smart speaker wants to call the recording permission of the course playback function. Do you want to allow it?". The user can choose "Allow" or "Reject". If the user chooses "Allow", the application will record the user's authorization information and activate the corresponding permission in the sandbox environment. The smart speaker will receive a confirmation response indicating that it can now call the recording permission of the course playback module. If the user selects “Decline,” the app records the selection and sends a rejection response to the smart speaker.
[0095] By processing the permission call request of external devices in a sandbox environment, it is ensured that external devices will not directly access the system permissions of the user terminal, thereby improving security. Users need to confirm in the module confirmation pop-up window and the permission confirmation pop-up window respectively, further ensuring the user's right to know and control. Users can clearly understand the specific modules and permissions that external devices want to call, avoiding the abuse of permissions. At the same time, through pop-up prompts, users can easily manage permissions, enhancing the interactivity and friendliness of the application.
[0096] The permission call logic of external devices is also processed in a sandbox environment, reducing the complex interactions between various functional modules and external devices. All permission call requests follow the same processing flow, improving the maintainability and scalability of the code.
[0097] This example ensures the security and compliance of external device permission calls by processing permission call requests from external devices in a sandbox environment. This approach not only enhances the security and user experience of the application, but also simplifies the development process and improves the flexibility of the system. Specifically, the steps of receiving external requests, determining the target module, generating call requests, and user confirmation allow external devices to safely call the permissions of the target module with explicit user authorization, avoiding permission abuse and security risks.
[0098] In some embodiments, the permission types include at least application permissions and hardware permissions; after responding to the call request, it also includes: after receiving a second call request, obtaining the module identifier and permission type corresponding to the second call request; determining whether the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request; if the module identifier corresponding to the module confirmation pop-up window does not include the module identifier corresponding to the second call request, regenerating the module confirmation pop-up window to the user terminal according to the module identifier corresponding to the second call request.
[0099] By receiving the second call request sent by the authorized module or the remaining functional modules, the module identifier and permission type are extracted from the second call request. Check whether the module identifier corresponding to the module confirmation pop-up window contains the module identifier corresponding to the second call request. If the module identifier corresponding to the module confirmation pop-up window does not contain the module identifier corresponding to the second call request, the module confirmation pop-up window is regenerated according to the module identifier corresponding to the second call request and sent to the user terminal.
[0100] By processing the second call request of the functional module in a sandbox environment, and adding a mechanism to verify the module identification and permission type and regenerate the module confirmation pop-up window, it further ensures that users can make clear confirmation every time they request a permission call. This method not only enhances the security and user experience of the application, but also simplifies the development process and improves the flexibility of the system. Specifically, by receiving the second call request, obtaining the module identification and permission type, determining the module identification of the module confirmation pop-up window and regenerating the module confirmation pop-up window, the application can better manage and respond to permission requests for any functional module, ensuring that each call is compliant and under user control.
[0101] Exemplarily, if the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request, the method also includes: determining whether the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request; if the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request, responding to the second call request.
[0102] By processing the second call request of the function module in the sandbox environment and adding verification logic for the module confirmation pop-up window and the permission confirmation pop-up window, it ensures that the module and permission calls that the user has confirmed can be responded to quickly, avoiding unnecessary repeated confirmations. This method not only reduces user interference and improves operational efficiency, but also further enhances the security and user experience of the application.
[0103] In some embodiments, the permission confirmation pop-up window includes multiple sub-permissions corresponding to the permission type; before responding to the first call request, it also includes: if it is determined according to the confirmation information corresponding to the permission confirmation pop-up window that the user terminal has authorized some sub-permissions among multiple sub-permissions, the response to the first call request is completed according to the authorized sub-permissions, so that the function module corresponding to the first call request completes the permission call to the user terminal according to the authorized sub-permissions.
[0104] When generating a permission confirmation pop-up window, the pop-up window includes multiple sub-permissions corresponding to the permission type. For example, a permission type recording may include sub-permissions microphone (microphone recording) and speaker (speaker recording). The user terminal displays a permission confirmation pop-up window, and the user can choose to authorize all sub-permissions, some sub-permissions, or deny all sub-permissions. According to the user's confirmation information, obtain which sub-permissions the user has authorized. According to the confirmation information corresponding to the permission confirmation pop-up window, determine whether the user has authorized some sub-permissions among multiple sub-permissions. If the user has authorized some sub-permissions, complete the response to the first call request according to the sub-permissions authorized by the user. For example, if the user only authorizes the microphone sub-permission, the application will record this selection and only activate the microphone sub-permission in the sandbox environment.
[0105] The function module corresponding to the first call request will complete the permission call to the user terminal according to the sub-permission authorized by the user. Unauthorized sub-permissions will not be called to ensure the compliance and security of permission use.
[0106] Suppose there is a financial app that contains a course playback module and an online discussion module. When a user installs and activates the app for the first time, the app will generate a permission confirmation pop-up window, requesting the user to authorize recording permission. The recording permission includes two sub-permissions: microphone (microphone recording) and speaker (speaker recording). The following is the specific processing process:
[0107] Generate permission confirmation pop-up window: The application generates a permission confirmation pop-up window with the content: "The financial APP wants to use the recording permission. Please select the authorized sub-permissions: microphone recording (microphone), speaker recording (speaker)." The user can choose to authorize all sub-permissions, some sub-permissions, or deny all sub-permissions. The user terminal displays the permission confirmation pop-up window, and the user chooses to authorize the microphone sub-permission. The user terminal sends the selected information back to the computer device of the application. The computer device corresponding to the application determines which sub-permissions the user has authorized among multiple sub-permissions based on the confirmation information corresponding to the permission confirmation pop-up window. In this example, if the user only authorized the microphone sub-permission. Complete the response to the first call request based on the sub-permissions authorized by the user. In the sandbox environment, only the microphone sub-permission is activated, and the speaker sub-permission is not activated. When performing the recording operation, the course playback module will only call the authorized microphone sub-permission. If the course playback module needs to call the speaker sub-permission, the application will need to regenerate the permission confirmation pop-up window and obtain the user's authorization.
[0108] Furthermore, by including multiple sub-permissions in the permission confirmation pop-up window, and completing the response to the first call request based on the user's choice when the user authorizes some sub-permissions, it ensures that the application uses permissions with the user's explicit authorization. This method not only enhances the user's control over the use of permissions, improves the security and transparency of the system, but also simplifies the development process and enhances flexibility.
[0109] In some embodiments, Figure 3 As shown, before responding to the first call request, the method further includes steps S105a to S105d.
[0110] Step S105a. Obtain terminal information corresponding to the user terminal;
[0111] Step S105b generates permission identification information according to the terminal information and the permission type corresponding to the first call request;
[0112] Step S105c. If the permission module corresponding to the permission identification information is confirmed to be closed in the user terminal, a permission opening prompt is generated according to the permission identification information and the confirmation information corresponding to the permission confirmation pop-up window;
[0113] Step S105d. Send a permission activation prompt to the user terminal to prompt that the permission module needs to be activated in order to complete the response to the first call request.
[0114] By obtaining terminal information from the user terminal, including the operating system type, version number, device model, etc. of the terminal. Terminal information can help applications better adapt to different terminal environments. Then generate permission identification information based on the terminal information of the user terminal and the permission type corresponding to the first call request. The permission identification information is a unique identifier used to check and process the status of the permission module in subsequent steps. Check whether the permission module corresponding to the permission identification information in the user terminal is closed. If the permission module is closed, generate a permission enable prompt to prompt the user that the permission module needs to be enabled in order to complete the response to the first call request. The permission enable prompt may include specific operating steps to guide the user on how to enable the permission module. Then send the generated permission enable prompt to the user terminal. After receiving the prompt, the user terminal can display a pop-up window or notification to guide the user's operation.
[0115] By adding a step to check the terminal information and permission module status of the user terminal before responding to the first call request, it is ensured that when the permission module is not enabled, the application can generate a permission enablement prompt and send it to the user terminal to guide the user's operation. This method not only enhances the user's control over the use of permissions, improves the security and transparency of the system, but also simplifies the development process and enhances flexibility.
[0116] The method provided in the embodiment of the present application first obtains the module information of multiple functional modules to be deployed in the user terminal. The module information includes at least: the module identification corresponding to the functional module, the operating system type, the protocol type and the permission type to be called. Then, a unified sandbox environment is generated based on the multiple operating system types, protocol types and permission types obtained. The sandbox environment is used to isolate and manage the permission call logic of each functional module to ensure that each module follows a unified standard and process when calling permissions. Then, when any functional module initiates a permission call request (first call request), a module confirmation pop-up window is generated in the sandbox environment according to the module identification of the functional module, and it is sent to the user terminal. The module confirmation pop-up window is used to inform the user of the specific information of the functional module currently requesting permission to call. Further, after the user terminal returns the confirmation information of the module confirmation pop-up window, a permission confirmation pop-up window is generated and sent to the user terminal. The permission confirmation pop-up window is used to clearly inform the user of the specific permissions that need to be called and request the user's consent. Finally, after the user terminal returns the confirmation information of the permission confirmation pop-up window, the first call request is responded to so that the functional module can complete the permission call to the user terminal.
[0117] The method provided thereby has at least the following beneficial effects:
[0118] 1. Improved compliance: By generating a module confirmation pop-up window and a permission confirmation pop-up window each time a permission is called, it ensures that users know clearly what permissions the module requires each time they use a new functional module, thereby improving the transparency and compliance of permission calls and avoiding the problem of directly using permissions without clearly informing users.
[0119] 2. Improved development efficiency: Generate a unified sandbox environment, reducing the amount of development work that each functional module development team needs to do to manage their own permission call logic. The sandbox environment provides a standardized permission call process, allowing the development team to focus more on function development rather than permission management.
[0120] 3. User experience optimization: Users can clearly understand the permission requirements of each functional module, and will receive clear prompts every time they call it, which helps to enhance user trust and satisfaction. At the same time, the design of pop-up windows can be more consistent, reducing the inconsistency of users when using different modules.
[0121] 4. Logical consistency: By unifying the management permission call logic, the consistency of each functional module when calling permissions is ensured, avoiding inconsistencies caused by the respective management logic of different module development teams.
[0122] 5. Enhanced flexibility: This method supports multiple operating system types and protocol types, allowing portal apps to efficiently and consistently manage permission calls in different terminals and environments, enhancing the flexibility and adaptability of the application.
[0123] See also Figure 4 As shown, Figure 4 1 is a schematic diagram of the structure of the permission invoking device 200 provided in an embodiment of the present application. The permission invoking device 200 is used to execute the steps of the permission invoking method shown in the above embodiments. The permission invoking device 200 can be a single server or a server cluster, or the permission invoking device 200 can be a terminal, which can be a handheld terminal, a laptop computer, a wearable device or a robot, etc.
[0124] like Figure 4 As shown, the permission calling device 200 includes:
[0125] The information acquisition unit 201 is used to acquire module information of multiple functional modules to be deployed in the user terminal; the module information at least includes a module identifier corresponding to the functional module, an operating system type, a protocol type, and a permission type to be called;
[0126] An environment generation unit 202, configured to generate a sandbox environment according to a plurality of operating system types, protocol types, and permission types;
[0127] A pop-up window generating unit 203 is used to generate a module confirmation pop-up window to a user terminal according to a module identifier corresponding to each functional module in a sandbox environment when any functional module initiates a first call request corresponding to any permission type;
[0128] The permission confirmation unit 204 is used to generate a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal after receiving the confirmation information corresponding to the module confirmation pop-up window returned by the user terminal;
[0129] The call completion unit 205 is used to respond to the first call request after receiving the confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, so that the function module corresponding to the first call request completes the permission call to the user terminal.
[0130] It should be noted that, those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the permission calling device and each module described above can refer to the corresponding process in the permission calling method embodiments described in the above embodiments, and will not be repeated here.
[0131] The above-mentioned permission calling method can be implemented in the form of a computer program, and the computer program can be Figure 4 Run on the device shown.
[0132] See also Figure 5 , Figure 5 1 is a schematic block diagram of the structure of a computer device provided in an embodiment of the present application. The computer device includes a processor, a memory and a network interface connected via a device bus, wherein the memory may include a storage medium and an internal memory.
[0133] The storage medium can store an operating device and a computer program. The computer program includes program instructions, and when the program instructions are executed, the processor can execute any permission calling method.
[0134] The processor is used to provide computing and control capabilities and support the operation of the entire computer equipment.
[0135] The internal memory provides an environment for the operation of the computer program in the non-volatile storage medium. When the computer program is executed by the processor, the processor can execute any permission calling method.
[0136] The network interface is used for network communication, such as sending assigned tasks, etc. Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the scheme of the present application, and does not constitute a limitation on the terminal to which the scheme of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.
[0137] It should be understood that the processor may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.
[0138] In one embodiment, the processor is used to run a computer program stored in the memory to implement the following steps:
[0139] Acquire module information of multiple functional modules to be deployed in the user terminal; the module information at least includes a module identifier corresponding to the functional module, an operating system type, a protocol type, and a permission type to be called;
[0140] Generate sandbox environments based on multiple operating system types, protocol types, and permission types;
[0141] When any function module initiates a first call request corresponding to any permission type, a module confirmation pop-up window is generated in the sandbox environment according to the module identifier corresponding to each function module and sent to the user terminal;
[0142] After receiving confirmation information corresponding to the module confirmation pop-up window returned by the user terminal, generating a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal;
[0143] After receiving the confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, respond to the first call request so that the function module corresponding to the first call request completes the permission call to the user terminal.
[0144] In some embodiments, a sandbox environment is generated based on multiple operating system types, protocol types, and permission types, including: generating a blank environment; generating mapping information corresponding to each permission type based on module identification, operating system type, and protocol type; and adding each mapping information to the blank environment to generate a sandbox environment.
[0145] Exemplarily, the method also includes: if a target module identifier and a target permission identifier to be called are received from an external device, determining the target module from multiple functional modules based on the target module identifier and multiple module identifiers; generating a second calling request corresponding to the external device in a sandbox environment based on the mapping information corresponding to the target module and the target permission identifier and sending it to the user terminal, so that the external device can complete the call to the target module after confirmation by the user terminal.
[0146] In some embodiments, the permission types include at least application permissions and hardware permissions; after responding to the call request, it also includes: after receiving a second call request, obtaining the module identifier and permission type corresponding to the second call request; determining whether the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request; if the module identifier corresponding to the module confirmation pop-up window does not include the module identifier corresponding to the second call request, regenerating the module confirmation pop-up window to the user terminal according to the module identifier corresponding to the second call request.
[0147] Exemplarily, if the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request, the method also includes: determining whether the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request; if the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request, responding to the second call request.
[0148] In some embodiments, the permission confirmation pop-up window includes multiple sub-permissions corresponding to the permission type; before responding to the first call request, it also includes: if it is determined according to the confirmation information corresponding to the permission confirmation pop-up window that the user terminal has authorized some sub-permissions among multiple sub-permissions, the response to the first call request is completed according to the authorized sub-permissions, so that the function module corresponding to the first call request completes the permission call to the user terminal according to the authorized sub-permissions.
[0149] In some embodiments, before responding to the first call request, the method also includes: obtaining terminal information corresponding to the user terminal; generating permission identification information based on the terminal information and the permission type corresponding to the first call request; if it is confirmed in the user terminal that the permission module corresponding to the permission identification information is closed, generating a permission enabling prompt based on the permission identification information and the confirmation information corresponding to the permission confirmation pop-up window; and sending the permission enabling prompt to the user terminal to prompt that the permission module needs to be enabled in order to complete the response to the first call request.
[0150] The present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor implements the steps of the permission calling method described in the first aspect above.
[0151] The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiment, such as a hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart memory card (SmartMedia Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc., equipped on the computer device.
[0152] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.
Claims
1. A permission calling method, characterized in that: include: Acquire module information of multiple functional modules to be deployed in a user terminal; The module information at least includes a module identifier, an operating system type, a protocol type, and a permission type to be called corresponding to the functional module; Generate a sandbox environment according to the plurality of operating system types, protocol types, and permission types; When any of the functional modules initiates a first call request corresponding to any of the permission types, a module confirmation pop-up window is generated in the sandbox environment according to the module identifier corresponding to each of the functional modules and sent to the user terminal; After receiving confirmation information corresponding to the module confirmation pop-up window returned by the user terminal, generating a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal; After receiving confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, respond to the first call request so that the function module corresponding to the first call request completes the permission call to the user terminal.
2. The method according to claim 1, characterized in that Generating a sandbox environment according to the plurality of operating system types, protocol types, and permission types includes: Generate a blank environment; Generate mapping information corresponding to each permission type according to the module identifier, operating system type and protocol type; Each mapping information is added to the blank environment to generate the sandbox environment.
3. The method according to claim 2, characterized in that The method further comprises: If a target module identifier and a target permission identifier to be called sent by an external device are received, a target module is determined from the plurality of functional modules according to the target module identifier and the plurality of module identifiers; In the sandbox environment, a second calling request corresponding to the external device is generated according to the mapping information corresponding to the target module and the target permission identifier and sent to the user terminal, so that the external device can complete the calling of the target module after confirmation by the user terminal.
4. The method according to claim 1, characterized in that: The permission types include at least application permissions and hardware permissions; After responding to the call request, the method further includes: After receiving the second call request, obtaining a module identifier and a permission type corresponding to the second call request; Determine whether the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request; If the module identifier corresponding to the module confirmation pop-up window does not include the module identifier corresponding to the second calling request, the module confirmation pop-up window is regenerated to the user terminal according to the module identifier corresponding to the second calling request.
5. The method according to claim 4, characterized in that If the module identifier corresponding to the module confirmation pop-up window includes the module identifier corresponding to the second call request, the method further includes: Determine whether the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request; If the permission type corresponding to the permission confirmation pop-up window includes the permission type corresponding to the second call request, respond to the second call request.
6. The method according to claim 1, characterized in that The permission confirmation pop-up window includes multiple sub-permissions corresponding to the permission type; Before responding to the first call request, the method further includes: If it is determined according to the confirmation information corresponding to the permission confirmation pop-up window that the user terminal has authorized some sub-permissions among the multiple sub-permissions, the response to the first call request is completed according to the authorized sub-permissions, so that the function module corresponding to the first call request completes the permission call to the user terminal according to the authorized sub-permissions.
7. The method according to claim 1, characterized in that Before responding to the first call request, the method further includes: Acquire terminal information corresponding to the user terminal; Generate permission identification information according to the terminal information and the permission type corresponding to the first call request; If it is confirmed in the user terminal that the permission module corresponding to the permission identification information is closed, a permission activation prompt is generated according to the permission identification information and confirmation information corresponding to the permission confirmation pop-up window; The permission activation prompt is sent to the user terminal to prompt that the permission module needs to be activated in order to complete the response to the first call request.
8. A permission calling device, characterized in that: include: An information acquisition unit, used to acquire module information of multiple functional modules to be deployed in a user terminal; The module information at least includes a module identifier, an operating system type, a protocol type, and a permission type to be called corresponding to the functional module; An environment generating unit, configured to generate a sandbox environment according to a plurality of the operating system types, protocol types, and permission types; A pop-up window generating unit, configured to generate a module confirmation pop-up window to the user terminal according to a module identifier corresponding to each of the functional modules in the sandbox environment when any of the functional modules initiates a first call request corresponding to any of the permission types; A permission confirmation unit, configured to generate a permission confirmation pop-up window of the permission type corresponding to the first call request to the user terminal after receiving confirmation information corresponding to the module confirmation pop-up window returned by the user terminal; The call completion unit is used to respond to the first call request after receiving the confirmation information corresponding to the permission confirmation pop-up window returned by the user terminal, so that the function module corresponding to the first call request completes the permission call to the user terminal.
9. A computer device, characterized in that: The computer device includes a memory and a processor; The memory is used to store computer programs; The processor is configured to execute the computer program and implement the method according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, causes the processor to implement the method according to any one of claims 1 to 7.