A permission management system, method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a kind of permission management system, method, device, electronic equipment and storage medium, it is related to information security technical field.The system, whenever at least one scene identifier corresponding policy is obtained by server, the specified database is updated using the obtained policy;Client sends the policy acquisition request carrying the scene identifier currently recorded in client and corresponding version number to server regularly;After receiving the policy acquisition request, if the target scene identifier meeting predetermined condition is detected by server, then generate and send the feedback result to client;Client updates local policy information based on the feedback result;When detecting the user operation for any scene identifier represented application scenario, client issues the notification information about permission application based on local policy information.The compliance degree about the permission application of client can be improved by using the scheme provided by the embodiments of the present application.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to an access control system, method, apparatus, electronic device, and storage medium. Background Technology

[0002] Before accessing a user's device functions and / or obtaining the user's personal information, the client needs to request the relevant permissions from the user's device. In accordance with the requirements of relevant regulations on personal information security protection, the client needs to inform the user of the information related to the permission request during the permission request process.

[0003] In related technologies, the client pre-stores policies corresponding to various application scenarios. Each policy for any application scenario at least characterizes the target permission required in that scenario, the reason for the permission request, and the prompt regarding whether the user allows the client to use that target permission. For example, in an application scenario where a user triggers the scan function, the client determines the policy corresponding to that scenario and then, based on that policy, outputs a notification about the permission request. When this notification exists in the form of a pop-up window, it can be called a compliance prompt pop-up.

[0004] However, when the relevant regulations are updated, the only way to update the policy is to update the client version. This leads to the following problem: if the client version is not updated in time, the policy for permission requests on the client cannot be updated, causing the client to fail to meet the updated regulations, that is, the compliance level is not high.

[0005] It is evident that improving the compliance of client permission requests without requiring client version updates is an urgent issue that needs to be addressed. Summary of the Invention

[0006] The purpose of this invention is to provide a permission management system, method, apparatus, electronic device, and storage medium to improve the compliance of client permission requests without requiring updates to the client version. The specific technical solution is as follows:

[0007] Firstly, in order to achieve the above objectives, embodiments of the present invention disclose a permission management system, including: a server and a client;

[0008] The server is used to update a specified database whenever it obtains a policy corresponding to at least one scenario identifier; wherein each scenario identifier is used to represent an application scenario, and the specified database is used to record the policy and version number corresponding to the scenario identifier for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier.

[0009] The client is used to periodically send policy retrieval requests to the server; wherein the policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number;

[0010] The server is further configured to, upon receiving the policy acquisition request, generate and send a feedback result to the client if it detects a target scene identifier that meets a predetermined condition; wherein the feedback result includes the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy acquisition request is less than the version number recorded in the specified database.

[0011] The client is also configured to update local policy information based on the feedback results; wherein the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client.

[0012] The client is also configured to, when detecting a user operation on any application scenario represented by a scenario identifier, issue a notification message regarding permission requests based on the policy corresponding to the scenario identifier in the local policy information.

[0013] Optionally, the client periodically sends a policy retrieval request to the server, including:

[0014] When the client finishes starting, it constructs a policy retrieval request and sends the constructed policy retrieval request to the server, using the predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client.

[0015] Once the client has started, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

[0016] Optionally, the client updates its local policy information based on the feedback result, including:

[0017] If the feedback result is the one given by the server when it receives the specified retrieval request, the local policy information is updated based on the feedback result using a full update method; wherein, the specified retrieval request is the policy retrieval request sent when the client finishes startup;

[0018] Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

[0019] Optionally, the strategy corresponding to each scenario identifier includes: the wording content about permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a specified flag; wherein, the specified flag is a flag used to indicate whether a reminder message about permission requests will pop up;

[0020] Based on the policy corresponding to the scenario identifier in the local policy information, the client sends a notification message regarding the permission request, including:

[0021] Query the flag value of the specified flag;

[0022] If the flag value of the specified flag indicates that no reminder message about permission request will pop up, then query whether the client has the target permission and obtain the query result; wherein, the target permission is the permission required in the application scenario represented by the scenario flag;

[0023] If the value of the specified flag represents a pop-up reminder message about permission request, or if the query result indicates that the client does not have the target permission, then a first notification message is issued, wherein the first notification message is generated using the script content and is used to ask the user whether to enable the target permission;

[0024] In response to obtaining an instruction to refuse to grant the target permission based on the first notification information, a second notification information is issued; wherein the second notification information is generated using the dialogue content and is used to guide the user to grant the target permission.

[0025] Optionally, the client is further configured to: determine whether the time difference between the current time and the time of the most recent notification exceeds a predetermined time before sending the first notification information;

[0026] If the number of cases exceeds the limit, then the step of issuing the first notification message will be executed.

[0027] Secondly, to achieve the above objectives, this invention discloses a permission management method applied to a client, wherein the client communicates with a server; the server is used to update a specified database and a version number corresponding to at least one scene identifier whenever it obtains a policy corresponding to at least one scene identifier; wherein each scene identifier is used to represent an application scene, the specified database is used to record the policies corresponding to the scene identifiers for each application scene of the client, and the version number corresponding to each scene identifier is the version number of the policy corresponding to that scene identifier;

[0028] The method includes:

[0029] The client periodically sends a policy retrieval request to the server. The policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets a predetermined condition, it generates and sends a feedback result to the client. The feedback result includes the policy corresponding to the target scene identifier in the specified database and the version number corresponding to the target scene identifier recorded by the server. The predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded by the server.

[0030] Based on the feedback results, the local policy information is updated; wherein, the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client;

[0031] When a user operation is detected that targets the application scenario represented by any scenario identifier, a notification message regarding the permission request is issued based on the policy corresponding to that scenario identifier in the local policy information.

[0032] Optionally, the step of periodically sending a policy acquisition request to the server includes:

[0033] When the client finishes starting, it constructs a policy retrieval request and sends the constructed policy retrieval request to the server, using the predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client.

[0034] Once the client has started, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

[0035] Optionally, updating the local policy information based on the feedback result includes:

[0036] If the feedback result is the one given by the server when it receives the specified retrieval request, the local policy information is updated based on the feedback result using a full update method; wherein, the specified retrieval request is the policy retrieval request sent when the client finishes startup;

[0037] Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

[0038] Thirdly, in order to achieve the above objectives, this invention discloses a permission management device applied to a client, wherein the client communicates with a server; the server is used to update a specified database and a version number corresponding to at least one scene identifier whenever it obtains a policy corresponding to at least one scene identifier; wherein each scene identifier is used to represent an application scene, the specified database is used to record the policies corresponding to the scene identifiers for each application scene of the client, and the version number corresponding to each scene identifier is the version number of the policy corresponding to that scene identifier;

[0039] The device includes:

[0040] The sending module is used to periodically send policy retrieval requests to the server. The policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets a predetermined condition, it generates and sends a feedback result to the client. The feedback result includes the policy corresponding to the target scene identifier in the specified database and the version number corresponding to the target scene identifier recorded by the server. The predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded by the server.

