User permission management method and device, terminal, electronic equipment and storage medium

Abstract

The invention relates to a user permission management method and device, a terminal, electronic equipment and a storage medium, and the method comprises the steps: under the condition that a user registration request is detected, binding a user account according to a mobile phone number input by a user, and storing the binding relation between the mobile phone number and the user account in an account database, the account database comprises at least one pair of binding relationships; under the condition that the permission request is detected, obtaining a pre-bound target number from an account database according to the identified target account; a target permission bound with the target number in advance is searched in a permission database, the permission database is used for storing the binding relation between the mobile phone number of the unregistered user and permission information, and the permission information is used for indicating that the client is allowed to read related permission data stored in the terminal; and if the target permission is found, feeding back the target permission to the user. The business development efficiency is improved.

Description

Technical Field

[0001] The present application relates to the technical field of intelligent terminals, and in particular to a method, device, terminal, electronic device and storage medium for managing user rights. Background Art

[0002] In the current digital business environment, user rights management is essential to protecting client security and data privacy. However, existing user rights management clients usually configure and assign rights after users complete the registration process. This rights management method may reduce user experience because users may not be able to access the rights or services they are promised immediately after registration, making this approach inflexible in specific marketing activities or business promotions. Current clients are unable to effectively respond to this demand, limiting the efficiency of business development. Summary of the invention

[0003] The present application provides a user rights management method, device, terminal, electronic device and storage medium to solve the problem of low business development efficiency.

[0004] In a first aspect, the present application provides a method for managing user rights, the method comprising:

[0005] In the case of detecting a user registration request, binding the user account according to the mobile phone number input by the user, and storing the binding relationship between the mobile phone number and the user account in an account database, wherein the account database includes at least one pair of binding relationships;

[0006] In case of detecting the permission request, obtaining a pre-bound target number from the account database according to the identified target account;

[0007] Searching in a permission database for a target permission pre-bound to the target number, wherein the permission database is used to store a binding relationship between a mobile phone number of an unregistered user and permission information, and the permission information is used to indicate that the client is allowed to read relevant permission data stored in the terminal;

[0008] If the target permission is found, the target permission is fed back to the user.

[0009] Optionally, before detecting the user registration request, the method further includes:

[0010] Before the user registers, obtain the mobile phone number and expected permissions input by the user, wherein the expected permissions are the relevant permission categories set by the user to allow the client to read the stored in the terminal;

[0011] If the format specification of the mobile phone number is verified and the desired permission belongs to a pre-recorded permission category, the mobile phone number and the desired permission are bound;

[0012] The binding relationship between the mobile phone number and the desired authority is stored in the authority database.

[0013] Optionally, binding a user account according to a mobile phone number input by the user, and storing the binding relationship between the mobile phone number and the user account in an account database includes:

[0014] Verify the format of the mobile phone number entered by the user and query the historical binding record of the mobile phone number;

[0015] If it is determined that the format of the mobile phone number is correct and no historical binding record of the mobile phone number is found, then a user account corresponding to the mobile phone number is created;

[0016] A binding relationship between the mobile phone number and the user account is established, and the binding relationship is stored in an account database.

[0017] Optionally, after querying the historical binding record of the mobile phone number, the method further includes:

[0018] If it is determined according to the historical binding record that the mobile phone number has been bound to a user account, guidance information is fed back to the user, wherein the guidance information is used to help the user resolve binding conflicts and guide the user to complete new account binding.

[0019] Optionally, after searching the target authority pre-bound to the target number in the authority database, the method further includes:

[0020] If the target permission is not found, a prompt message is fed back to the user, wherein the prompt message is used to inform the user that the function requested by the relevant permission cannot be used and provide a method for enabling the permission.

[0021] Optionally, binding the mobile phone number and the expected authority includes: encrypting the expected authority, and binding the encrypted expected authority to the mobile phone number;

[0022] If the target authority is found, feeding back the target authority to the user includes: if the encrypted authority corresponding to the target number is found, decrypting the encrypted authority to restore the original authority, and feeding back the original authority to the user.

[0023] In a second aspect, the present application provides a user rights management device, the device comprising:

[0024] A binding module, configured to bind a user account according to a mobile phone number input by a user when a user registration request is detected, and store the binding relationship between the mobile phone number and the user account in an account database, wherein the account database includes at least one pair of binding relationships;

[0025] an acquisition module, configured to acquire a pre-bound target number from the account database according to the identified target account when a permission request is detected;

[0026] A query module, used to search the target authority pre-bound to the target number in an authority database, wherein the authority database is used to store the binding relationship between the mobile phone number of the unregistered user and the authority information, and the authority information is used to indicate that the client is allowed to read the relevant authority data stored in the terminal;

[0027] The feedback module is used to feed back the target permission to the user if the target permission is found.

[0028] In a third aspect, the present application provides a terminal, the terminal comprising:

[0029] A permission pre-recording module binds the mobile phone number of an unregistered user with permission information and stores the binding relationship in a permission database, wherein the permission information is used to indicate that the client is allowed to read relevant permission data stored in the terminal;

[0030] A user registration module, when a user registration request is detected, binds the user account according to the mobile phone number input by the user, and stores the binding relationship between the mobile phone number and the user account in an account database, wherein the account database includes at least one pair of binding relationships;

[0031] The permission acquisition module, when a permission request is detected, obtains a pre-bound target number from the account database according to the identified target account, and when the target permission bound to the target number is found in the permission database, the target permission is fed back to the user.

[0032] In a fourth aspect, the present application provides an electronic device comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus.

[0033] In a fifth aspect, the present application further provides a computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the user rights management method described in any one of the above items of the present application.

[0034] The above technical solution provided by the embodiment of the present application has the following advantages compared with the prior art: the permission information bound to the user's mobile phone number is determined in advance before the user registers, so that a unique user account is configured for the user's mobile phone number when the user registers. When the user needs to use the permission information, the user's mobile phone number can be determined based on the user account, and the user authority can be determined based on the above binding relationship, ensuring that once the user completes the registration, they can smoothly enjoy the permission services they deserve without having to face long waits or complicated subsequent operations, thereby improving the efficiency of user access rights after registration. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0037] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0038] Figure 1 A schematic diagram of a user rights management client provided in an embodiment of the present application;

[0039] Figure 2 A flowchart of a method for managing user rights provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of a user rights management signaling provided in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of the structure of a user rights management device provided in an embodiment of the present application;

[0042] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0044] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0045] In order to solve the problem mentioned in the background technology, according to one aspect of the embodiments of the present application, an embodiment of user rights management is provided.

[0046] Optionally, in the embodiment of the present application, the above user rights management method can be applied to Figure 1 In the hardware environment composed of the terminal 101 and the database 105 shown in FIG, the terminal 101 and the database 105 are connected via a network. Figure 1 As shown, a database 105 can be set up in the cloud or server to provide data storage services for the terminal 101. The above-mentioned network includes but is not limited to: a wide area network, a metropolitan area network or a local area network. The terminal 101 includes but is not limited to a PC, a mobile phone, a tablet computer, etc. The terminal 101 includes a client. Before the user registers, the client stores the permission information bound to the user's mobile phone number in the permission database, so that when the user registers and uses the client, the permission information corresponding to the user is automatically obtained.

[0047] A method for managing user rights in an embodiment of the present application can be executed by the terminal 101 or by a client.

[0048] The following will be combined with specific implementation methods to describe in detail a method for managing user rights provided in an embodiment of the present application, taking application to a terminal as an example. Figure 2 As shown, the specific steps are as follows:

[0049] Step 201: When a user registration request is detected, the user account is bound according to the mobile phone number input by the user, and the binding relationship between the mobile phone number and the user account is stored in an account database, wherein the account database includes at least one pair of binding relationships;

[0050] Step 202: when a permission request is detected, obtaining a pre-bound target number from an account database according to the identified target account;

[0051] Step 203: searching the target permission pre-bound to the target number in the permission database, wherein the permission database is used to store the binding relationship between the mobile phone number of the unregistered user and the permission information, and the permission information is used to indicate that the client is allowed to read the relevant permission data stored in the terminal;