[0041] An update module is used to update local policy information based on the feedback results; wherein, the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client;

[0042] The issuing module is used to issue a notification message about permission requests based on the policy corresponding to the scene identifier in the local policy information when a user operation is detected that targets the application scene represented by any scene identifier.

[0043] This invention also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0044] Memory, used to store computer programs;

[0045] The processor, when executing a program stored in memory, implements any of the aforementioned permission management methods.

[0046] Beneficial effects of the embodiments of the present invention:

[0047] Based on the above scheme, when the server obtains the policy corresponding to a scene identifier, it updates the specified database using the obtained policy. The client periodically sends a policy retrieval request to the server, carrying the scene identifier currently recorded in the client and its corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets predetermined conditions, it generates and sends a feedback result to the client. Since the feedback result contains the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database, the client can update its local policy information based on the feedback result. When the client detects a user operation on any scene identifier representing an application scenario, it issues a notification message regarding permission requests based on the policy corresponding to that scene identifier in its local policy information. Therefore, in this scheme, the server can update the specified database whenever it obtains the policy corresponding to a scene identifier. If the version number corresponding to the scene identifier on the server is greater than the version number in the client, the server sends the policy corresponding to the target scene identifier to the client, enabling the client to update its local policy information. The client can then issue a notification message regarding permission requests based on its local policy information. Therefore, this solution can improve the compliance of client permission requests without requiring client version updates.

[0048] Of course, implementing any product or method of the present invention does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0050] Figure 1 A schematic diagram of the structure of a permission management system provided in an embodiment of the present invention;

[0051] Figure 2 A flowchart illustrating a permission management method provided in an embodiment of the present invention;

[0052] Figure 3 A schematic diagram of the structure of a permission management system provided in an embodiment of the present invention;

[0053] Figure 4 A timing diagram of a permission management system provided in an embodiment of the present invention;

[0054] Figure 5 A timing diagram of a permission management system provided in an embodiment of the present invention;

[0055] Figure 6 This is a flowchart illustrating how a client sends a notification about a permission request based on the policy corresponding to the scenario identifier in the local policy information, according to an embodiment of the present invention.

[0056] Figure 7 This is a flowchart illustrating how a client sends a notification about a permission request based on the policy corresponding to the scenario identifier in the local policy information, according to an embodiment of the present invention.

[0057] Figures 8(a)-8(d) This is a schematic diagram of a pop-up window provided in an embodiment of the present invention;

[0058] Figure 9 This is a schematic diagram of the structure of a permission management device provided in an embodiment of the present invention;

[0059] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art based on the present invention are within the scope of protection of the present invention.

[0061] To better understand the embodiments of the present invention, the prior art will be described below.

[0062] Relevant regulations require that before the first use of extended business functions, the data subject should be informed of the extended business functions and the necessary personal information to be collected through an interactive interface or design (such as pop-ups, text descriptions, fill-in boxes, prompts, sound prompts, etc.), and the data subject should be allowed to select and agree to each extended business function. It should be noted that such applications for extended business functions can be called proactive requests.

[0063] In related technologies, the client uses the system's native sensitive permission framework or a third-party open-source framework to request permissions, which essentially extends business functionality. Specifically, according to relevant regulations, corresponding policies are bound to different application scenarios for different permission requests. When a user triggers an application scenario, the client sends a pop-up message to request permissions for that application scenario. For example, when a user triggers the scan function, the client needs to obtain camera permissions. The client will then display a camera permission pop-up, showing the user that the client wishes to use the camera for taking pictures; the camera permission pop-up also includes allow and deny selection boxes.

[0064] However, when relevant regulations are updated, the technology can only update the policies by updating the client version. This leads to the following problem: if the client version is not updated in time, the client's policy for permission requests cannot be updated, causing the client to fail to meet the updated regulations, that is, the compliance level is not high.

[0065] To improve the compliance of client permission requests without requiring client version updates, embodiments of the present invention provide a permission management system, method, apparatus, electronic device, and storage medium.

[0066] The following section first introduces a permission management system provided by an embodiment of the present invention.

[0067] The permission management system provided in this embodiment of the invention includes a server and a client. The server is the functional software located on the server device side, corresponding to the client, while the client is the functional software located on the user device side, i.e., the client program. In practical applications, the user device where the client is located can be a smartphone, tablet, etc.; furthermore, the client in this embodiment of the invention can be any application that requires requesting relevant permissions from the user device, such as an instant messaging client, a news client, or an audio / video client.

[0068] An embodiment of the present invention provides a permission management system, which may include: a server and a client;

[0069] The server is used to update a specified database whenever it obtains a policy corresponding to at least one scenario identifier; wherein each scenario identifier is used to represent an application scenario, and the specified database is used to record the policy and version number corresponding to the scenario identifier for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier.

[0070] The client is used to periodically send policy retrieval requests to the server; wherein the policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number;

[0071] The server is further configured to, upon receiving the policy acquisition request, generate and send a feedback result to the client if it detects a target scene identifier that meets a predetermined condition; wherein the feedback result includes the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy acquisition request is less than the version number recorded in the specified database.

[0072] The client is also configured to update local policy information based on the feedback results; wherein the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client.

[0073] The client is also configured to, when detecting a user operation on any application scenario represented by a scenario identifier, issue a notification message regarding permission requests based on the policy corresponding to the scenario identifier in the local policy information.

[0074] Based on the above scheme, when the server obtains the policy corresponding to a scene identifier, it updates the specified database using the obtained policy. The client periodically sends a policy retrieval request to the server, carrying the scene identifier currently recorded in the client and its corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets predetermined conditions, it generates and sends a feedback result to the client. Since the feedback result contains the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database, the client can update its local policy information based on the feedback result. When the client detects a user operation on any scene identifier representing an application scenario, it issues a notification message regarding permission requests based on the policy corresponding to that scene identifier in its local policy information. Therefore, in this scheme, the server can update the specified database whenever it obtains the policy corresponding to a scene identifier. If the version number corresponding to the scene identifier on the server is greater than the version number in the client, the server sends the policy corresponding to the target scene identifier to the client, enabling the client to update its local policy information. The client can then issue a notification message regarding permission requests based on its local policy information. Therefore, this solution can improve the compliance of client permission requests without requiring client version updates.

[0075] The following description, in conjunction with the accompanying drawings, introduces an embodiment of the permission management system provided by the present invention.

[0076] Figure 1 A schematic diagram of the structure of a permission management system provided in an embodiment of the present invention is shown below. Figure 1 As shown, the system may include: server 110 and client 120;

[0077] The server 110 is used to update a specified database whenever it obtains a policy corresponding to at least one scenario identifier; wherein each scenario identifier is used to represent an application scenario, and the specified database is used to record the policy and version number corresponding to the scenario identifier for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier.