[0052] Step 204: If the target permission is found, the target permission is fed back to the user.

[0053] The client includes three modules, namely, permission pre-recording module, user registration module and permission acquisition module. The process of this solution is described in detail below in combination with these three modules.

[0054] The permission pre-recording module is used to receive the user's mobile phone number and permission information before the user registers, and establish the association storage between the two in the permission database. The permission database has efficient data storage and retrieval capabilities, and can quickly and accurately store and query the mapping relationship between mobile phone numbers and permission information. That is, the permission database is specifically used to save the association data between the mobile phone numbers of unregistered users and their authorized permission information. These permission information details the specific scope and type of relevant permission data stored in the terminal that the client can read, which means that even new users can immediately obtain certain access rights without waiting for the full registration process to be completed.

[0055] When the user registration module receives a registration request from a user for the client, it automatically starts a process to process the request. First, the user registration module requires the user to provide a valid mobile phone number as a means of verification. Once the user provides the correct mobile phone number, the user registration module will create a new user account and bind this account to the provided mobile phone number. This binding relationship will be recorded in the account database to ensure that each user account corresponds to a unique mobile phone number. The account database stores multiple such binding relationships to support the registration and management of a large number of users.

[0056] When a user attempts to access a function or service that requires specific permissions, the permission acquisition module will first identify the user's specific target account, and then retrieve the mobile phone number associated with the target account from the account database, that is, the target number. This step is part of the permission verification process and is intended to confirm the identity of the actual user who initiated the permission request. Once the user's identity is determined, the permission acquisition module will then search the permission database for specific permission information corresponding to the user's mobile phone number. If permission information matching the user's mobile phone number is found in the permission database, the permission acquisition module will feed back this permission information to the user, which allows the user to immediately understand the scope of permissions they currently have and perform corresponding operations accordingly. In this way, after completing the registration process, users can immediately obtain and use the specific permissions they are authorized to, without waiting for additional approval or configuration processes.

[0057] Optionally, the permission acquisition module identifies the target account of the user in a manner including but not limited to: 1. Authenticating the user: This is usually done by requiring the user to enter a username and password, using two-factor authentication, or confirming the user's identity through a logged-in user session. 2. Session management: After the user successfully logs in, the client creates a user session, which is a server-side record that contains the user's identity information and login status. When a user makes a permission request, the client can determine which user made the request by viewing the currently active user session.

[0058] In this application, the permission information bound to the user's mobile phone number is determined in advance before the user registers, so that a unique user account is configured for the user's mobile phone number when the user registers. When the user needs to use the permission information, the user's mobile phone number can be determined based on the user account, and the user permissions can be determined based on the above binding relationship. This ensures that once the user completes registration, they can smoothly enjoy the permission services they deserve without having to face long waits or complicated subsequent operations, thereby improving the efficiency of user access rights after registration.

[0059] In addition, the instant permission feedback mechanism not only improves the user's operating efficiency, but also enhances the transparency of the client, making users more trusting of the client, optimizing the user experience, and improving the user stickiness of the client. This application uses strict permission management to ensure that only authorized users can use specific functions, thereby improving the security of the client.

[0060] As an optional implementation, after searching the target permission pre-bound to the target number in the permission database, the method also includes: if the target permission is not found, a prompt message is fed back to the user, wherein the prompt message is used to inform the user that the function requested by the relevant permission cannot be used, and a method for enabling the permission is provided.

[0061] If the client fails to find the permission information bound to the user's mobile phone number in the permission database, the client will generate a prompt message to clearly inform the user that the requested function cannot be used at present because the relevant permission is not found, and the generated prompt message will be fed back to the user to ensure that the user can understand the current status in a timely manner.

[0062] In the prompt message, the client will also provide specific steps or methods to guide users on how to enable the required permissions. These steps may include but are not limited to: guiding users to open the application settings page of the mobile phone and find the permission settings of the current application; detailed instructions on how to manually enable the required permissions in the permission settings, such as camera permissions, storage permissions, etc.; if users encounter difficulties in the process of enabling permissions, customer service contact information can be provided to help users solve the problem.

[0063] For example, a user tries to use a function that requires camera permission in an application. The client searches the permission database for permission information pre-bound to the user's mobile number. The client fails to find the camera permission bound to the user's mobile number, and the client generates a prompt message. The client displays the generated prompt message to the user to ensure that the user can see and understand the current status. The user manually enters the application settings and turns on camera permission according to the steps in the prompt message.

[0064] The content of the prompt message is as follows: The camera function cannot be used at present because your account has not granted camera permission. Please follow the steps below to enable camera permission: 1. Open the phone settings; 2. Enter the application management or application settings; 3. Find this application and click to enter the application details; 4. Select permission settings; 5. Enable camera permission.

[0065] This application can promptly inform users that the requested function is currently unavailable, avoiding long waits or repeated attempts at invalid operations, helping users quickly resolve problems, and improving user operational efficiency and satisfaction.

[0066] As an optional implementation, before detecting the user registration request, the method further includes the following steps:

[0067] Step S11: Before the user registers, the mobile phone number and expected authority input by the user are obtained, wherein the expected authority is a related authority category set by the user to allow the client to read the stored information in the terminal.

[0068] Before the user starts the registration process, the user operates through the input interface provided by the client, guiding the user to enter their mobile phone number and desired permissions, which can be an entry designed specifically for unregistered users. The desired permissions here refer to the operations that the user wants the client to be able to perform on the terminal device, such as reading storage permissions, accessing camera permissions, etc. Users can specify the permission categories they want to grant by checking or selecting.

[0069] This application allows users to select permissions in advance, giving users the opportunity to understand and control their privacy settings before registration, enhancing users' trust in the client. In addition, users can complete some configuration work before registration, making the registration process smoother and faster.

[0070] Step S12: If the format of the mobile phone number is verified to be standard and the desired permission belongs to the pre-recorded permission category, the mobile phone number and the desired permission are bound.

[0071] After the client receives the information entered by the user, the permission pre-recording module immediately starts to perform verification operations. For example, it will check whether the mobile phone number conforms to the prescribed format specifications, including the correct number of digits and regional coding rules. At the same time, the permissions requested by the user will also be reviewed to ensure that all requests are compliant and supported by the client.

[0072] Mobile phone number format verification includes but is not limited to: checking whether the digit length of the mobile phone number meets the standard, verifying whether the mobile phone number meets the coding rules of a specific region (such as Chinese mobile phone numbers usually start with 1 and have a total of 11 digits), or using regular expressions or other methods to verify the general format of the mobile phone number.

[0073] Expected permission compliance verification includes but is not limited to: comparing the permissions requested by the user with the client's preset permission list to ensure that all requested permissions are within the permitted range; checking whether there are illegal or unreasonable permission requests, such as attempts to obtain control permissions at the operating client level.

[0074] If the mobile phone number format and expected permissions are both compliant, the permission pre-recording module will associate the permissions entered by the user with the corresponding mobile phone number, and store this association information in the permission database. The permission database is a temporary database. The temporary database is a storage area specially set up within the application for temporarily storing data related to the permissions of unregistered users, so that the formal granting of permissions can be performed later after the user registration is completed.

[0075] If the mobile phone number format is incorrect or the expected permissions are not compliant, the permission pre-recording module will send a prompt message to the user, clearly informing the user that there is an error in the information entered, and prompting the user to re-enter the correct mobile phone number and compliant permission information.

[0076] A strict verification mechanism can effectively prevent malicious users from using illegal mobile phone numbers or permission requests to launch attacks. In addition, it ensures that the stored mobile phone numbers and permission information are accurate and valid, reducing errors in subsequent processing.

[0077] Step S13: storing the binding relationship between the mobile phone number and the desired authority in the authority database.

[0078] If both the mobile phone number and the desired permission are verified, the permission pre-recording module will bind the two and store the binding relationship in the permission database. The process of establishing the associated storage is to create a record in the permission database, which contains the mapping relationship between the mobile phone number and the desired permission. Among them, the permission database should have efficient data storage and retrieval capabilities to support fast read and write operations.