[0078] It is understandable that the server-side of the access control system can update a specified database using the policy corresponding to a scene identifier. The obtained policy is the policy corresponding to the scene identifier; that is, policies are categorized by scene identifiers, and scene identifiers are used to characterize application scenarios. Therefore, the obtained policy essentially belongs to a specific application scenario. Furthermore, the server can obtain one policy corresponding to a scene identifier or multiple policies corresponding to multiple scene identifiers at once; this embodiment of the invention does not specifically limit this.

[0079] It is understandable that during the update process of the specified database, the server can classify and record the acquired strategies according to the scenario identifiers corresponding to the strategies, and update the version number corresponding to the scenario identifiers. In one implementation, the acquired strategies may include dialogue content. In the specified database, the server can save the acquired strategies along with other information as strategies in the server's database. The strategies saved by the server may include scenario identifiers, version numbers, dialogue content, generation time, and update time, etc. Optionally, in another implementation, the acquired strategies may include dialogue content. In the specified database, the server can use the scenario as the table name. The table data in the scenario table may include: version number, dialogue content, generation time, update time, etc. Updating the specified database is equivalent to updating the table data in the scenario table. Of course, the above-described update process of the specified database is only illustrative and does not constitute a limitation on the embodiments of the present invention.

[0080] In this system, the scene identifier and version number can have a corresponding relationship. For example, the scene identifier can be in the form of a key, and the version number can be in the form of a value. The scene identifier and version number can be stored as a key-value pair. Each time the specified database is updated, the server can query the version number corresponding to the scene identifier to determine the version number of the scene identifier before the acquisition strategy, and then update the version number based on the determined version number. For example, updating the version number can be done by incrementing the version number value by one. For instance, if a scene identifier has a version number of 100, incrementing the version number value will result in an updated version number of 101. Of course, the above process of recording version numbers is only illustrative and does not limit the scope of this embodiment of the invention.

[0081] It should be noted that the process of the server obtaining the policy can be achieved through manual processing of the policies stored on the server. For example, a person can add a new policy corresponding to a scene identifier to the server, delete a policy from the server, or update the policy corresponding to a scene identifier on the server. Optionally, in one implementation, a person can also query the policy corresponding to a scene identifier from the server. Of course, the above-described manual processing of policies on the server is merely illustrative and does not constitute a specific limitation in this embodiment of the invention.

[0082] For example, an application scenario is when a user triggers the scan function. This application scenario can be represented by scenario identifier 1. A human (such as an operations and maintenance administrator) inputs a policy containing new dialogue content into the server. When the server obtains the policy, it adds the policy containing the new dialogue content to the data table belonging to scenario identifier 1 in the specified database and updates the version number corresponding to scenario identifier 1.

[0083] The client 120 is used to periodically send policy acquisition requests to the server; wherein the policy acquisition request carries the scene identifier currently recorded in the client and the corresponding version number.

[0084] It is understood that a client belonging to the access control system can periodically send policy retrieval requests to the server; the policy retrieval request can carry the scene identifier currently recorded in the client and the corresponding version number. For example, when the client is running and connected to the network, it can periodically send policy retrieval requests to the server based on a pre-set timer; this embodiment of the invention does not specifically limit this.

[0085] For example, in one implementation, the client periodically sends a policy retrieval request to the server, which may include steps A1 and A2:

[0086] A1. When the client finishes starting, it constructs a policy retrieval request and sends the constructed policy retrieval request to the server, using the predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client.

[0087] It is understandable that when a client first starts up and sends a policy retrieval request to the server for the first time, the request may carry the scene identifier recorded by the client and the corresponding, predetermined initial version number. It should be noted that the predetermined initial version number is itself still the version number corresponding to the scene identifier; however, when the client has just started up and is sending a policy retrieval request for the first time, in order to ensure the completeness and accuracy of the policies recorded by the client, the version number carried in the policy retrieval request is the predetermined initial version number. For example, the predetermined initial version number can be 0; this embodiment of the invention is for illustrative purposes only and does not impose specific limitations.

[0088] A2. After the client starts up, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

[0089] Understandably, after the client has started up and the initial policy retrieval request has been sent, the client can periodically construct a policy retrieval request and send it to the server, using the version number corresponding to the scenario identifier in the local policy information as the version number corresponding to the currently recorded scenario identifier in the client. It should be noted that the version number corresponding to the scenario identifier in the local policy information can be used to indicate that the policy recorded in the client is the current version in the client. For example, after the client has started up, it can periodically send policy retrieval requests to the server on a daily, weekly, or other time basis.

[0090] The server 110 is further configured to, upon receiving the policy acquisition request, generate and send a feedback result to the client if it detects a target scene identifier that meets a predetermined condition; wherein the feedback result includes the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy acquisition request is less than the version number recorded in the specified database.

[0091] It is understandable that after receiving a policy retrieval request, the server can check whether there is a target scene identifier that meets the predetermined conditions. If the target scene identifier exists, the server can generate a feedback result and send the feedback result to the client.

[0092] The predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database. In other words, for the same scenario identifier, the policy recorded by the client differs from the policy recorded by the server. The server can construct a feedback result from the policy corresponding to the target scenario identifier that meets the predetermined condition and its version number, and send the feedback result to the client.

[0093] The client 120 is also configured to update local policy information based on the feedback results; wherein the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client.

[0094] Understandably, the client can obtain the feedback results sent by the client and use the policies in the feedback results to update the local policy information; the local policy information includes the policies and version numbers corresponding to each scenario identifier that the client has obtained.

[0095] For example, in one implementation, the client updating local policy information based on the feedback result may include step B1:

[0096] B1. If the feedback result is the one given by the server when it receives the specified acquisition request, the local policy information is updated based on the feedback result using a full update method; wherein, the specified acquisition request is the policy acquisition request sent when the client finishes startup.

[0097] Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

[0098] It is understandable that, upon client startup and the initial sending of a policy retrieval request to the server, the client can utilize the feedback from the server upon receiving the request to obtain the policies corresponding to all scene identifiers within the client. Then, using a full update approach, the client resets all policies corresponding to scene identifiers in its local policy information using the policies sent by the server, and updates the version numbers to ensure policy accuracy. The version numbers corresponding to each scene identifier in the client can be updated after the policy update. For example, updating the version numbers in the client can be done by incrementing the initial version number 0 to obtain a new version number 1; or by using the version number corresponding to the target scene identifier sent by the server as the new version number. Of course, the above-described version number update process in the client is merely illustrative and does not constitute a specific limitation of this embodiment of the invention.

[0099] Understandably, once the client has started and completed its initial policy retrieval request, it can obtain policies corresponding to target scene identifiers that meet predetermined conditions. Then, using the policies sent by the server, it updates the policies corresponding to the target scene identifiers in its local policy information using an incremental update method, and updates the version number, thus ensuring rapid policy updates. Specifically, the version number corresponding to each scene identifier in the client can be updated after the policy update, based on the previous version number. For example, updating the version number in the client can be done by incrementing the previous version number 100 by one to obtain a new version number 101; or it can be updated using the version number corresponding to the target scene identifier sent by the server. Of course, the above-described version number update process in the client is merely illustrative and does not constitute a specific limitation of this embodiment of the invention.