[0079] Through the above steps, it is ensured that only strictly verified user information and permission requests are recorded and processed, providing a basis for subsequent user registration and permission allocation.

[0080] As an optional implementation, binding a user account according to a mobile phone number input by a user and storing the binding relationship between the mobile phone number and the user account in an account database includes: performing format verification on the mobile phone number input by the user and querying the historical binding record of the mobile phone number; if it is determined that the format of the mobile phone number is correct and no historical binding record of the mobile phone number is found, creating a user account corresponding to the mobile phone number; establishing a binding relationship between the mobile phone number and the user account, and storing the binding relationship in the account database.

[0081] Users enter their mobile phone numbers through the registration process interface provided by the application to create a new user account or associate an existing account (if the relevant function is supported). At this stage, users need to ensure that the mobile phone number they enter is accurate, as this will be the basis for subsequent verification and binding.

[0083] After receiving the mobile phone number entered by the user, the user registration module will perform the following verification operations: Mobile phone number compliance verification: Check whether the length of the mobile phone number meets the standard (such as the mobile phone number is 11 digits), verify whether the mobile phone number complies with the coding rules of a specific region (such as mobile phone numbers usually start with 1), or ensure that the mobile phone number contains only numbers and no other special characters or letters.

[0084] Historical binding record query: Check whether the mobile phone number has been bound to other accounts in the client. This step is to avoid account conflicts and ensure that each mobile phone number can only be bound to one user account.

[0085] If the mobile phone number is both compliant and has not been bound in the client, the user registration module will create a new user account and bind the mobile phone number to the newly created user account. This binding process usually involves establishing a corresponding relationship record between the mobile phone number and the user account in the user account database of the client to ensure that the two-way data can be checked. The binding relationship between the mobile phone number and the user account is then stored in the account database to ensure that the corresponding user account can be found through the mobile phone number in the future, and the bound mobile phone number can also be obtained through the user account.

[0086] If the mobile phone number is not compliant, the user will be prompted that there is a problem with the mobile phone number and will be told to re-enter the correct mobile phone number; if the mobile phone number has been bound, the user will be prompted to handle the binding conflict based on the specific situation, such as providing relevant instructions such as retrieving the password and releasing the original binding, so that the user can successfully complete the registration process and ensure that the mobile phone number is bound to the correct account.

[0087] As an optional implementation method, binding a mobile phone number and expected permissions includes: encrypting the expected permissions and binding the encrypted expected permissions to the mobile phone number; if the target permissions are found, feeding back the target permissions to the user includes: if the encrypted permissions corresponding to the target number are found, decrypting the encrypted permissions to restore the original permissions, and feeding back the original permissions to the user.

[0088] The user enters his or her mobile phone number and desired permission information through the registration process interface provided by the client. The desired permissions may include read storage permissions, access camera permissions, etc. The permission pre-recording module verifies the format of the received mobile phone number to ensure that it conforms to the standard format, and verifies the compliance of the permissions requested by the user to ensure that the requested permissions are within the scope of permissions defined by the client.

[0089] If both the mobile phone number and the expected permission are verified, the permission pre-recording module will encrypt the expected permission. The encryption process can use industry-standard encryption algorithms, such as AES (Advanced Encryption Standard), to ensure the security of the permission information. The permission pre-recording module binds the encrypted expected permission to the mobile phone number entered by the user. This binding relationship will be stored in the permission database to ensure that the corresponding permission information can be queried by mobile phone number later.

[0090] When a user uses the client and needs to obtain permission, the permission acquisition module searches the permission database for the encrypted permission corresponding to the user's target number, decrypts it using a decryption algorithm corresponding to the encryption algorithm, and then feeds back the decrypted original permission to the user.