[0100] The client 120 is also configured to, when detecting a user operation on any application scenario represented by a scenario identifier, issue a notification message regarding permission requests based on the policy corresponding to the scenario identifier in the local policy information.

[0101] Understandably, the client can detect whether a user operation pertains to an application scenario represented by any scenario identifier. When a user operation pertaining to an application scenario represented by any scenario identifier is detected, the client can issue a notification regarding the permission request based on the policy corresponding to that scenario identifier in its locally stored policy information. This notification regarding the permission request may include inquiries to the user about whether they allow the client to use the permissions required in the scenario corresponding to the scenario identifier, the reason for using the required permissions, and wording tailored to comply with relevant regulations. This embodiment of the invention does not specifically limit the specific wording in this regard.

[0102] Based on the above scheme, when the server obtains the policy corresponding to a scene identifier, it updates the specified database using the obtained policy. The client periodically sends a policy retrieval request to the server, carrying the scene identifier currently recorded in the client and its corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets predetermined conditions, it generates and sends a feedback result to the client. Since the feedback result contains the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database, the client can update its local policy information based on the feedback result. When the client detects a user operation on any scene identifier representing an application scenario, it issues a notification message regarding permission requests based on the policy corresponding to that scene identifier in its local policy information. Therefore, in this scheme, the server can update the specified database whenever it obtains the policy corresponding to a scene identifier. If the version number corresponding to the scene identifier on the server is greater than the version number in the client, the server sends the policy corresponding to the target scene identifier to the client, enabling the client to update its local policy information. The client can then issue a notification message regarding permission requests based on its local policy information. Therefore, this solution can improve the compliance of client permission requests without requiring client version updates.

[0103] In addition, in this embodiment, the client can update the policy without re-issuing a new version, reducing maintenance costs and the complexity of the policy update process. Furthermore, in different application scenarios, for the same permission request, the client can issue a notification message belonging to the application scenario based on the policy of the application scenario triggered by the user, so as to obtain the permission for that application scenario, reducing disagreements and disputes between the user and the client.

[0104] Optionally, in another embodiment of the present invention, the strategy corresponding to each scenario identifier includes: the wording content about permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a specified flag; wherein, the specified flag is a flag used to indicate whether a reminder message about permission requests will pop up;

[0105] Based on the policy corresponding to the scenario identifier in the local policy information, the client issues a notification message regarding the permission request, which may include steps C1-C4:

[0106] C1, query the flag value of the specified flag.

[0107] It is understood that, since the policy corresponding to each scenario identifier includes: the wording content regarding permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a specified flag, and the specified flag can be used to indicate whether a reminder message regarding permission requests will pop up, the client can first find the policy corresponding to the application scenario triggered by the user operation from the local policy information, and then query the flag value of the specified flag in the found policy. For example, the flag value of the specified flag can be 0 or 1. When the flag value is 0, the specified flag is used to indicate that a reminder message regarding permission requests will pop up; when the flag value is 1, the specified flag is used to indicate that a reminder message regarding permission requests will not pop up. Optionally, the specified flag can be a forced pop-up flag used to indicate whether a pop-up window needs to be forcibly displayed, and this embodiment of the invention does not specifically limit this.

[0108] It should be noted that when the client detects a user operation targeting any application scenario represented by a scenario identifier, the client can query the flag value of the specified flag.

[0109] C2, if the flag value of the specified flag indicates that no reminder message about permission request will pop up, then query whether the client has the target permission and obtain the query result; wherein, the target permission is the permission required to be used in the application scenario represented by the scenario identifier.

[0110] Understandably, if the specified flag value indicates that no notification message regarding permission requests will pop up, then the client can query whether it possesses the permissions required for the application scenario triggered by the user's action, i.e., the target permissions. For example, the client can call the system permission interface to verify whether it has the required permissions. If calling the system permission interface allows the client to use the required permissions, then it means the client possesses the necessary permissions. The method for permission querying in this embodiment is merely illustrative and not specifically limited.

[0111] C3, if the value of the specified flag represents a pop-up reminder message about permission request, or if the query result indicates that the client does not have the target permission, then a first notification message is issued, wherein the first notification message is generated using the dialogue content and is used to ask the user whether to enable the target permission.

[0112] Understandably, if the flag value of the specified flag indicates a pop-up notification message regarding permission requests, or if it is found that the client does not have the target permission, the client will issue a first notification message to ask the user whether to grant the target permission. This first notification message can be generated using the wording content from the local policy information corresponding to the policy of the application scenario triggered by the user. For example, the first notification message can be a pop-up window displaying "Allow the client to obtain the target permission?", which may also include two buttons for user interaction with the client: "Deny" and "Allow". This embodiment of the invention is merely illustrative and does not constitute a specific limitation.

[0113] C4, in response to obtaining an instruction to refuse to enable the target permission based on the first notification information, issues a second notification information; wherein the second notification information is generated using the dialogue content and is used to guide the user to enable the target permission.

[0114] Understandably, if a user refuses to grant the target permission after being prompted by the first notification message, the client can send a second notification message to guide the user to grant the target permission in the system settings. For example, the second notification message could be a pop-up window displaying "The client needs to obtain the target permission; please grant it in the settings." This embodiment of the invention is merely illustrative and does not constitute a specific limitation.

[0115] For example, in one implementation, the client is further configured to: determine whether the time difference between the current time and the time of the most recent notification exceeds a predetermined time before sending the first notification message;

[0116] If the number of cases exceeds the limit, then the step of issuing the first notification message will be executed.

[0117] Understandably, before sending the first notification, the client can determine whether the time difference between the current time and the time of the most recent notification exceeds a predetermined time; that is, the time interval between two notifications sent by the client must be at least a predetermined time. For example, relevant regulations stipulate that if the data subject does not agree to the collection of personal information necessary for extended business functions, the data controller should not repeatedly solicit the data subject's consent. Unless the data subject actively chooses to enable extended functions, the number of times consent is solicited from the data subject within 48 hours should not exceed once. In this case, the client's permission request process can be called a passive request; therefore, the first notification sent by the client to request permission can be sent 48 hours after the last notification, further improving the compliance of this solution.

[0118] In this embodiment, the client can apply for target permissions based on local policy information that is synchronized with the server's policy updates, targeting the application scenario corresponding to the user's operation. Since this embodiment can utilize the policy synchronized with the server and issue notification information in accordance with relevant regulations, it can be seen that this embodiment can improve the compliance of client permission requests without updating the client version.

[0119] Based on the aforementioned permission management system, from the client's perspective, this embodiment of the invention provides a permission management method. This permission management method is applied to a client of the permission management system, the client communicating with a server; the server, whenever it obtains a policy corresponding to at least one scenario identifier, updates a designated database and the version number corresponding to at least one scenario identifier using the obtained policy; wherein, each scenario identifier represents an application scenario, the designated database records the policies corresponding to the scenario identifiers for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier; for example... Figure 2 As shown, the access control method may include steps S201-S203:

[0120] S201, a policy retrieval request is periodically sent to the server. The policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number. This allows the server to generate and send a feedback result to the client if it detects a target scene identifier that meets a predetermined condition after receiving the policy retrieval request. The feedback result includes the policy corresponding to the target scene identifier in the specified database and the version number corresponding to the target scene identifier recorded by the server. The predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded by the server.

[0121] In one implementation, the periodic sending of the policy acquisition request to the server may include steps A1 and A2:

[0122] A1. When the client finishes starting, it constructs a policy retrieval request and sends the constructed policy retrieval request to the server, using the predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client.

[0123] A2. After the client starts up, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

[0124] S202, based on the feedback result, update the local policy information; wherein, the local policy information includes the policy and version number corresponding to each scenario identifier obtained by the client.

[0125] In one implementation, updating the local policy information based on the feedback result may include step B1:

[0126] B1. If the feedback result is the one given by the server when it receives the specified acquisition request, the local policy information is updated based on the feedback result using a full update method; wherein, the specified acquisition request is the policy acquisition request sent when the client finishes startup.

[0127] Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

[0128] S203, when a user operation is detected targeting any application scenario represented by a scenario identifier, a notification message regarding the permission request is issued based on the policy corresponding to the scenario identifier in the local policy information.

[0129] In one implementation, the strategy corresponding to each scenario identifier includes: the wording content about permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a specified flag; wherein, the specified flag is a flag used to indicate whether a reminder message about permission requests will pop up;

[0130] The client, based on the policy corresponding to the scenario identifier in the local policy information, issues a notification message regarding the permission request, which may include steps C1-C4:

[0131] C1, query the flag value of the specified flag.

[0132] C2, if the flag value of the specified flag indicates that no reminder message about permission request will pop up, then query whether the client has the target permission and obtain the query result; wherein, the target permission is the permission required to be used in the application scenario represented by the scenario identifier.

[0133] C3, if the value of the specified flag represents a pop-up reminder message about permission request, or if the query result indicates that the client does not have the target permission, then a first notification message is issued, wherein the first notification message is generated using the dialogue content and is used to ask the user whether to enable the target permission.

[0134] In one implementation, before issuing the first notification information, the steps may include: determining whether the time difference between the current time and the time of the most recent notification information issuance exceeds a predetermined time; if it does, then executing the step of issuing the first notification information.

[0135] C4, in response to obtaining an instruction to refuse to enable the target permission based on the first notification information, issues a second notification information; wherein the second notification information is generated using the dialogue content and is used to guide the user to enable the target permission.

[0136] It should be noted that the relevant descriptions of steps S201-S203 can be found in the relevant descriptions in the system embodiments, and will not be elaborated further here.

[0137] Based on the above scheme, when the server obtains the policy corresponding to a scene identifier, it updates the specified database using the obtained policy. The client periodically sends a policy retrieval request to the server, carrying the scene identifier currently recorded in the client and its corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets predetermined conditions, it generates and sends a feedback result to the client. Since the feedback result contains the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database, the client can update its local policy information based on the feedback result. When the client detects a user operation on any scene identifier representing an application scenario, it issues a notification message regarding permission requests based on the policy corresponding to that scene identifier in its local policy information. Therefore, in this scheme, the server can update the specified database whenever it obtains the policy corresponding to a scene identifier. If the version number corresponding to the scene identifier on the server is greater than the version number in the client, the server sends the policy corresponding to the target scene identifier to the client, enabling the client to update its local policy information. The client can then issue a notification message regarding permission requests based on its local policy information. Therefore, this solution can improve the compliance of client permission requests without requiring client version updates.

[0138] To better understand this solution, Figure 3 A schematic diagram of the structure of a permission management system provided by an embodiment of the present invention is shown. Figure 3 As shown, the permission management system may include a server and a client.

[0139] The server-side may include: a compliance policy management module, a storage module, and a policy distributor;

[0140] The compliance policy management module can be used to obtain the policy corresponding to at least one scenario identifier;

[0141] The storage module can be used to update a specified database whenever a policy corresponding to at least one scenario identifier is obtained, using the obtained policy.

[0142] The policy dispatcher can be used to receive policy retrieval requests sent by the server, and after receiving the policy retrieval request, if it detects that there is a target scene identifier that meets the predetermined conditions, it generates and sends the feedback result to the client.

[0143] The client may include: a communication subsystem, a decision-making submodule, and an interaction submodule; wherein, the decision-making submodule may include a database for persistent storage;

[0144] The communication subsystem can be used to periodically send policy retrieval requests to the server. The policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number. The application scenarios corresponding to the scene identifier currently recorded in the client can include: account tracking, live streaming floating window, ID card recognition, bank card recognition, two-way video, one-way video, software update, etc.

[0145] The decision submodule can be used to update local policy information based on the feedback results; wherein, the local policy information can be stored in the database mentioned above for persistent storage.

[0146] The interaction submodule can be used to issue a notification message about permission requests based on the policy corresponding to the scenario identifier in the local policy information when a user operation is detected that targets the application scenario represented by any scenario identifier.

[0147] It is understandable that, in the client, the communication subsystem, decision-making submodule, and interaction submodule can be collectively referred to as the client's permission module.

[0148] Based on the above scheme, when the server obtains the policy corresponding to a scene identifier, it updates the specified database using the obtained policy. The client periodically sends a policy retrieval request to the server, carrying the scene identifier currently recorded in the client and its corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets predetermined conditions, it generates and sends a feedback result to the client. Since the feedback result contains the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database, the client can update its local policy information based on the feedback result. When the client detects a user operation on any scene identifier representing an application scenario, it issues a notification message regarding permission requests based on the policy corresponding to that scene identifier in its local policy information. Therefore, in this scheme, the server can update the specified database whenever it obtains the policy corresponding to a scene identifier. If the version number corresponding to the scene identifier on the server is greater than the version number in the client, the server sends the policy corresponding to the target scene identifier to the client, enabling the client to update its local policy information. The client can then issue a notification message regarding permission requests based on its local policy information. Therefore, this solution can improve the compliance of client permission requests without requiring client version updates.

[0149] To better understand this solution, Figure 4 This diagram illustrates a sequence flowchart of a permission management system under a full update policy, as provided in an embodiment of the present invention. Figure 4As shown, the access control system includes: a compliance policy management module, a storage module, a policy distributor, a communication subsystem, a decision-making submodule, and an interaction submodule. The process of executing the access control method may include steps S401-S4011:

[0150] S401, Policy Transmission.

[0151] Understandably, users can input policies into the compliance policy management module to complete the policy input process; the compliance policy management module can then send the acquired policies to the storage module to complete the policy transmission process.

[0152] S402, policy storage and version number update.

[0153] Understandably, whenever the storage module obtains a policy corresponding to at least one scenario identifier, it can use the obtained policy to update the specified database. The specified database is used to record the policies and version numbers corresponding to the scenario identifiers of various application scenarios of the client. Updating the specified database means updating the policies in the specified database and incrementing the version number by one.