[0091] For example, assuming that a user wants to use the camera function through an application, the specific steps are as follows: the user enters the mobile phone number: aa in the registration interface and selects the desired permission: camera permission. The client verifies the format of the mobile phone number aa and confirms that it conforms to the standard format. It verifies whether the camera permission is within the permission range defined by the client and confirms that it is compliant. The permission pre-recording module uses the AES algorithm to encrypt the camera permission and generates encrypted permission information: encrypted_camera_permission. The permission pre-recording module binds aa and encrypted_camera_permission and stores this binding relationship in the permission database.

[0092] When a user tries to use a function that requires camera permission in the client, the permission acquisition module searches the permission database for permission information pre-bound to the user's mobile phone number aa. If the permission acquisition module finds the encrypted permission encrypted_camera_permission corresponding to aa, the permission acquisition module decrypts the encrypted permission and restores the original camera permission. The permission acquisition module feeds back the decrypted original camera permission to the user, allowing the user to use the camera function normally. After the application receives the camera permission, the user can use the camera function normally, such as taking photos.

[0093] This application ensures the security of permission information during storage and transmission by encrypting it, preventing unauthorized access and tampering. The client can promptly inform the user of the current permission status, preventing the user from repeatedly trying invalid operations without permission.

[0094] Based on the same technical concept, the present application provides a user rights management signaling diagram, such as Figure 3 As shown, the content of the program is described in three stages:

[0095] 1. User unregistered stage.

[0096] The permission pre-recording module guides the user to enter their mobile phone number and desired permissions in a specific input interface, and then verifies the format of the mobile phone number and the compliance of permissions. If the mobile phone number format is correct and the permissions are compliant (compliance is in Figure 3 alt or legal is used in the text box), then the mobile phone number and the expected permission are bound and stored in the permission database (temporary database). If the mobile phone number format is incorrect or the permission is not compliant, an error message is prompted to the user to allow the user to adjust the input mobile phone number or expected permission.

[0097] 2. User registration stage.

[0098] The user registers and enters the mobile phone number. The user registration module verifies the format of the mobile phone number and whether it has been bound to the user account. If the mobile phone number format is correct and has not been bound to an account, the user registration module binds a new user account to the mobile phone number and stores the binding relationship between the mobile phone number and the user account in the account database to ensure that the data can be checked in both directions. If the mobile phone number format is incorrect or has been bound to an account, the user is prompted to modify the mobile phone number, or the user is guided to handle the binding conflict so that the user can successfully complete the registration process and ensure that the mobile phone number is bound to the correct account.

[0099] 3. User obtains permission stage.

[0100] When a user tries to access a function or service that requires specific permissions, the permission acquisition module identifies the user account, searches the account database for the mobile phone number bound to the user account, and then queries the permission database for the user permissions bound to the mobile phone number. If the user permissions are found, feedback is provided to the user. If the user permissions are not found, a "no permission information" prompt is displayed.

[0101] Based on the same technical concept, this application provides a user rights management process step, including the following contents:

[0102] (1) Permission pre-recording mechanism based on mobile phone numbers.

[0103] 1. Information reception and verification.

[0104] A special permission pre-recording module is designed to receive the mobile phone number and permission information entered by the user. During the receiving process, the format of the mobile phone number is strictly verified, including checking the length of the number, the coding format of the specific area, etc., to ensure the validity of the mobile phone number. At the same time, the user's requested permissions are checked for compliance to ensure that the requested permissions are within the scope of permissions defined by the client, to avoid illegal or unreasonable permission requests being recorded.

[0105] 2. Associated storage.

[0106] For verified mobile phone numbers and permission information, an association is established between the two in a temporary database. This temporary database has efficient data storage and retrieval capabilities, and can quickly and accurately store and query the mapping relationship between permission information and mobile phone numbers. The storage process uses secure data encryption technology to encrypt and store permission information to prevent information leakage and ensure user data security.

[0107] (2) User registration and mobile phone number binding process.

[0108] 1. Registration information processing.

[0109] The user registration module is responsible for processing user registration requests. When a user enters a mobile phone number for registration, the mobile phone number is verified for compliance again to confirm that it meets the format requirements and has no obvious errors. At the same time, it is checked whether the mobile phone number has been bound by other users to avoid account conflicts.