[0154] S403, timed synchronization strategy and version number.

[0155] Understandably, the policy distributor can periodically retrieve policies and version numbers from the storage module; for example, the policy distributor can periodically synchronize all scenario policies to the storage module.

[0156] S404 returns a policy with a version number greater than the specified version number.

[0157] Understandably, the policy dispatcher can obtain policies from the storage module whose version number is greater than the version number in the policy dispatcher.

[0158] S405, when the client starts, the synchronization strategy version number is 0.

[0159] Understandably, during client startup, the communication subsystem can send a policy with client version number 0 to the policy distributor.

[0160] S406, Full Update Strategy.

[0161] Understandably, since the version number of the client policy received by the policy distributor is 0, the policy distributor can send the policies corresponding to all scenario identifiers to the communication subsystem in the form of a full update.

[0162] S407, update the decision submodule strategy according to the version number.

[0163] Understandably, the communication subsystem can update the local policy information in the decision-making submodule based on the received policy. The decision-making submodule also includes a persistent database to store the local policy information.

[0164] S408, requesting the current scene policy scene_code.

[0165] Understandably, the interaction submodule can be used to request the current scenario's strategy from the decision submodule when a user action is detected that targets an application scenario represented by any scenario identifier. For example, the interaction submodule can identify the scenario identifier `scene_code` and send a request carrying the scenario identifier to the decision submodule. The user action can trigger the application scenario.

[0166] S409, Current scenario strategy returned.

[0167] Understandably, the decision-making submodule can send the current scene strategy to the interaction submodule based on the scene identifier sent by the interaction submodule.

[0168] S4010, issue a notification message.

[0169] Understandably, the interaction submodule can send out notification information based on the strategy sent by the decision submodule.

[0170] S4011, Save the interactive results.

[0171] Understandably, during the interaction process, the interaction submodule can send the user's interaction choices to the decision submodule, and the decision submodule can save the interaction results.

[0172] In this embodiment, the access control system can perform a full update of all policies in the client when the client starts up, ensuring the integrity of the policies and the compliance of the client.

[0173] To better understand this solution, Figure 5 This diagram illustrates a sequence flowchart of a permission management system under a full update policy, as provided in an embodiment of the present invention. Figure 5 As shown, the access control system includes: a compliance policy management module, a storage module, a policy distributor, a communication subsystem, a decision-making submodule, and an interaction submodule. The process of executing the access control method may include steps S501-S5011:

[0174] S501, Policy Transmission.

[0175] Understandably, users can input policies into the compliance policy management module to complete the policy input process; the compliance policy management module can then send the acquired policies to the storage module to complete the policy transmission process.

[0176] It should be noted that during the temporary update of permission statements, the manually entered policies are updated for a relatively small number of policies. Correspondingly, the compliance policy management module also sends a relatively small number of policies that need to be updated to the storage module.

[0177] S502, policy storage and version number updates.

[0178] Understandably, the storage module can update a specified database whenever it obtains a policy corresponding to at least one scenario identifier. The specified database is used to record the policies and version numbers corresponding to the scenario identifiers of various application scenarios of the client. Updating the specified database means updating the policies in the specified database and incrementing the version number by one.

[0179] S503, timed synchronization strategy and version number.

[0180] Understandably, the policy distributor can periodically retrieve policies and version numbers from the storage module; for example, the policy distributor can periodically synchronize all scenario policies to the storage module.

[0181] S504 returns a policy with a version number greater than the specified version number.

[0182] Understandably, the policy dispatcher can obtain policies from the storage module whose version number is greater than the version number in the policy dispatcher.

[0183] S505, timed synchronization strategy and request version number.

[0184] Understandably, the communication subsystem can periodically send the policies currently stored in the decision submodule, along with their version numbers (i.e., the request version numbers), to the policy distributor.

[0185] S506 returns a policy with a version number greater than the requested version number.

[0186] It is understandable that the version number of the request received by the policy dispatcher is the version number of the policy currently stored in the client. The policy dispatcher can send policies with version numbers greater than the request version number in the storage module to the communication subsystem in the form of incremental updates.

[0187] S507, Update the decision submodule strategy based on the returned information.

[0188] Understandably, the communication subsystem can update the local policy information in the decision-making submodule based on the received policy. The decision-making submodule also includes a persistent database to store the local policy information.

[0189] S508, request the current scene policy scene_code.

[0190] Understandably, the interaction submodule can be used to request the current scenario's strategy from the decision submodule when a user action is detected that targets an application scenario represented by any scenario identifier. For example, the interaction submodule can identify the scenario identifier `scene_code` and send a request carrying the scenario identifier to the decision submodule. The user action can trigger the application scenario.

[0191] S509, Current scenario strategy returned.

[0192] It is understandable that the decision-making submodule can send the current scene strategy to the interaction submodule based on the scene identifier sent by the interaction submodule.

[0193] S5010, issue a notification message.

[0194] Understandably, the interaction submodule can send out notification information based on the strategy sent by the decision submodule.

[0195] S5011, save the interactive results.

[0196] Understandably, during the interaction process, the interaction submodule can send the user's interaction choices to the decision submodule, and the decision submodule can save the interaction results.

[0197] In this embodiment, the access control system can temporarily update the policies that have changed on the client side when relevant regulations change, thus ensuring the timeliness of the policies and the compliance of the client side.

[0198] To better understand this solution, based on a permission management method provided in an embodiment of the present invention... Figure 6 This diagram illustrates the process by which a client sends a notification about a permission request based on the policy corresponding to the scenario identifier in the local policy information. Figure 6 As shown, this implementation method may include steps S601-S604:

[0199] S601, query whether the flag value of the specified flag is a value that indicates a pop-up reminder message about permission request. If yes, proceed to step S603; if no, proceed to step S602.

[0200] S602, if the flag value of the specified flag is a value that indicates that no reminder information about permission requests will pop up, then query whether the client has the target permission and obtain the query result; wherein, the target permission is the permission required to be used in the application scenario represented by the scenario flag.

[0201] S603, if the flag value of the specified flag represents the value of popping up a reminder message about permission request, or if the query result shows that the client does not have the target permission, then a first notification message is issued, wherein the first notification message is generated using the dialogue content and is used to ask the user whether to enable the target permission.

[0202] S604, in response to obtaining an instruction to refuse to enable the target permission based on the first notification information, a second notification information is issued; wherein, the second notification information is information generated using the dialogue content and used to guide the user to enable the target permission.

[0203] It should be noted that the solution in this embodiment is for the case where the client sends notification information about the target permission for the first time. In this case, the process of the client requesting the target permission can also be called an active request.

[0204] It is understood that steps S601-S604 have been described in the foregoing embodiments and will not be repeated here.

[0205] In this embodiment, the client can send a first notification message to the user based on local policy information, and send a second notification message according to the user's operation. Since the local policy information is generated using the latest relevant regulations, the solution in this embodiment can ensure the compliance of the permission application process.