[0110] 2. Binding operation.

[0111] If the mobile phone number is compliant and has not been bound, the client will establish a binding relationship between the mobile phone number and the newly created user account in the user account database. This binding relationship is bidirectional, and the corresponding user account can be found through the mobile phone number, and the bound mobile phone number can be obtained through the user account, providing an accurate association basis for the subsequent permission acquisition process. If the mobile phone number is already bound or the account is not compliant, the client will send a corresponding prompt to the user to guide the user to complete the correct registration operation.

[0112] (3) Permission acquisition process

[0113] 1. Permission query trigger.

[0114] When the user requests permission after completing registration, the permission acquisition module starts. The module first obtains the bound mobile phone number from the user account information.

[0115] 2. Permission retrieval and return.

[0116] According to the obtained mobile phone number, the previously recorded permission information is queried in the temporary database. If the corresponding permission information is found, it is decrypted. The decryption algorithm matches the encryption algorithm when the permission is pre-recorded to ensure accurate restoration of the permission content. Finally, the decrypted permission information is returned to the user so that the user can use the corresponding function normally. If the permission information is not found, the user is prompted that there is no permission, and the user may need to further apply or check the configuration.

[0117] Through this series of steps, the pre-configuration and acquisition of permissions associated with unregistered users' mobile phone numbers are achieved, which effectively solves the business problem of needing to configure permissions before user registration, improves the flexibility of the client, and improves the user experience.

[0118] This application provides a user rights management device, such as Figure 4 As shown, the device comprises:

[0119] The binding module 401 is used to bind the user account according to the mobile phone number input by the user when a user registration request is detected, and store the binding relationship between the mobile phone number and the user account in the account database, wherein the account database includes at least one pair of binding relationships;

[0120] The acquisition module 402 is used to acquire a pre-bound target number from an account database according to the identified target account when a permission request is detected;

[0121] A query module 403 is used to search for a target permission pre-bound to a target number in a permission database, wherein the permission database is used to store a binding relationship between a mobile phone number of an unregistered user and permission information, and the permission information is used to indicate that the client is allowed to read relevant permission data stored in the terminal;

[0122] Feedback module 404 is used to feed back the target permission to the user if the target permission is found.

[0123] Optionally, the device is also used for:

[0124] Before the user registers, obtain the mobile phone number and expected permissions input by the user, where the expected permissions are the relevant permission categories set by the user to allow the client to read the storage in the terminal;

[0125] If the format of the verified mobile phone number is standard and the expected permission belongs to the pre-recorded permission category, the mobile phone number and the expected permission are bound;

[0126] The binding relationship between the mobile phone number and the desired permission is stored in the permission database.

[0127] Optionally, the binding module 401 is used to:

[0128] Verify the format of the mobile phone number entered by the user and query the historical binding records of the mobile phone number;

[0129] If the format of the mobile phone number is confirmed to be correct and no historical binding records of the mobile phone number are found, a user account corresponding to the mobile phone number is created;

[0130] Establish a binding relationship between the mobile phone number and the user account, and store the binding relationship in the account database.

[0131] Optionally, the device is also used for:

[0132] If it is determined based on historical binding records that the mobile phone number has been bound to a user account, guidance information is fed back to the user, wherein the guidance information is used to help the user resolve binding conflicts and guide the user to complete new account binding.

[0133] Optionally, the device is also used for:

[0134] If the target permission is not found, a prompt message is fed back to the user, wherein the prompt message is used to inform the user that the function requested by the relevant permission cannot be used and provide a method to enable the permission.

[0135] Optionally, the desired permission is encrypted and bound to the mobile phone number; if the encrypted permission corresponding to the target number is found, the encrypted permission is decrypted to restore the original permission, and the original permission is fed back to the user.

[0136] like Figure 5 As shown, an embodiment of the present application provides an electronic device, including a processor 501, a communication interface 502, a memory 503 and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0137] The memory 503 is used to store computer programs.

[0138] In one embodiment of the present application, the processor 501 is used to implement the user authority management method provided by any one of the aforementioned method embodiments when executing the program stored in the memory 503.