[0206] Alternatively, in another embodiment, such as Figure 7 As shown, in Figure 6 Based on this, the implementation method may further include step S701 before step S603:

[0207] S701, determine whether the time difference between the current time and the time of the most recent notification exceeds the predetermined time.

[0208] Understandably, if the time difference between the current time and the time of the most recent notification does not exceed the predetermined time, then step S603 is executed.

[0209] Furthermore, step S701 has been described in the foregoing embodiments and will not be repeated here.

[0210] It should be noted that the solution in this embodiment is for situations where the client sends notification information about the target permission not for the first time within a predetermined time. In this case, the process of the client requesting the target permission can also be called a passive request.

[0211] In this embodiment, the client can, in accordance with relevant regulations, refrain from issuing a second notification message for the request of the target permission within a preset time period. Therefore, the solution in this embodiment can ensure the compliance of the permission request process.

[0212] To better understand this solution, Figures 8(a)-8(d) The diagram shows a pop-up window on a client side of a permission management method provided by an embodiment of the present invention.

[0213] When a user first triggers the scan function, the specified flag in the application scenario's strategy requires the client to force a pop-up window. The client sends the first notification message: a permission notification pop-up window as shown in Figure 8(a), informing the user that "the scan function requires camera permission. Please enable it in the settings." After the user clicks the "OK" interaction button, as shown in Figure 8(b), the client calls the operating system's permission system and sends a pop-up window asking whether "taking photos and recording videos" is allowed. This pop-up window has three options: "Deny," "Allow for this run," and "Allow only while in use." After the user clicks "Deny," the client sends the second notification message: a permission notification pop-up window as shown in Figure 8(c), informing the user that "the scan function requires camera permission. Please enable it in the settings." The pop-up window also has two interaction buttons: "Cancel" and "Go to Enable." After the user clicks the "Go to Enable" interaction button, as shown in Figure 8(d), the client jumps to the application information in the system settings, allowing the user to set permissions independently in the permission management section related to permissions.

[0214] During the above process, if the user clicks "Allow this run" or "Allow only during use" in the pop-up window in Figure 8(b), or if the user sets camera permission to be enabled in the permission management in Figure 8(d), then the client can use the camera to complete the scanning function.

[0215] In this embodiment, the client can send a first notification message to the user based on local policy information, and send a second notification message according to the user's operation. Since the local policy information is generated using the latest relevant regulations, the solution in this embodiment can ensure the compliance of the permission application process.

[0216] Based on the aforementioned permission management system, from the client's perspective, embodiments of the present invention provide a permission management device. For example... Figure 9As shown, the permission management device is applied to the client of the permission management system, and the client communicates with the server. The server is used to update the specified database and the version number corresponding to at least one scene identifier whenever it obtains a policy corresponding to at least one scene identifier. Each scene identifier is used to represent an application scenario, the specified database is used to record the policies corresponding to the scene identifiers of each application scenario of the client, and the version number corresponding to each scene identifier is the version number of the policy corresponding to that scene identifier.

[0217] The access control device may include the following modules:

[0218] The sending module 910 is used to periodically send a policy acquisition request to the server. The policy acquisition request carries the scene identifier currently recorded in the client and the corresponding version number, so that after receiving the policy acquisition request, if the server detects that there is a target scene identifier that meets a predetermined condition, it generates and sends a feedback result to the client. The feedback result includes the policy corresponding to the target scene identifier in the specified database and the version number corresponding to the target scene identifier recorded by the server. The predetermined condition is that the version number carried in the policy acquisition request is less than the version number recorded by the server.

[0219] The update module 920 is used to update the local policy information based on the feedback result; wherein, the local policy information includes the policy and version number corresponding to each scenario identifier obtained by the client;

[0220] The issuing module 930 is used to issue a notification message regarding permission requests based on the policy corresponding to the scene identifier in the local policy information when a user operation is detected for any scene identifier representing the application scene.

[0221] Optionally, the sending module 910 is specifically used to construct a policy acquisition request and send the constructed policy acquisition request to the server when the client has finished starting up, using a predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client.

[0222] Once the client has started, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

[0223] Optionally, the update module 920 is specifically used to update the local policy information based on the feedback result if the feedback result is the one given by the server when it receives the specified acquisition request, using a full update method; wherein, the specified acquisition request is the policy acquisition request issued when the client finishes startup;

[0224] Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

[0225] Optionally, the strategy corresponding to each scenario identifier includes: the wording content about permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a specified flag; wherein, the specified flag is a flag used to indicate whether a reminder message about permission requests will pop up;

[0226] Module 930 is specifically used for

[0227] Query the flag value of the specified flag;

[0228] If the flag value of the specified flag indicates that no reminder message about permission request will pop up, then query whether the client has the target permission and obtain the query result; wherein, the target permission is the permission required in the application scenario represented by the scenario flag;

[0229] If the value of the specified flag represents a pop-up reminder message about permission request, or if the query result indicates that the client does not have the target permission, then a first notification message is issued, wherein the first notification message is generated using the script content and is used to ask the user whether to enable the target permission;

[0230] In response to obtaining an instruction to refuse to grant the target permission based on the first notification information, a second notification information is issued; wherein the second notification information is generated using the dialogue content and is used to guide the user to grant the target permission.

[0231] Optionally, before the issuing module 930 issues the first notification information, a judging module is also included to judge whether the time difference between the current time and the time of the most recent notification information exceeds a predetermined time.

[0232] If the number of cases exceeds the limit, then the step of issuing the first notification message will be executed.

[0233] Based on the above scheme, when the server obtains the policy corresponding to a scene identifier, it updates the specified database using the obtained policy. The client periodically sends a policy retrieval request to the server, carrying the scene identifier currently recorded in the client and its corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets predetermined conditions, it generates and sends a feedback result to the client. Since the feedback result contains the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded in the specified database, the client can update its local policy information based on the feedback result. When the client detects a user operation on any scene identifier representing an application scenario, it issues a notification message regarding permission requests based on the policy corresponding to that scene identifier in its local policy information. Therefore, in this scheme, the server can update the specified database whenever it obtains the policy corresponding to a scene identifier. If the version number corresponding to the scene identifier on the server is greater than the version number in the client, the server sends the policy corresponding to the target scene identifier to the client, enabling the client to update its local policy information. The client can then issue a notification message regarding permission requests based on its local policy information. Therefore, this solution can improve the compliance of client permission requests without requiring client version updates.

[0234] This invention also provides an electronic device, such as... Figure 10 As shown, it includes a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004, wherein the processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004.

[0235] Memory 1003 is used to store computer programs;

[0236] The processor 1001 is used to implement the permission management method provided in the embodiments of the present invention when executing the program stored in the memory 1003.

[0237] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0238] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0239] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0240] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0241] In another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements any of the above-described permission management methods.

[0242] In another embodiment of the present invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the permission management methods described above.

[0243] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0244] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0245] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the method and apparatus embodiments are basically similar to the system embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0246] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A permission management system, characterized in that, include: Server and client; The server is used to update a specified database whenever it obtains a policy corresponding to at least one scenario identifier; wherein each scenario identifier is used to represent an application scenario, and the specified database is used to record the policy and version number corresponding to the scenario identifier for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier. The client is used to periodically send policy retrieval requests to the server; wherein the policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number; The server is further configured to, upon receiving the policy acquisition request, generate and send a feedback result to the client if it detects a target scene identifier that meets a predetermined condition; wherein the feedback result includes the policy and version number corresponding to the target scene identifier in the specified database, and the predetermined condition is that the version number carried in the policy acquisition request is less than the version number recorded in the specified database. The client is also configured to update local policy information based on the feedback result; wherein the local policy information includes the policy and version number corresponding to each scenario identifier obtained by the client; the policy corresponding to each scenario identifier includes: the wording content about permission request corresponding to the application scenario represented by the scenario identifier, and the flag value of a specified flag; wherein the specified flag is a flag used to indicate whether to pop up a reminder message about permission request. The client is further configured to, when detecting a user operation targeting any application scenario represented by a scenario identifier, query the flag value of the specified flag; if the flag value of the specified flag indicates that no reminder information about permission requests will pop up, then query whether the client has the target permission and obtain a query result; wherein, the target permission is the permission required to be used in the application scenario represented by the scenario identifier; if the flag value of the specified flag indicates that a reminder information about permission requests will pop up, or if the query result indicates that the client does not have the target permission, then issue a first notification message, wherein the first notification message is generated using the dialogue content and is used to ask the user whether to enable the target permission; in response to obtaining an instruction to refuse to enable the target permission based on the first notification message, issue a second notification message; wherein, the second notification message is generated using the dialogue content and is used to guide the user to enable the target permission.

2. The system according to claim 1, characterized in that, The client periodically sends policy retrieval requests to the server, including: When the client finishes starting, it constructs a policy retrieval request and sends the constructed policy retrieval request to the server, using the predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client. Once the client has started, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

3. The system according to claim 2, characterized in that, Based on the feedback result, the client updates its local policy information including: If the feedback result is the one given by the server when it receives the specified acquisition request, the local policy information is updated based on the feedback result using a full update method; wherein, the specified acquisition request is the policy acquisition request sent when the client finishes startup; Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

4. The system according to claim 1, characterized in that, The client is also configured to: determine, before sending the first notification information, whether the time difference between the current time and the time of the most recent notification information sent exceeds a predetermined time; If the number of cases exceeds the limit, then the step of issuing the first notification message will be executed.

5. A method for managing access permissions, characterized in that, This system is applied to a client-side application that communicates with a server. The server, upon acquiring a policy corresponding to at least one scenario identifier, updates a designated database and the version number corresponding to at least one scenario identifier using the acquired policy. Each scenario identifier represents an application scenario, the designated database records policies corresponding to the scenario identifiers for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier. The policy corresponding to each scenario identifier includes: the message content regarding permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a designated flag. The designated flag is a flag indicating whether a notification message regarding permission requests should be displayed. The method includes: The client periodically sends a policy retrieval request to the server. The policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets a predetermined condition, it generates and sends a feedback result to the client. The feedback result includes the policy corresponding to the target scene identifier in the specified database and the version number corresponding to the target scene identifier recorded by the server. The predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded by the server. Based on the feedback results, the local policy information is updated; wherein, the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client; When a user operation is detected targeting any application scenario represented by a scenario identifier, the flag value of the specified flag is queried. If the flag value of the specified flag indicates that no reminder message about permission requests will pop up, then the client is queried to determine whether it has the target permission, and a query result is obtained. The target permission is the permission required for the application scenario represented by the scenario identifier. If the flag value of the specified flag indicates that a reminder message about permission requests will pop up, or if the query result indicates that the client does not have the target permission, then a first notification message is issued. The first notification message is generated using the script content and is used to ask the user whether to enable the target permission. In response to obtaining an instruction to refuse to enable the target permission based on the first notification message, a second notification message is issued. The second notification message is generated using the script content and is used to guide the user to enable the target permission.

6. The method according to claim 5, characterized in that, The periodic sending of policy retrieval requests to the server includes: When the client finishes starting, it constructs a policy retrieval request and sends the constructed policy retrieval request to the server, using the predetermined initial version number as the version number corresponding to the scene identifier currently recorded in the client. Once the client has started, it periodically uses the version number corresponding to the scene identifier in the local policy information as the version number corresponding to the scene identifier currently recorded in the client to construct a policy retrieval request and send the constructed policy retrieval request to the server.

7. The method according to claim 6, characterized in that, The step of updating the local policy information based on the feedback result includes: If the feedback result is the one given by the server when it receives the specified acquisition request, the local policy information is updated based on the feedback result using a full update method; wherein, the specified acquisition request is the policy acquisition request sent when the client finishes startup; Otherwise, based on the feedback results, the local policy information is updated using an incremental update method.

8. A permission management device, characterized in that, This system is applied to a client-side application that communicates with a server. The server, upon acquiring a policy corresponding to at least one scenario identifier, updates a designated database and the version number corresponding to at least one scenario identifier using the acquired policy. Each scenario identifier represents an application scenario, the designated database records policies corresponding to the scenario identifiers for each application scenario of the client, and the version number corresponding to each scenario identifier is the version number of the policy corresponding to that scenario identifier. The policy corresponding to each scenario identifier includes: the message content regarding permission requests corresponding to the application scenario represented by the scenario identifier, and the flag value of a designated flag. The designated flag is a flag indicating whether a notification message regarding permission requests should be displayed. The device includes: The sending module is used to periodically send policy retrieval requests to the server. The policy retrieval request carries the scene identifier currently recorded in the client and the corresponding version number. After receiving the policy retrieval request, if the server detects a target scene identifier that meets a predetermined condition, it generates and sends a feedback result to the client. The feedback result includes the policy corresponding to the target scene identifier in the specified database and the version number corresponding to the target scene identifier recorded by the server. The predetermined condition is that the version number carried in the policy retrieval request is less than the version number recorded by the server. An update module is used to update local policy information based on the feedback results; wherein, the local policy information includes the policies and version numbers corresponding to each scenario identifier obtained by the client; The issuing module is configured to, when detecting a user operation targeting an application scenario represented by any scenario identifier, query the flag value of the specified flag; if the flag value of the specified flag indicates that no reminder message about permission requests will pop up, then query whether the client has the target permission and obtain the query result; wherein, the target permission is the permission required in the application scenario represented by the scenario identifier; if the flag value of the specified flag indicates that a reminder message about permission requests will pop up, or if the query result indicates that the client does not have the target permission, then issue a first notification message, wherein the first notification message is generated using the dialogue content and is used to ask the user whether to enable the target permission; in response to obtaining an instruction to refuse to enable the target permission based on the first notification message, issue a second notification message; wherein, the second notification message is generated using the dialogue content and is used to guide the user to enable the target permission.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 5-7.

Images