[0139] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the user rights management method provided in any of the aforementioned method embodiments are implemented.

[0140] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0141] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0142] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0143] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for managing user rights, characterized in that: The method comprises: In the case of detecting a user registration request, binding the user account according to the mobile phone number input by the user, and storing the binding relationship between the mobile phone number and the user account in an account database, wherein the account database includes at least one pair of binding relationships; In case of detecting the permission request, obtaining a pre-bound target number from the account database according to the identified target account; Searching for the target permission pre-bound to the target number in a permission database, wherein the permission database is used to store the binding relationship between the mobile phone number of the unregistered user and the permission information, and the permission information is used to indicate that the client is allowed to read the relevant permission data stored in the terminal; If the target permission is found, the target permission is fed back to the user.

2. The method according to claim 1, characterized in that Before detecting a user registration request, the method further includes: Before the user registers, obtain the mobile phone number and expected permissions input by the user, wherein the expected permissions are the relevant permission categories set by the user to allow the client to read the stored in the terminal; If the format specification of the mobile phone number is verified and the desired permission belongs to a pre-recorded permission category, the mobile phone number and the desired permission are bound; The binding relationship between the mobile phone number and the desired authority is stored in the authority database.

3. The method according to claim 1, characterized in that Binding a user account according to a mobile phone number input by a user, and storing the binding relationship between the mobile phone number and the user account in an account database includes: Verify the format of the mobile phone number entered by the user and query the historical binding record of the mobile phone number; If it is determined that the format of the mobile phone number is correct and no historical binding record of the mobile phone number is found, then a user account corresponding to the mobile phone number is created; A binding relationship between the mobile phone number and the user account is established, and the binding relationship is stored in an account database.

4. The method according to claim 3, characterized in that After querying the historical binding record of the mobile phone number, the method further includes: If it is determined according to the historical binding record that the mobile phone number has been bound to a user account, guidance information is fed back to the user, wherein the guidance information is used to help the user resolve binding conflicts and guide the user to complete new account binding.

5. The method according to claim 1, characterized in that After searching the target authority pre-bound to the target number in the authority database, the method further includes: If the target permission is not found, a prompt message is fed back to the user, wherein the prompt message is used to inform the user that the function requested by the relevant permission cannot be used and provide a method for enabling the permission.

6. The method according to claim 2, characterized in that Binding the mobile phone number and the desired authority includes: encrypting the desired authority and binding the encrypted desired authority to the mobile phone number; If the target authority is found, feeding back the target authority to the user includes: if the encrypted authority corresponding to the target number is found, decrypting the encrypted authority to restore the original authority, and feeding back the original authority to the user.

7. A user rights management device, characterized in that: The device comprises: A binding module, configured to bind a user account according to a mobile phone number input by a user when a user registration request is detected, and store the binding relationship between the mobile phone number and the user account in an account database, wherein the account database includes at least one pair of binding relationships; an acquisition module, configured to acquire a pre-bound target number from the account database according to the identified target account when a permission request is detected; A query module, used to search the target authority pre-bound to the target number in an authority database, wherein the authority database is used to store the binding relationship between the mobile phone number of the unregistered user and the authority information, and the authority information is used to indicate that the client is allowed to read the relevant authority data stored in the terminal; The feedback module is used to feed back the target permission to the user if the target permission is found.

8. A terminal, characterized in that: The terminal comprises: A permission pre-recording module binds the mobile phone number of an unregistered user with permission information and stores the binding relationship in a permission database, wherein the permission information is used to indicate that the client is allowed to read relevant permission data stored in the terminal; A user registration module, when a user registration request is detected, binds the user account according to the mobile phone number input by the user, and stores the binding relationship between the mobile phone number and the user account in an account database, wherein the account database includes at least one pair of binding relationships; The permission acquisition module, when a permission request is detected, obtains a pre-bound target number from the account database according to the identified target account, and when the target permission bound to the target number is found in the permission database, the target permission is fed back to the user.

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, for implementing any of the methods described in claims 1-6 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images