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

Abstract

The present application provides a permission management method, apparatus, electronic device and storage medium, the method comprising: applying to an electronic device, a target role is logged in on the electronic device, and a first role identifier of the target role is obtained; a first device identifier of the electronic device is obtained, the first device identifier at least characterizing the device type of the electronic device; in a permission group, searching for permissions corresponding to the first role identifier and the first device identifier, if a first target permission corresponding to the first role identifier and the first device identifier is found, determining that the target role has the first target permission on the electronic device, so that the target role can perform operations corresponding to the first target permission on the electronic device; wherein the permission group contains one or more groups of permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier, respectively.

Description

Technical Field

[0001] The present application relates to the field of information management technology, and in particular to a permission management method, device, electronic device and storage medium. Background Art

[0002] In the authority management of an information system, users are usually assigned corresponding roles so that they have the authority corresponding to the role in the information system, and can then perform operations corresponding to the authority in the information system.

[0003] However, in the current information system, for the management of user rights, a user can only have one set of roles, and thus can only be assigned one set of rights. Therefore, there is a problem of relatively simple rights allocation. Summary of the invention

[0004] In view of this, the present application provides a method for rights management and control, which is used to solve the problem of relatively simple allocation of user rights in the information system.

[0005] The present application provides a permission management method, which is applied to an electronic device, where a target role is logged in to the electronic device, and the method includes:

[0006] Acquire a first device identifier of the electronic device, where the first device identifier at least represents a device type of the electronic device;

[0007] Obtaining a first role identifier of the target role;

[0008] In the permission group, searching for a permission corresponding to the first role identifier and the first device identifier, and if a first target permission corresponding to the first role identifier and the first device identifier is found, determining that the target role has the first target permission on the electronic device, so that the target role can perform an operation corresponding to the first target permission on the electronic device;

[0009] The permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier.

[0010] In the above method, preferably, searching the permission corresponding to the first role identifier and the first device identifier in the permission group includes:

[0011] Get the first permission in the permission group as the current permission;

[0012] Obtaining a preset role identifier and a preset device identifier corresponding to the current permission;

[0013] Searching among the preset role identifiers corresponding to the current authority whether the first role identifier is included;

[0014] If the first role identifier is found in the preset role identifiers corresponding to the current authority, obtaining the preset device identifier corresponding to the first role identifier according to the preset device identifier corresponding to the current authority;

[0015] searching among preset device identifiers corresponding to the first role identifier whether the first device identifier is included;

[0016] If the first device identifier is found in the preset device identifiers corresponding to the first role identifier, determining that the current permission is a first target permission corresponding to the first role identifier and the first device identifier;

[0017] If the first role identifier is not found in the preset role identifiers corresponding to the current permission, or if the first device identifier is not found in the preset device identifiers corresponding to the first role identifier, obtain the next permission in the permission group as the new current permission, and return to execute the step of obtaining the preset role identifier and preset device identifier corresponding to the current permission.

[0018] In the above method, preferably, searching the permission corresponding to the first role identifier and the first device identifier in the permission group includes:

[0019] Get the first permission in the permission group as the current permission;

[0020] Obtaining a preset role identifier and a preset device identifier corresponding to the current permission;

[0021] Searching among preset device identifiers corresponding to the current permission whether the first device identifier is included;

[0022] If the first device identifier is found in the preset device identifiers corresponding to the current authority, obtaining the preset role identifier corresponding to the first device identifier according to the preset role identifier corresponding to the current authority;

[0023] Searching among preset role identifiers corresponding to the first device identifier whether the first role identifier is included;

[0024] If the first device identifier is found in the preset role identifiers corresponding to the first device identifier, determining that the current permission is a first target permission corresponding to the first role identifier and the first device identifier;

[0025] If the first device identifier is not found in the preset device identifiers corresponding to the current authority, or if the first role identifier is not found in the preset role identifiers corresponding to the first device identifier, obtain the next permission in the permission group as the new current permission, and return to execute the step of obtaining the preset role identifier and preset device identifier corresponding to the current authority.

[0026] The above method, preferably, after obtaining the first device identification of the electronic device and before obtaining the first role identification of the target role, further includes:

[0027] Determining whether the target role has a second role identifier, where the second role identifier is different from the first role identifier;

[0028] If the target role has the second role identifier, searching the permission corresponding to the second role identifier and the first device identifier in the permission group, and if a second target permission corresponding to the second role identifier and the first device identifier is found, determining that the target role has the second target permission on the electronic device, so that the target role can perform an operation corresponding to the second target permission on the electronic device, and the second target permission is a different permission from the first target permission;

[0029] If the target role does not have the second role identifier, or if the permission corresponding to the second role identifier and the first device identifier is not found in the permission group, the step of obtaining the first role identifier of the target role is performed.

[0030] In the above method, preferably, the first target permission includes at least one sub-permission, and each sub-permission in the first target permission corresponds to at least one preset role identifier and at least one preset device identifier;

[0031] After determining that the target role has the first target permission on the electronic device, the method further includes:

[0032] Among all sub-rights in the first target permission, all first target sub-rights corresponding to the first role identifier and the first device identifier are acquired, so that the target role can perform operations corresponding to the first target sub-rights on the electronic device.

[0033] In the above method, preferably, the second target permission includes at least one sub-permission, and each sub-permission in the second target permission corresponds to at least one preset role identifier and at least one preset device identifier;

[0034] After determining that the target role has the second target permission on the electronic device, the method further includes:

[0035] Among all sub-rights in the second target permission, all second target sub-rights corresponding to the second role identifier and the first device identifier are acquired, so that the target role can perform operations corresponding to the second target sub-rights on the electronic device.

[0036] The present application also provides a rights management device, which is applied to an electronic device, where a target role is logged in to the electronic device, and the method includes:

[0037] A first device identification acquiring unit, configured to acquire a first device identification of the electronic device, wherein the first device identification at least represents a device type of the electronic device;

[0038] A first role identification obtaining unit, used to obtain a first role identification of the target role;

[0039] The first permission search unit is used to search for the permission corresponding to the first role identifier and the first device identifier in the permission group, and if the first target permission corresponding to the first role identifier and the first device identifier is found, determine that the target role has the first target permission on the electronic device, so that the target role can perform the operation corresponding to the first target permission on the electronic device; wherein the permission group contains one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier.

[0040] The present application also provides an electronic device, on which a target role is logged, including:

[0041] A memory, used to store a computer program and data generated by the execution of the computer program;

[0042] A processor is used to execute the computer program to achieve: obtaining a first device identifier of the electronic device, the first device identifier at least representing the device type of the electronic device; obtaining a first role identifier of the target role; searching for permissions corresponding to the first role identifier and the first device identifier in a permission group, and if a first target permission corresponding to the first role identifier and the first device identifier is found, determining that the target role has the first target permission on the electronic device, so that the target role can perform operations corresponding to the first target permission on the electronic device; wherein the permission group contains one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier.

[0043] The present application also provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the rights management method as described in any one of claims 1 to 7 are implemented.

[0044] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the various steps of the rights management method as described in any one of claims 1 to 7.

[0045] It can be seen from the above technical solution that the present application provides a permission management method, in which, when a target role is logged in on an electronic device, the first device identification of the electronic device and the first role identification of the target role are obtained, and then the first target permission corresponding to the first role identification and the device identification of the electronic device is found from the permission group. Based on this, in the present application, the device identification of the electronic device also participates in the permission allocation of the target role, and different permissions will be allocated to the user according to the different device types of the electronic device logged in, avoiding the problem of relatively single permission allocation. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0047] Figure 1 A flowchart of a method for implementing a rights management method provided in Example 1 of the present application;

[0048] Figure 2 A partial implementation flow chart of a rights management method provided in Example 1 of the present application;

[0049] Figure 3 A partial implementation flow chart of a rights management method provided in Example 1 of the present application;

[0050] Figure 4 Another implementation flow chart of a rights management method provided in Example 1 of the present application;

[0051] Figure 5 A partial implementation flow chart of a rights management method provided in Example 1 of the present application;

[0052] Figure 6 A flowchart of another implementation of a permission management method provided in Example 1 of the present application;

[0053] Figure 7 A flowchart of another implementation of a permission management method provided in Example 1 of the present application;

[0054] Figure 8 A schematic diagram of the structure of a rights management device provided in Embodiment 2 of the present application;

[0055] Fig. 9 Another structural diagram of a rights management device provided in Embodiment 2 of the present application;

[0056] Fig.10 A schematic diagram of another structure of a rights management device provided in the second embodiment of the present application;

[0057] Fig.11 A schematic diagram of another structure of a rights management device provided in the second embodiment of the present application;

[0058] Fig.12 A schematic diagram of the structure of an electronic device provided in Embodiment 3 of the present application;

[0059] Fig.13 This is an overall implementation structure diagram of a menu permission management method that supports permission differences in multiple scenarios for this application;

[0060] Fig.14 A flowchart for implementing a recursive method in a menu permission management method that supports permission differences in multiple scenarios in this application;

[0061] Fig.15 Another implementation flowchart of a recursive method in a menu permission management method that supports permission differences in multiple scenarios in this application. DETAILED DESCRIPTION

[0062] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0063] refer to Figure 1 As shown, it is a flowchart of a method for implementing a rights management method provided in the first embodiment of the present application. The method can be applied to applications or devices for specific users, such as mobile phones, tablet computers, personal computers (PCs), televisions and other electronic devices or applications installed in electronic devices. This embodiment is mainly used to solve the problem of relatively simple allocation of user rights in information systems.

[0064] Specifically, the method in this embodiment may include the following steps:

[0065] Step 101: Obtain a first device identification of an electronic device.

[0066] The first device identifier at least represents the device type of the electronic device. Specifically, the device type of the electronic device can be: mobile phone, PC, tablet computer, TV, etc. The device type of the user login device can be obtained by obtaining the browser's user agent UA (UserAgent).

[0067] For example, taking a mobile phone with a browser installed as an example, obtain the UA of the browser. If the UA contains iphone, it can be determined that the device type of the login device used by the user is a mobile phone.

[0068] For another example, taking a computer with a browser installed as an example, obtain the UA of the browser. If the UA contains Windows, then it can be determined that the device type of the login device used by the user is a PC.

[0069] Step S102: Obtain the first role identifier of the target role;

[0070] The first role identifier is the role identifier carried by the target role.

[0071] In a specific implementation, in this embodiment, the target role can be logged in in the electronic device to obtain the first role identifier from the role code of the target role. Each target role has its own unique role code, and the role code contains the first role identifier of the target role. The role code can be a string composed of numbers and / or letters, and a segment of characters in the role code is intercepted as the first role identifier. By assigning the target role to the user, the user has the role code of the target role and the first role identifier contained in the role code, and the corresponding permissions are assigned to the user accordingly. Accordingly, the user can perform corresponding operations on the electronic device according to the assigned permissions.

[0072] For example, taking the user's permission allocation on the mobile phone as an example, the user's user number is 1012345678, and the first two characters "10" of the user number are intercepted as the user's role. After that, the corresponding permissions are matched for the user according to the user's role. Based on this, the user can perform corresponding operations on the mobile phone according to the assigned permissions.

[0073] It should be noted that the target role can be a target role logged in the user system of the electronic device, or the target role can be a target role logged in the user system of a certain application in the electronic device. Login is performed through a login interface in the electronic device or a login interface in an application in the electronic device.

[0074] In addition, the first role identification of the target character can also be obtained by other means, such as, after logging in to the target character in the electronic device, uploading the role code corresponding to the target character to the corresponding server, so that the server can query the corresponding first role identification according to the role code corresponding to the target character, and return the first role identification to the electronic device.

[0075] Step S103: Whether the first target permission corresponding to the first role identifier and the first device identifier is found in the permission group.

[0076] If the first target permission corresponding to the first role identifier and the first device identifier is found, step S104 is executed. If the permission corresponding to the first role identifier and the first device identifier is not found, it can be determined that the target role does not have any permission on the electronic device, and the current process is terminated at this time, that is, there is no permission corresponding to the first role identifier and the first device identifier in the permission group, and the user cannot perform any operation in the electronic device.

[0077] The permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier.

[0078] In a specific implementation, the preset role identifier and preset device identifier corresponding to each permission in the permission group can be compared with the first role identifier and the first device identifier, that is, according to the order between the permissions in the permission group, it is determined in turn whether each permission corresponds to the first role identifier and the first device identifier. If it is determined that there is a first target permission corresponding to the first role identifier and the first device identifier, then it can be determined that the target role has the first target permission on the electronic device. For example: in the permission group, the first permission is obtained as the current permission, and the preset role identifier and preset device identifier corresponding to the current permission are obtained; find out whether the preset role identifier and preset device identifier corresponding to the current permission correspond to the first role identifier and the first device identifier; if so, determine that the current permission is the first target permission corresponding to the target role; if not, obtain the next permission in the permission group as the new current permission, and obtain the preset role identifier and preset device identifier corresponding to the current permission, and so on, until the first target permission corresponding to the first role identifier and the first device identifier is found.

[0079] Step S104: Determine whether the target role has a first target permission on the electronic device, so that the target role can perform an operation corresponding to the first target permission on the electronic device.

[0080] In a specific implementation, the first target permission in this embodiment may be a set of functional permissions, and the functional permissions corresponding to the first target permission are open to the target role in the electronic device, so that the target role can perform corresponding functional operations on the electronic device according to the first target permission. Accordingly, the user assigned to the target role can perform corresponding functional operations on the electronic device according to the first target permission.

[0081] It can be seen from the above technical scheme that in a permission management method provided in Example 1 of the present application, when a target role is logged in on an electronic device, the first device identifier of the electronic device and the first role identifier of the target role are obtained, and then the first target permission corresponding to the first role identifier and the device identifier of the electronic device is found from the permission group. Based on this, in this embodiment, the device identifier of the electronic device also participates in the permission allocation of the target role, and different permissions will be allocated to the user according to the device type of the logged-in electronic device, thereby avoiding the problem of relatively single permission allocation for users.

[0082] Based on Figure 1 In the specific implementation, step S103 can be implemented in the following ways: Figure 2 As shown:

[0083] Step S201: Obtain the first permission in the permission group as the current permission.

[0084] In a specific implementation, the permission group in this embodiment can be embodied in the form of a permission table, as shown in Table 1:

[0085] Table 1 Permission table

[0086] Permission 1 Permission code 1 Permission 2 Permission code 2 Permissions Permission code n

[0087] Each row in the permission table corresponds to a permission and its corresponding permission code. For example, in permission table 1, "permission 1" corresponds to "permission code 1"; "permission 2" corresponds to "permission code 2".

[0088] The permission code can be represented by a string consisting of one or more digits and / or letters, such as a decimal number, a hexadecimal number, etc. Each digit in the string corresponds to a role ID, such as the first digit in the string is "Role 1", the second digit is "Role 2", and so on. Each additional digit in the string adds a role ID. In other words, if you need to set a new role ID, you only need to add a new digit to the permission code.

[0089] In a specific implementation, this embodiment can obtain a permission in the permission table as the current permission through a preset reading method, such as reading the permission table in a top-down order to obtain the first permission in the permission table as the current permission, or randomly obtaining a permission in the permission table as the current permission, and so on.

[0090] Get the value of the digit corresponding to a role ID in the permission code, convert the value to a binary number, and each digit in the binary number corresponds to a device ID, such as: the last digit corresponds to "mobile phone", the second last digit corresponds to "PC", and so on. The number of digits in the binary number corresponds to the number of device IDs. In other words, if you need to increase the number of device IDs, you only need to increase the number of digits in the binary number. For example, the value of a digit in a permission code is 3, which is 11 after conversion to binary, so it can have up to 2 device IDs at the same time; for another example, the value of a digit in a permission code is 7, which is 111 after conversion to binary, so it can have up to 3 device IDs at the same time. By analogy, the more digits in a binary number, the more device IDs it has.

[0091] Step S202: Obtaining a preset role identifier and a preset device identifier corresponding to the current authority.

[0092] Among them, the preset role identifier corresponds to the current authority, and one authority corresponds to at least one preset role identifier; the preset device identifier corresponds to the preset role identifier, and each preset role identifier corresponds to at least one preset device identifier.

[0093] In a specific implementation, in this embodiment, the permission table can be read, and the first permission in the permission table can be obtained in a top-down order as the current permission, and the permission code corresponding to the current permission can be obtained. According to the different values ​​corresponding to each digit in the permission code, the preset role identifier corresponding to the current permission can be obtained. For example, the value corresponding to a certain digit in the permission code of the current permission is obtained. If the value on the digit is not "0", then the preset role identifier corresponding to the current permission contains the role identifier corresponding to the digit. If the value on the digit is 0, then the preset role identifier corresponding to the current permission does not contain the role identifier corresponding to the digit. By analogy, the role identifiers corresponding to all digits whose values ​​are not "0" in the permission code corresponding to the current permission are obtained as the preset role identifiers corresponding to the current permission, and subsequent permission allocation is performed based on these preset role identifiers. In other words, by obtaining the role identifiers corresponding to all digits whose values ​​are not "0" in the permission code corresponding to the current permission, the preset role identifier corresponding to the current permission is also obtained. For example: Taking the permission code of the current permission as 2130, the role identifiers corresponding to the digits "2", "1" and "3" are the preset role identifiers corresponding to the current permission, and the role identifier corresponding to the digit "0" is not included in the preset role identifiers corresponding to the current permission.

[0094] The value of a certain digit in the permission code of the current permission is converted into a binary number, and each digit in the binary number corresponds to a device identifier, such as the last digit of the binary number represents the mobile terminal, the second last digit of the binary number represents the PC terminal, and so on, which can support application scenarios of multiple device types. When the value of the digit of the binary number is "1", it can be determined that the preset device identifier corresponding to the digit is included in the preset device identifier corresponding to the current permission. When the value of the digit of the binary number is "0", it can be determined that the preset device identifier corresponding to the digit is not included in the preset device identifier corresponding to the current permission. By analogy, all device identifiers in the permission code corresponding to the current permission are obtained, that is, the preset device identifier corresponding to the current permission is obtained, and then the subsequent permission allocation is performed according to these preset device identifiers. In other words, after obtaining the values ​​of all non-"0" digits in the permission code corresponding to the current permission and converting them into binary numbers, the device identifiers corresponding to all digits in the binary number with a value of "1" are all preset device identifiers corresponding to the current permission.

[0095] For example: Take the user's menu permission allocation on the computer as an example. The permission code of the menu permission is 2130, and the user's user number is 01123456789. According to the user's role "01", the value "2" corresponding to the first digit in the permission code is obtained. After converting to a binary number, the binary number "10" is obtained. The value of the last digit of the binary number is "0", so it can be determined that the preset device type corresponding to the menu permission does not include the mobile terminal. The value of the second to last digit is "1", so it can be determined that the preset device type corresponding to the menu permission includes the PC terminal. After that, the subsequent menu permission allocation is performed according to the preset device type obtained. Based on this, the user can perform corresponding operations on the computer according to the assigned menu permissions.

[0096] For another example: taking the user's menu permission allocation on the computer as an example, the permission code of the menu permission is 2130, and the user number of the user is 03123456789. According to the user's role "03", the value "3" corresponding to the third digit in the permission code is obtained. After conversion to binary, the binary number "11" is obtained. The values ​​of the penultimate digit and the second to last digit of the binary number are both "1". Therefore, it can be determined that the preset device type corresponding to the menu permission includes both mobile phones and PCs, and subsequent permission allocation is performed accordingly. Based on this, the user can perform corresponding operations on the computer according to the assigned menu permissions.

[0097] Step S203: Searching whether the preset role identifiers corresponding to the current authority contain the first role identifier. If the first role identifier is found in the preset role identifiers corresponding to the current authority, executing step S204; if the first role identifier is not found in the preset role identifiers corresponding to the current authority, executing step S205.

[0098] In a specific implementation, in this embodiment, according to the first role identifier of the target role, the numerical value of the digit corresponding to the first role identifier in the permission code corresponding to the current permission can be obtained. If the corresponding value of the digit is not "0", then it can be determined that the preset identifier corresponding to the current permission contains the first role identifier, and step S204 and subsequent steps are executed; if the corresponding numerical value of the digit is "0", then it can be determined that the preset role identifier corresponding to the current permission does not contain the first role identifier, and step S205 is executed, and the process returns to step S202 and subsequent steps. Based on this, the user can perform corresponding operations on the electronic device according to the assigned permissions.

[0099] For example, taking the user's menu permission allocation in the mobile phone as an example, the user number of the user is 0212345678, and the permission code corresponding to the menu permission is 2130. The first two digits "02" of the user number are intercepted as the role corresponding to the user, and the corresponding value on the second digit is obtained from the permission code of the current menu permission. The value on the second digit is "1", then it can be determined that the preset role corresponding to the current menu permission includes the role corresponding to the user, and subsequent permission allocation is performed according to the role. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0100] For another example, take the user's menu authority allocation in the mobile phone as an example. The user number is 04123456789, and the authority code corresponding to the menu authority is 2130. The first two digits "04" of the user number are intercepted as the role of the user. From the authority code of the menu authority, the corresponding value on the 4th digit is obtained. The value on the 4th digit is "0", then it can be determined that the preset role corresponding to the menu authority does not include the role corresponding to the user, and the next menu authority and its corresponding menu authority code are obtained, and the subsequent menu authority allocation is performed accordingly. Based on this, the user can perform corresponding operations on the mobile phone according to the authority he has.

[0101] It should be noted that, in this embodiment, the digit corresponding to the first role identifier in the permission code may be obtained by any one of the following methods.

[0102] The digit corresponding to the first role identifier in the permission code corresponds to the first role identifier. For example, if the first role identifier is 01, the first digit or the last digit in the permission code is the digit corresponding to the first role identifier. For another example, if the first role identifier is 10, the tenth digit or the tenth last digit in the permission code is the digit corresponding to the first role identifier.

[0103] Alternatively, when permissions are allocated in an electronic device, the first role identifier is sent to a corresponding server so that the service queries the digital information corresponding to the first role identifier in the permission code based on the first role identifier, and returns the digital information corresponding to the first role identifier in the permission code to the electronic device, thereby obtaining the digital information corresponding to the first role identifier.

[0104] Step S204: Obtain a preset device identifier corresponding to the first role identifier, and execute step S206.

[0105] According to the first role identifier, a preset device identifier corresponding to the first role identifier in the current authority is obtained.

[0106] In a specific implementation, after obtaining the numerical value of the digit corresponding to the first role identifier in the permission code corresponding to the current permission, the numerical value can be converted into a binary number through base conversion. Each digit in the binary number corresponds to a device identifier. If the numerical value of a certain digit is "1", then it can be determined that the preset device identifier corresponding to the first role identifier contains the device identifier corresponding to the digit. If the numerical value of a certain digit is "0", then the preset device identifier corresponding to the first role identifier does not contain the device identifier corresponding to the digit. The device identifiers corresponding to all the digits with a numerical value of "1" obtained are the preset device identifiers corresponding to the first role identifier. In other words, after converting the numerical value of the digit corresponding to the first role identifier into a binary number, the device identifier corresponding to the digit with a numerical value of "1" is the preset device identifier corresponding to the first role identifier.

[0107] For example, taking the user's permission allocation in a mobile phone as an example, the permission code of the current menu permission is 2130, and the user's role code is 02123456789. Get the value "1" corresponding to the second digit in the permission code of the current permission, and convert the value "1" into a binary number "01". The penultimate digit of the binary number represents the mobile terminal, and the penultimate digit represents the PC terminal. Then, it can be determined that the preset device type corresponding to the role corresponding to the user in the current menu permission includes the mobile terminal, but not the PC terminal. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0108] Step S205: Acquire the next permission in the permission group as the new current permission, and return to execute step S202, that is, obtain the preset role identifier and preset device identifier corresponding to the current permission.

[0109] In a specific implementation, the permission table can be read again to obtain the next permission in the permission table in a top-down order as the new current permission. For example, if the current permission obtained in the permission group for the first time is "permission 1", then "permission 2" is obtained in the permission group as the new current permission next time.

[0110] Step S206: Search whether the first device identifier is included in the preset device identifier corresponding to the first role identifier. If the first device identifier is found in the preset device identifier corresponding to the first role identifier, execute step S207, i.e., determine that the current permission is the first target permission corresponding to the first role identifier and the first device identifier; if the first device identifier is not found in the preset device identifier corresponding to the first role identifier, execute step S205, i.e., obtain the next permission as the new current permission in the permission group, and return to execute step S202, i.e., obtain the preset role identifier and preset device identifier corresponding to the current permission.

[0111] In a specific implementation, after obtaining the numerical value of the digit corresponding to the first role identifier in the permission code corresponding to the current permission and converting it into a binary number, obtain the numerical value of the digit corresponding to the first device identifier in the binary number according to the first device identifier of the electronic device. If the numerical value of the digit is "1", then execute step S207; if the numerical value of the digit is "0", then execute step S205, and return to execute step S202 and subsequent steps. In other words, as long as the numerical value of the digit corresponding to the first role identifier in the permission code corresponding to the current permission is converted into a binary number, and the numerical value of the digit corresponding to the first device identifier in the binary number is "1", it can be determined that the current permission is the first target permission corresponding to the target role; otherwise, obtain the next permission in the permission group as the new current permission, and continue to allocate permissions.

[0112] For example, taking the user's menu permission allocation on the mobile phone as an example, the permission code of the current menu permission is 2130, and the user number of the user is 02123456789. The value "1" corresponding to the second digit in the menu permission code is obtained, and the value "1" is converted into a binary number "01". The penultimate digit of the binary number represents the mobile terminal permission, and the penultimate digit represents the PC terminal permission. Therefore, it can be determined that the user has the current menu permission on the mobile phone. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0113] Step S207: Determine that the current permission is a first target permission corresponding to the first role identifier and the first device identifier.

[0114] The first target permission is the permission that the target role has on the electronic device, and the first target permission is open to the target role so that the target role can perform operations corresponding to the first target permission on the electronic device. Accordingly, for a user assigned the target role, the first target permission is open to the user so that the user can perform operations corresponding to the first target permission on the electronic device.

[0115] For example, taking the example of a user logging into a mobile banking APP, when a user logs in to the mobile banking APP with his or her bank card account information, the bank's backend management system will assign a set of permissions to the user based on the user's account information, so that the user can perform functional operations corresponding to the permissions. For example, if the permissions assigned include the bank's account query permission, the user can query the current account balance and expenditure details, etc. Based on this, the user can perform corresponding operations on the mobile banking APP according to the permissions they have.

[0116] Based on Figure 1 In the specific implementation, step S103 can also be implemented in the following manner: Figure 3 As shown:

[0117] Step S301: Obtain the first permission in the permission group as the current permission.

[0118] In a specific implementation, the permission group in this embodiment can be embodied in the form of a permission table, as shown in Table 1.

[0119] Each row in the permission table corresponds to a permission and its corresponding permission code. For example, in permission table 1, "permission 1" corresponds to "permission code 1"; "permission 2" corresponds to "permission code 2".

[0120] The permission code can be represented by a string consisting of one or more digits and / or letters, such as a decimal number, a hexadecimal number, etc. Each digit in the string corresponds to a device identifier, such as the last digit corresponds to "mobile phone", the second last digit corresponds to "PC", and so on. Each additional digit adds a device identifier. In other words, if you need to set a new device identifier, you only need to add a new digit to the permission code.

[0121] In a specific implementation, this embodiment can obtain a permission in the permission table as the current permission through a preset reading method, such as reading the permission table in a top-down order to obtain the first permission in the permission table as the current permission, or randomly obtaining a permission in the permission table as the current permission, and so on.

[0122] Get the value of the digit corresponding to a device identifier in the permission code, convert the value to a binary number, and each digit in the binary number corresponds to a role identifier, such as: the first digit in the string is "Role 1", the second digit is "Role 2", and so on. In other words, if you need to increase the number of role identifiers, you only need to increase the number of digits in the binary number by changing the value of the digit corresponding to the corresponding device identifier in the permission code. For example, the value of a digit in a permission code is 3, which is 11 after conversion to binary, so it can have up to 2 role identifiers at the same time; for another example, the value of a digit in a permission code is 7, which is 111 after conversion to binary, so it can have up to 3 role identifiers at the same time. And so on, the more digits in the binary number, the more role identifiers it has.

[0123] Step S302: Obtain the preset role identifier and preset device identifier corresponding to the current authority.

[0124] Among them, the preset device identifier corresponds to the current authority, and one authority corresponds to at least one preset device identifier; the preset role identifier corresponds to the preset device identifier, and each preset device identifier corresponds to at least one preset role identifier.

[0125] In a specific implementation, by reading the permission table, the first permission in the permission table is obtained as the current permission in a top-down order, and the permission code corresponding to the current permission is obtained. Each digit in the permission code corresponds to a device identifier, such as the last digit represents the mobile terminal, the second last digit represents the PC terminal, and so on. It can support application scenarios of multiple device types. According to the different values ​​corresponding to each digit in the permission code, the preset device identifier corresponding to the current permission is obtained. For example, the value corresponding to a digit in the permission code of the current permission is obtained. If the value on the digit is not "0", then the preset device identifier corresponding to the current permission includes the device identifier corresponding to the digit. If the value on the digit is 0, then the preset device identifier corresponding to the current permission does not include the device identifier corresponding to the digit. By analogy, the device identifiers corresponding to all digits whose values ​​are not "0" in the permission code corresponding to the current permission are obtained as the preset device identifiers corresponding to the current permission, and subsequent permission allocation is performed based on these preset device identifiers. That is to say, by obtaining the device identifiers corresponding to all digits whose values ​​are not "0" in the permission code corresponding to the current permission, the preset device identifier corresponding to the current permission is also obtained.

[0126] For example: Taking the permission code corresponding to the current permission as 2130, the device identifiers corresponding to the digits "2", "1", and "3" are the preset device identifiers corresponding to the current permission, and the device identifier corresponding to the digit "0" is not included in the preset device identifiers corresponding to the current permission.

[0127] The value of a certain digit in the permission code of the current permission is converted into a binary number, and each digit in the binary number corresponds to a role identifier. When the value of a digit in the binary number is "1", it can be determined that the preset role identifier corresponding to the current permission includes the role identifier corresponding to the digit. When the value of a digit in the binary number is "0", it can be determined that the preset role identifier corresponding to the current permission does not include the role identifier corresponding to the digit. By analogy, all preset role identifiers in the permission code corresponding to the current permission are obtained, and subsequent permission allocation is performed based on these preset role identifiers. In other words, after obtaining the values ​​of all non-"0" digits in the permission code corresponding to the current permission and converting them into binary numbers, the role identifiers corresponding to all digits in the binary number with a value of "1" are all preset role identifiers corresponding to the current permission.

[0128] For example: taking the user's menu permission allocation on the computer as an example, the permission code of the menu permission is 1023. According to the user's login device being a computer, i.e., the "PC end", the value "2" on the second-to-last digit in the permission code is obtained. After conversion to a binary number, the binary number "10" is obtained. The corresponding value on the last digit of the binary number is "0", so the preset role corresponding to the menu permission does not include the role corresponding to this digit. The value on the second-to-last digit is "1", so the preset role corresponding to the menu permission includes the role corresponding to this digit, and subsequent permission allocation is performed based on the preset role obtained. Based on this, the user can perform corresponding operations on the computer according to the permissions he or she has.

[0129] For another example: taking the menu permission allocation of users on their mobile phones as an example, the permission code for the menu permission is 1023. According to the device type of the user's login device, which is "mobile", the value "3" on the last digit in the permission code is obtained, and after converting it to a binary number, the binary number "11" is obtained. The values ​​of the last digit and the second to last digit of the binary number are both "1". Therefore, it can be determined that the preset roles corresponding to the menu permission include the roles corresponding to these two digits at the same time, and subsequent permission allocation is performed based on the preset roles obtained. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0130] Step S303: Searching whether the preset device identification corresponding to the current authority contains the first device identification. If the first device identification is found in the preset device identification corresponding to the current authority, executing step S304; if the first device identification is not found in the preset device identification corresponding to the current authority, executing step S305.

[0131] In a specific implementation, in this embodiment, the value of the digit corresponding to the first device identifier in the permission code corresponding to the current permission can be obtained according to the first device identifier of the electronic device. If the value corresponding to the digit is not "0", it can be determined that the preset device identifier corresponding to the current permission includes the first device identifier, and step S304 and subsequent steps are executed; if the value corresponding to the digit is "0", it can be determined that the preset device identifier corresponding to the current permission does not include the first device identifier, and step S305 is executed, and the process returns to step S302 and subsequent steps. Based on this, the user can perform corresponding operations on the electronic device according to the permissions he has.

[0132] For example, taking the menu permission allocation of the user in the mobile phone as an example, the permission code corresponding to the menu permission is 1203. According to the user device type of "mobile terminal", the value "3" on the last digit of the permission code is obtained. Then, it can be determined that the preset device type corresponding to the current menu permission includes the device type corresponding to the electronic device, and the subsequent permission allocation is performed according to the device type of the electronic device. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0133] Step S304: Obtain a preset role identifier corresponding to the first device identifier, and execute step S306.

[0134] According to the first device identifier, a preset role identifier corresponding to the first device identifier in the current authority is obtained.

[0135] In a specific implementation, after obtaining the numerical value of the digit corresponding to the first device identifier in the permission code corresponding to the current permission, the numerical value is converted into a binary number through base conversion. Each digit in the binary number corresponds to a role identifier. If the numerical value of a digit in the binary number is "1", then it can be determined that the preset role identifier corresponding to the first device identifier contains the role identifier corresponding to the digit. If the numerical value of a digit is "0", then the preset role identifier corresponding to the first device identifier does not contain the role identifier corresponding to the digit. The role identifiers corresponding to all the digits with a numerical value of "1" obtained are the preset role identifiers corresponding to the first device identifier. In other words, after converting the numerical value of the digit corresponding to the first role identifier into a binary number, the role identifier corresponding to the digit with a numerical value of "1" is the preset role identifier corresponding to the first device identifier.

[0136] For example, taking the menu permission allocation of users in mobile phones as an example, the permission code of the menu permission is 2103. According to the device type of the user's login device, which is "mobile phone", the value "3" on the last digit in the permission code is obtained, and the value "3" is converted into a binary number "11". The values ​​of the two digits are both "1". Then, it can be determined that the role corresponding to these two digits is the preset role corresponding to the user's device type "mobile phone" in the menu permission, and subsequent permission allocation is performed according to the preset role obtained. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0137] Step S305: Acquire the next permission in the permission group as the new current permission, and return to execute step S302, that is, obtain the preset device identifier and preset role identifier corresponding to the current permission.

[0138] In a specific implementation, the permission table can be read again to obtain the next permission in the permission table in a top-down order as the new current permission. For example, if the current permission obtained in the permission group for the first time is "permission 1", then "permission 2" is obtained in the permission group as the new current permission next time.

[0139] Step S306: searching among the preset role identifiers corresponding to the first device identifier to see whether the first role identifier is included.

[0140] If the first role identifier is found in the preset role identifier corresponding to the first device identifier, execute step S307, that is, determine that the current permission is the first target permission corresponding to the first device identifier and the first role identifier; if the first role identifier is not found in the preset role identifier corresponding to the first device identifier, execute step S305, that is, obtain the next permission as the new current permission in the permission group, and return to execute step S302, that is, obtain the preset device identifier and preset role identifier corresponding to the current permission.

[0141] In a specific implementation, after obtaining the numerical value of the digit corresponding to the first device identifier in the permission code corresponding to the current permission and obtaining a binary number through base conversion, obtain the numerical value of the digit corresponding to the first role identifier in the binary number according to the first role identifier of the electronic device. If the numerical value of the digit is "1", then execute step S307; if the numerical value of the digit is "0", execute step S305, and return to execute step S302 and subsequent steps. In other words, as long as the numerical value of the digit corresponding to the first device identifier in the permission code corresponding to the current permission is converted into a binary number, the numerical value of the digit corresponding to the first role identifier in the binary number is "1", it can be determined that the current permission is the first target permission corresponding to the target role; otherwise, obtain the next permission of the permission group as the new current permission, and continue to allocate permissions.

[0142] For example, taking the user's menu permission allocation on the mobile phone as an example, the permission code of the current menu permission is 2113, and the user's role code is 02123456789. According to the device type of the user's login device, which is "mobile", the value "3" corresponding to the last digit in the permission code is obtained, and the value "3" is converted into a binary number "11". According to the user role "02", the value corresponding to the second to last digit in the binary number is obtained, which is "1". Therefore, it can be determined that the user has the current menu permission on the mobile phone. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0143] Step S307: Determine that the current permission is the first target permission corresponding to the first role identifier and the first device identifier.

[0144] The first target permission is the permission that the target role has on the electronic device, and the first target permission is open to the target role so that the target role can perform operations corresponding to the first target permission on the electronic device. Accordingly, for a user assigned the target role, the first target permission is open to the user so that the user can perform operations corresponding to the first target permission on the electronic device.

[0145] For example, taking the example of a user logging into a mobile banking APP, when a user logs in to the mobile banking APP with his or her bank card account information, the bank's backend management system will assign a set of permissions to the user so that the user can perform functional operations corresponding to the permissions. For example, if the permissions assigned include the bank's account query permission, the user can query the current account balance and expenditure details, etc. Based on this, the user can perform corresponding functional operations in the mobile banking APP according to the assigned permissions.

[0146] Based on Figure 1 In the implementation method, after step S101 and before step S102, the following steps may also be included, such as Figure 4 As shown:

[0147] Step S105: Determine whether the target character has a second character identifier.

[0148] The second role identifier is a variable role identifier, which is stored in a pre-established role identifier table, and the second role identifier in the role identifier table can be added, deleted or changed by setting. The second role identifier is a different role identifier from the first role identifier. For example, if the permission code is a string with 10 digits, that is, one permission can have up to 10 role identifiers at the same time, then the first role identifier must be one of the role identifiers corresponding to the first 7 digits, and the second role identifier must be one of the role identifiers corresponding to the last 3 digits.

[0149] In a specific implementation, in this embodiment, it is possible to determine whether the target role has the second role identification by querying the role identification table. If the role identification table is empty after querying, then it can be determined that the target role does not have the second role identification, and step S102 and subsequent steps are executed. If the role identification table is not empty after querying, then it can be determined that the target role has the second role identification, and step S106 and subsequent steps are executed. In other words, when the target role has the second role identification, the permission search operation is first performed according to the second role identification and the first device identification, and the permission search operation is temporarily not performed according to the first role identification of the target role, that is, step S102 is temporarily not executed.

[0150] Step S106: Obtain the second role identifier of the target role.

[0151] In a specific implementation, after determining that the role identification table is not empty, the role identification table is directly read to obtain the second role identification corresponding to the target role in the role identification table, and step S107 is executed.

[0152] Step S107: Whether the second target permission corresponding to the second role identifier and the first device identifier is found in the permission group.

[0153] The permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier.

[0154] If the second target permission corresponding to the second role identifier and the first device identifier is found, step S108 is executed, i.e., it is determined that the target permission has the second target permission on the electronic device; if the permission corresponding to the second role identifier and the first device identifier is not found, step S102 and subsequent steps are executed. In other words, if the permission corresponding to the second role identifier and the first device identifier is not found, the first device identifier of the target role is obtained, and the permission search operation is started according to the first role identifier of the target role and the first device identifier of the electronic device, i.e., step S102 is started.

[0155] In a specific implementation, the preset role identifier and preset device identifier corresponding to each permission in the permission group can be compared with the second role identifier and the first device identifier, that is, according to the order between the permissions in the permission group, it is determined in turn whether each permission corresponds to the second role identifier and the first device identifier. If it is determined that there is a second target permission corresponding to the second role identifier and the first device identifier, then it can be determined that the target role has the second target permission on the electronic device. For example: in the permission group, the first permission is obtained as the current permission, and the preset role identifier and preset device identifier corresponding to the current permission are obtained; find out whether the preset role identifier and preset device identifier corresponding to the current permission correspond to the second role identifier and the first device identifier; if so, determine that the current permission is the second target permission corresponding to the target role; if not, obtain the next permission in the permission group as the new current permission, and obtain the preset role identifier and preset device identifier corresponding to the current permission, and so on. If the second target permission corresponding to the second role identifier and the first device identifier is found in the permission group, it is determined that the target role has the second target permission on the electronic device; if the second target permission corresponding to the second role identifier and the first device identifier is not found in the permission group, the first role identifier of the target role is obtained and subsequent permission search operations are performed.

[0156] It should be noted that if the second target permission corresponding to the second role identifier and the first device identifier is found in the permission group, the first role identifier of the target role and the subsequent permission search will no longer be obtained. In other words, when the second target permission is found and it is determined that the target role has the second target permission on the electronic device, the current process ends. If the second target permission corresponding to the second role identifier and the first device identifier is not found in the permission group, then the first role identifier of the target role is obtained.

[0157] S108: Determine whether the target role has the second target permission on the electronic device, so that the target role can perform an operation corresponding to the second target permission on the electronic device.

[0158] In a specific implementation, the second target permission in this embodiment may be a set of functional permissions, and the functional permissions corresponding to the second target permission in the electronic device are open to the target role, so that the target role can perform corresponding functional operations on the electronic device according to the second target permission. Accordingly, the user assigned to the target role can perform corresponding functional operations on the electronic device according to the second target permission.

[0159] Based on Figure 4 In the specific implementation, step S107 can be implemented by the following steps: Figure 5 As shown:

[0160] Step S501: Obtain the first permission in the permission group as the current permission.

[0161] In a specific implementation, the permission group in this embodiment can be embodied in the form of a permission table, as shown in Table 1.

[0162] Each row in the permission table corresponds to a permission and its corresponding permission code. For example, in permission table 1, "permission 1" corresponds to "permission code 1"; "permission 2" corresponds to "permission code 2".

[0163] The permission code can be represented by a string consisting of one or more digits and / or letters, such as a decimal number, a hexadecimal number, etc. Each digit in the string corresponds to a role ID, such as the first digit in the string is "Role 1", the second digit is "Role 2", and so on. Each additional digit in the string adds a role ID. In other words, if you need to set a new role ID, you only need to add a new digit to the permission code.

[0164] In a specific implementation, this embodiment can obtain a permission in the permission table as the current permission through a preset reading method, such as reading the permission table in a top-down order to obtain the first permission in the permission table as the current permission, or randomly obtaining a permission in the permission table as the current permission, and so on.

[0165] Get the value of the digit corresponding to a role ID in the permission code, convert the value to a binary number, and each digit in the binary number corresponds to a device ID, such as: the last digit corresponds to "mobile phone", the second last digit corresponds to "PC", and so on. The number of digits in the binary number corresponds to the number of device IDs. In other words, if you need to increase the number of device IDs, you only need to increase the number of digits in the binary number. For example, the value of a digit in a permission code is 3, which is 11 after conversion to binary, so it can have up to 2 device IDs at the same time; for another example, the value of a digit in a permission code is 7, which is 111 after conversion to binary, so it can have up to 3 device IDs at the same time. By analogy, the more digits in a binary number, the more device IDs it has.

[0166] Step S502: Obtain the preset role identifier and preset device identifier corresponding to the current authority.

[0167] Among them, the preset role identifier corresponds to the current authority, and one authority corresponds to at least one preset role identifier; the preset device identifier corresponds to the preset role identifier, and each preset role identifier corresponds to at least one preset device identifier.

[0168] In a specific implementation, in this embodiment, the permission table can be read, and the first permission in the permission table can be obtained in a top-down order as the current permission, and the permission code corresponding to the current permission can be obtained. According to the different values ​​corresponding to each digit in the permission code, the preset role identifier corresponding to the current permission can be obtained. For example, the value corresponding to a certain digit in the permission code of the current permission is obtained. If the value on the digit is not "0", then the preset role identifier corresponding to the current permission contains the role identifier corresponding to the digit. If the value on the digit is 0, then the preset role identifier corresponding to the current permission does not contain the role identifier corresponding to the digit. By analogy, the role identifiers corresponding to all digits whose values ​​are not "0" in the permission code corresponding to the current permission are obtained as the preset role identifiers corresponding to the current permission, and subsequent permission allocation is performed based on these preset role identifiers. In other words, by obtaining the role identifiers corresponding to all digits whose values ​​are not "0" in the permission code corresponding to the current permission, the preset role identifier corresponding to the current permission is also obtained. For example: Taking the permission code of the current permission as 2130, the role identifiers corresponding to the digits "2", "1" and "3" are the preset role identifiers corresponding to the current permission, and the role identifier corresponding to the digit "0" is not included in the preset role identifiers corresponding to the current permission.

[0169] The value of a certain digit in the permission code of the current permission is converted into a binary number, and each digit in the binary number corresponds to a device identifier, such as the last digit of the binary number represents the mobile terminal, the second last digit of the binary number represents the PC terminal, and so on, which can support application scenarios of multiple device types. When the value of the digit of the binary number is "1", the preset device identifier corresponding to the current permission includes the device identifier corresponding to the digit. When the value of the digit of the binary number is "0", the preset device identifier corresponding to the current permission does not include the device identifier corresponding to the digit. By analogy, all device identifiers in the permission code corresponding to the current permission are obtained, that is, the preset device identifier corresponding to the current permission is obtained, and then the subsequent permission allocation is performed according to these preset device identifiers. In other words, after obtaining the values ​​of all non-"0" digits in the permission code corresponding to the current permission and converting them into binary numbers, the device identifiers corresponding to all digits in the binary number with a value of "1" are all preset device identifiers corresponding to the current permission.

[0170] For example: take the user's menu permission allocation on the computer as an example. The permission code of the menu permission is 2130, and the user number of the user is 01123456789. According to the user's role "01", the value "2" corresponding to the first digit in the menu permission code is obtained. After conversion to a binary number, the binary number "10" is obtained. The value of the last digit of the binary number is "0", so it can be determined that the preset device type corresponding to the menu permission does not include the mobile phone. The value of the second to last digit is "1", so it can be determined that the preset device type corresponding to the menu permission includes the PC. After that, the subsequent menu permission allocation is performed according to the preset device type obtained. Based on this, the user can perform corresponding operations on the computer according to the assigned menu.

[0171] Step S503: Search whether the preset role identifier corresponding to the current authority contains the second role identifier. If the second role identifier is found in the preset role identifier corresponding to the current authority, execute step S504; if the second role identifier is not found in the preset role identifier corresponding to the current authority, execute step S505.

[0172] In a specific implementation, in this embodiment, the value of the digit corresponding to the second role identifier in the permission code corresponding to the current permission can be obtained according to the second role identifier of the target role. If the value corresponding to the digit is not "0", then it can be determined that the preset identifier corresponding to the current permission contains the second role identifier, and step S504 and subsequent steps are executed; if the value on the digit is "0", then it can be determined that the preset role identifier corresponding to the current permission does not contain the second role identifier, and step S505 is executed, and step S502 and subsequent steps are returned to be executed. Based on this, the user can perform corresponding operations on the electronic device according to the assigned permissions.

[0173] For example, taking the user's menu permission allocation in the mobile phone as an example, the user number of the user is 02123456789, and the menu permission code corresponding to the menu permission is 2130. The first two digits "02" of the user number are intercepted, and the corresponding value on the second digit is obtained from the permission code of the current menu permission. The value on the second digit is "1", then it can be determined that the preset role corresponding to the menu permission includes the role corresponding to the user, and subsequent permission allocation is performed according to the role. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0174] For another example, take the menu permission allocation of the user in the mobile phone as an example. The menu permission code corresponding to the user number 04123456789 is 2130. The first two digits "04" of the user number are intercepted as the role of the user. From the permission code of the current menu permission, the corresponding value of the 4th digit is obtained. The value of the 4th digit is "0". Then, it can be determined that the preset role corresponding to the menu permission does not include the role corresponding to the user, and the next menu permission is obtained for subsequent menu permission allocation. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0175] Step S504: Obtain a preset device identifier corresponding to the second role identifier, and execute step S506.

[0176] According to the second role identifier, a preset device identifier corresponding to the second role identifier in the current permission is obtained.

[0177] In a specific implementation, after obtaining the numerical value of the digit corresponding to the second role identifier in the permission code corresponding to the current permission, the numerical value can be converted into a binary number through base conversion. Each digit in the binary number corresponds to a device identifier. If the numerical value of a certain digit is "1", the preset device identifier corresponding to the second role identifier includes the device identifier corresponding to the digit. If the numerical value of a certain digit is "0", the preset device identifier corresponding to the second role identifier does not include the device identifier corresponding to the digit. The device identifier corresponding to all the digits with a numerical value of "1" in the obtained binary number is the preset device identifier corresponding to the second role identifier. In other words, after converting the numerical value of the digit corresponding to the second role identifier into a binary number, the device identifier corresponding to the digit with a numerical value of "1" is the preset device identifier corresponding to the second role identifier.

[0178] For example, taking the user's permission allocation in a mobile phone as an example, the permission code of the current menu permission is 2130, and the user's role code is 02123456789. Get the value "1" corresponding to the second digit in the permission code of the current permission, and convert the value "1" into a binary number "01". The penultimate digit of the binary number represents the mobile terminal, and the penultimate digit represents the PC terminal. Then, it can be determined that the preset device type corresponding to the role corresponding to the user in the current menu permission includes the mobile terminal, but not the PC terminal. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0179] Step S505: Acquire the next permission in the permission group as the new current permission, and return to execute step S502, that is, obtain the preset role identifier and preset device identifier corresponding to the current permission.

[0180] In a specific implementation, the permission table can be read again to obtain the next permission in the permission table as the new current permission. For example, if the current permission obtained in the permission group for the first time is "permission 1", then "permission 2" is obtained in the permission group as the new current permission next time.

[0181] Step S506: Search whether the first device identifier is included in the preset device identifier corresponding to the second role identifier. If the first device identifier is found in the preset device identifier corresponding to the second role identifier, execute step S507, i.e., determine that the current permission is the second target permission corresponding to the second role identifier and the first device identifier; if the first device identifier is not found in the preset device identifier corresponding to the second role identifier, execute step S505, i.e., obtain the next permission as the new current permission in the permission group, and return to execute step S502, i.e., obtain the preset role identifier and preset device identifier corresponding to the current permission.

[0182] In a specific implementation, after obtaining the numerical value of the digit corresponding to the second role identifier in the permission code corresponding to the current permission and converting it into a binary number, obtain the numerical value of the digit corresponding to the first device identifier in the binary number according to the first device identifier of the electronic device. If the numerical value of the digit is "1", then execute step S507; if the numerical value of the digit is "0", then execute step S505, and return to execute step S502 and subsequent steps. In other words, as long as the numerical value of the digit corresponding to the second role identifier in the permission code corresponding to the current permission is converted into a binary number, and the numerical value of the digit corresponding to the first device identifier is "1", it can be determined that the current permission is the second target permission corresponding to the target role; otherwise, obtain the next permission in the permission group as the new current permission, and continue to allocate permissions.

[0183] For example, taking the user's menu permission allocation on the mobile phone as an example, the permission code of the current menu permission is 2130, and the user number of the user is 02123456789. The value "1" corresponding to the second digit in the menu permission code is obtained, and the value "1" is converted into a binary number "01". The penultimate digit of the binary number represents the mobile terminal permission, and the penultimate digit represents the PC terminal permission. Therefore, it can be determined that the user has the current menu permission on the mobile phone. Based on this, the user can perform corresponding operations on the mobile phone according to the permissions he has.

[0184] Step S507: Determine that the current permission is a second target permission corresponding to the second role identifier and the first device identifier.

[0185] The second target permission is the permission that the target role has on the electronic device, and the second target permission is open to the target role so that the target role can perform operations corresponding to the second target permission on the electronic device. Accordingly, for a user assigned the target role, the second target permission is open to the user so that the user can perform operations corresponding to the second target permission on the electronic device.

[0186] For example, taking the example of a user logging into a bank's mobile banking APP, when a user logs in to the mobile banking APP with his or her bank card account information, the bank's backend management system will assign a set of permissions to the user based on the user's account information, so that the user can perform functional operations corresponding to the permissions. For example, if the permissions assigned include the bank's account query permission, the user can query the current account balance and expenditure details, etc. Based on this, the user can perform corresponding operations on the mobile banking APP according to the permissions they have.

[0187] Based on Figure 1 In the implementation of the method, the following steps may be further included after step S104, such as Figure 6 As shown:

[0188] Step S109: Obtain all first target sub-authorities corresponding to the first role identifier and the first device identifier of the electronic device from among all sub-authorities in the first target authority, so that the target role can perform operations corresponding to the first target sub-authority in the electronic device.

[0189] The first target permission includes at least one sub-permission, and each sub-permission in the first target permission corresponds to at least one preset role identifier and at least one preset device identifier.

[0190] The first target permission is traversed to obtain all sub-permissions in the first target permission, and for each traversed sub-permission, a comparison is made to see whether it corresponds to the first role identifier and the first device identifier, so as to obtain all first target sub-permissions in the first target permission corresponding to the first role identifier and the first device identifier.

[0191] In a specific implementation, the sub-permissions in the first target permission in this embodiment can be reflected in the form of a sub-permission table, as shown in Table 2:

[0192] Table 2 Sub-authority table

[0193] Sub-authority 1 Permission code 1 Sub-authority 2 Permission code 2 Sub-permission n Permission code n

[0194] Read the sub-permission table in a certain order, such as traversing the sub-permission table from top to bottom, obtaining the first sub-permission in the sub-permission table as the current sub-permission, comparing whether the current sub-permission corresponds to the first role identifier and the first device identifier, then obtaining the next sub-permission in the sub-permission table as the current sub-permission, comparing whether the current sub-permission corresponds to the first role identifier and the first device identifier, and so on, performing a comparison operation on all sub-permissions in the first target permission. For example: obtain the preset role identifier and preset device identifier corresponding to the current subauthority according to the permission code corresponding to the current subauthority; check whether the preset role identifier corresponding to the current subauthority contains the first role identifier; if the preset role identifier corresponding to the current subauthority contains the first role identifier, obtain the preset device identifier corresponding to the first role identifier; if the preset device identifier corresponding to the first role identifier contains the first device identifier, it can be determined that the current subauthority is a first target subauthority corresponding to the target role in the first target permission; if the preset role identifier corresponding to the current subauthority does not contain the first role identifier, or the preset device identifier corresponding to the first role identifier does not contain the first device identifier, it can be determined that the current subauthority is not a first target subauthority corresponding to the target role, and so on, until all first target subauthorities in the first target permission are obtained.

[0195] That is to say, when performing a comparison operation on a sub-authority in the first target authority, no matter what the comparison result is, it is necessary to perform a comparison operation on all sub-authorities in the first target authority to obtain all first target sub-authorities corresponding to the target role in the first target authority. Accordingly, the user can perform corresponding operations in the electronic device according to the permissions assigned.

[0196] Based on Figure 4 In the implementation of the method, the following steps may be further included after step S108, such as Figure 7 As shown:

[0197] Step S110: Obtain all second target sub-authorities corresponding to the second role identifier and the first device identifier of the electronic device from among all sub-authorities in the second target authority, so that the target role can perform operations corresponding to the second target sub-authority in the electronic device.

[0198] The second target permission includes at least one sub-permission, and each sub-permission in the second target permission corresponds to at least one preset role identifier and at least one preset device identifier.

[0199] Traverse the second target permission to obtain all sub-permissions in the second target permission, and for each traversed sub-permission, compare whether it corresponds to the second role identifier and the first device identifier to obtain all second target sub-permissions in the second target permission that correspond to the second role identifier and the first device identifier.

[0200] In a specific implementation, the sub-permissions in the second target permission in this embodiment can be reflected in the form of a sub-permission table, and the sub-permission table is shown in Table 2.

[0201] The sub-permission table is read in a certain order, such as by traversing the sub-permission table from top to bottom, obtaining the first sub-permission in the sub-permission table as the current sub-permission, comparing whether the current sub-permission corresponds to the second role identifier and the first device identifier, and then obtaining the next sub-permission in the sub-permission table as the current sub-permission, comparing whether the current sub-permission corresponds to the second role identifier and the first device identifier, and so on, performing a comparison operation on all sub-permissions in the first target permission. For example: obtain the preset role identifier and preset device identifier corresponding to the current subauthority according to the permission code corresponding to the current subauthority; check whether the preset role identifier corresponding to the current subauthority contains the second role identifier; if the preset role identifier corresponding to the current subauthority contains the second role identifier, obtain the preset device identifier corresponding to the second role identifier; if the preset device identifier corresponding to the second role identifier contains the first device identifier, it can be determined that the current subauthority is a second target subauthority corresponding to the target role in the second target permission; if the preset role identifier corresponding to the current subauthority does not contain the second role identifier, or the preset device identifier corresponding to the second role identifier does not contain the first device identifier, it can be determined that the current subauthority is not a second target subauthority corresponding to the target role, and so on, until all second target subauthorities in the second target permission are obtained.

[0202] That is to say, when performing a comparison operation on a sub-authority in the second target authority, no matter what the comparison result is, it is necessary to perform a comparison operation on all sub-authorities in the second target authority to obtain all second target sub-authorities corresponding to the target role in the second target authority. Accordingly, the user can perform corresponding operations in the electronic device according to the permissions assigned.

[0203] refer to Figure 8 As shown, it is a flowchart of the implementation of a rights management device provided in the second embodiment of the present application, which can be applied to applications or devices for specific users, such as mobile phones, tablet computers, PCs, TVs and other electronic devices or applications installed in electronic devices. This embodiment is mainly used to solve the problem of relatively simple allocation of user rights in information systems.

[0204] A first device identification obtaining unit 801 is configured to obtain a first device identification of an electronic device, wherein the first device identification at least represents a device type of the electronic device;

[0205] A first role identification acquisition unit 802, used to acquire a first role identification of a target role;

[0206] The first permission search unit 803 is used to search for the permission corresponding to the first role identifier and the first device identifier in the permission group, and if the first target permission corresponding to the first role identifier and the first device identifier is found, determine that the target role has the first target permission on the electronic device, so that the target role can perform the operation corresponding to the first target permission on the electronic device; wherein the permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier;

[0207] It can be seen from the above technical scheme that in a permission management device provided in Example 2 of the present application, when a target role is logged in on an electronic device on which the device is provided, the first device identifier of the electronic device and the first role identifier of the target role are obtained, and then the first target permission corresponding to the first role identifier and the device identifier of the electronic device is found from the permission group. Based on this, in this embodiment, the device identifier of the electronic device also participates in the permission allocation of the target role, and different permissions will be allocated to the user according to the different device types of the electronic device logged in, thereby avoiding the problem of relatively single permission allocation.

[0208] In one implementation, the first permission search unit 803 is specifically configured to:

[0209] Obtain the first permission in the permission group as the current permission; obtain the preset role identifier and preset device identifier corresponding to the current permission; search whether the first role identifier is included in the preset role identifier corresponding to the current permission; if the first role identifier is found in the preset role identifier corresponding to the current permission, obtain the preset device identifier corresponding to the first role identifier according to the preset device identifier corresponding to the current permission; search whether the first device identifier is included in the preset device identifier corresponding to the first role identifier; if the first device identifier is found in the preset device identifier corresponding to the first role identifier, determine that the current permission is the first target permission corresponding to the first role identifier and the first device identifier; if the first role identifier is not found in the preset role identifier corresponding to the current permission, or, if the first device identifier is not found in the preset device identifier corresponding to the first role identifier, obtain the next permission in the permission group as the new current permission, and continue to trigger the first permission search unit 803.

[0210] In one implementation, the first authority search unit 803 may also be used to:

[0211] Obtain the first permission in the permission group as the current permission; obtain the preset role identifier and preset device identifier corresponding to the current permission; search whether the first device identifier is included in the preset device identifier corresponding to the current permission; if the first device identifier is found in the preset device identifier corresponding to the current permission, obtain the preset role identifier corresponding to the first device identifier according to the preset role identifier corresponding to the current permission; search whether the first role identifier is included in the preset role identifier corresponding to the first device identifier; if the first device identifier is found in the preset role identifier corresponding to the first device identifier, determine that the current permission is the first target permission corresponding to the first role identifier and the first device identifier; if the first device identifier is not found in the preset device identifier corresponding to the current permission, or, if the first role identifier is not found in the preset role identifier corresponding to the first device identifier, obtain the next permission in the permission group as the new current permission, and continue to trigger the first permission search unit 803.

[0212] In one implementation, the device in this embodiment may further include the following units: Fig. 9 As shown:

[0213] The second role identification judgment unit 804 is used to judge whether the target role has a second role identification after the first device identification acquisition unit 801 acquires the first device identification of the electronic device and before the first role identification acquisition unit 802 acquires the first role identification of the target role, wherein the second target permission is different from the first target permission;

[0214] If the target role has the second role identifier, the second permission search unit 805 is triggered;

[0215] If the target character does not have the second character identifier, the first character identifier obtaining unit 802 is triggered;

[0216] The second permission search unit 805 searches for the permission corresponding to the second role identifier and the first device identifier in the permission group. If the second target permission corresponding to the second role identifier and the first device identifier is found, it is determined that the target role has the second target permission on the electronic device, so that the target role can perform the operation corresponding to the second target permission on the electronic device, wherein the second target permission is different from the first target permission; if the permission corresponding to the second role identifier and the first device identifier is not found in the permission group, the first role identifier acquisition unit 802 is triggered.

[0217] In one implementation, the device in this embodiment further includes the following units: Fig.10 As shown:

[0218] The first sub-permission search unit 806 is used to obtain all first target sub-permissions corresponding to the first role identifier and the first device identifier in all sub-permissions in the first target permission after the first permission search unit 803 determines that the target role has the first target permission on the electronic device, so that the target role can perform operations corresponding to the first target sub-permission on the electronic device; wherein the first target permission includes at least one sub-permission, and each sub-permission in the first target permission corresponds to at least one preset role identifier and at least one preset device identifier, respectively.

[0219] In one implementation, the device in this embodiment may also include the following units: Fig.11 As shown:

[0220] The second sub-authority search unit 807 is used to obtain all second target sub-authorities corresponding to the second role identifier and the first device identifier in all sub-authorities in the second target permission after the second permission search unit 805 determines that the target role has the second target permission on the electronic device, so that the target role can perform operations corresponding to the second target sub-authority on the electronic device; wherein the second target permission includes at least one sub-authority, and each sub-authority in the second target permission corresponds to at least one preset role identifier and at least one preset device identifier.

[0221] refer to Fig.12 As shown, it is a schematic diagram of the structure of a rights management device provided in the third embodiment of the present application, and the electronic device can be a mobile phone, a tablet computer, a PC, a television, etc. This embodiment is mainly used to solve the problem of relatively simple allocation of user rights in an information system.

[0222] The memory 1201 is used to store the computer program and the data generated by the running of the computer program;

[0223] Processor 1202 is used to execute a computer program to achieve: obtaining a first device identifier of an electronic device, the first device identifier at least representing the device type of the electronic device; obtaining a first role identifier of a target role; searching for permissions corresponding to the first role identifier and the first device identifier in a permission group, and if a first target permission corresponding to the first role identifier and the first device identifier is found, determining that the target role has the first target permission on the electronic device, so that the target role can perform an operation corresponding to the first target permission on the electronic device; wherein the permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier.

[0224] It can be seen from the above technical scheme that in an electronic device provided in Example 3 of the present application, when a target role is logged in on the electronic device, the first device identification of the electronic device and the first role identification of the target role are obtained, and then the permission corresponding to the first role identification and the device identification of the electronic device is found from the permission group. Based on this, in this embodiment, the device identification of the electronic device also participates in the permission allocation of the target role, and different permissions will be allocated to the user according to the different device types of the electronic device logged in, avoiding the problem of relatively single permission allocation.

[0225] An embodiment of the present application also provides a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by the processor 1202 in the electronic device, the electronic device can execute the permission management method provided in any embodiment of the present application.

[0226] An embodiment of the present application also provides a computer program product, including a computer program, which implements the permission management method provided in any embodiment of the present application when the computer program is executed by a processor.

[0227] Taking the menu permission management and verification method that supports permission differences in multiple scenarios implemented by the present application as an example, current information systems generally provide menus. For the purpose of ensuring information security or facilitating users to quickly find the required functions, most information systems have implemented menu permission control. In the current menu permission control method, for the same system, a user can only correspond to one set of roles and one set of permissions. However, the scenarios supported by the current information system are not limited to computers, but also exist in various scenarios such as tablets and PCs. In view of the characteristics of different electronic products, the functions that the same user can enjoy are different, so the menu permissions should also be different accordingly. The current menu permission control method cannot support differentiated permission management in multiple scenarios. The present application provides a menu permission management and verification method that supports permission differences in multiple scenarios, which aims to solve the problem that the prior art cannot support the same system to have different functions in different scenarios, the menu permissions are inconsistent, and it is difficult to uniformly manage menu permissions.

[0228] Basic solution: Create a menu permission code table, menu role table, and user role table in the database. The menu permission code table contains two columns. The first column stores the menu code, and the second column stores the corresponding menu permission code. Each bit of the menu permission code represents a role. For each character corresponding to a role, convert it into binary. The last bit of the binary represents the PC-side permission, which is 1 for permission and 0 for no permission. The second to last bit represents the Pad-side permission, which is 1 for permission and 0 for no permission, and so on. It supports multiple scenarios. The menu administrator can select menu permissions through the visual interface of the menu management end, and write the generated menu permissions into the database menu permission code table. Based on this, when customers use the information system, the information system can verify the menu permissions based on the menu permissions stored in the database.

[0229] In various information systems, menus provide the ability to classify functions, allowing users to quickly find the functions they need. For the purposes of information confidentiality, system security, and user convenience, most information systems control the access rights of menus.

[0230] The current menu permission control generally assigns a group of menu permissions with similar functions to a role, and then assigns the role to the user, so that the user has all the permissions of the role. The current menu management method generally manages menu permissions by adjusting the permissions of the role and the role of the user. In the current menu permission control method, for the same system, a user can only correspond to one group of roles and one group of permissions. In the case of multiple scenarios, a set of permission management models needs to be implemented separately for each scenario, and it is impossible to use the same set of permission models to achieve differentiated management of menu permissions in multiple scenarios.

[0231] The present application provides a menu permission management and verification method that supports permission differences in multiple scenarios, aiming to solve the problem that the prior art cannot support the same system having different functions in different scenarios, the menu permissions are inconsistent, and it is difficult to uniformly manage menu permissions.

[0232] The menu permission management method supports the use of the menu permission management system to set menu permissions in multiple scenarios, so as to generate a unified set of menu permission codes and write them into the database. The menu permission verification method supports users to use the client system in different scenarios, and can perform differential permission control based on the menu permission codes in the database and the user login device. In addition, this application supports fixed roles and variable roles, and has the ability to control differential permissions in multiple dimensions in multiple scenarios.

[0233] First, refer to Fig.13 As shown, the present application provides an overall implementation structure diagram of a menu permission management method that supports permission differences in multiple scenarios, including the following steps:

[0234] S11. Establish a menu permission code table, a menu role table and a user role table in the database. The menu permission code table contains two columns, the first column stores the menu code, and the second column stores the corresponding menu permission code. Each bit of the menu permission code represents a role, and the roles include fixed roles and variable roles. The variable role needs to be configured in the database menu role table and user role table.

[0235] The data stored in the menu permission code is shown in Table 3:

[0236] Table 3 Menu permission code table

[0237]

[0238] For example, a system supports both PC and mobile terminals. We use the first digit of the binary number to represent the mobile terminal permission, and the second digit to represent the PC terminal permission. 1 represents permission, and 0 represents no permission. When the menu opens the mobile terminal permission, the permission is 10 (binary) and the corresponding character is 2 (decimal). When the menu opens the PC terminal permission, the permission is 01 (binary) and the corresponding character is 1 (decimal); when the menu opens both mobile and PC terminal permissions, the permission is 11 (binary) and the corresponding character is 3 (decimal).

[0239] If the permission code of a menu is 21300, the first digit corresponds to role 1, the second digit corresponds to role 2, and so on. The meaning of this permission code is that users with role 1 can access this menu when logging in on the mobile terminal, users with role 2 can access this menu when logging in on the PC terminal, users with role 3 can access this menu when logging in on both the PC terminal and the mobile terminal, and users with roles 4 and 5 do not have access rights to this menu.

[0240] The relationship between the menu code and the menu permission code is one-to-one, that is, one menu code corresponds to only one menu permission code.

[0241] The data stored in the menu role table is shown in Table 4:

[0242] Table 4 Menu role table

[0243] Property Name Data item category range Menu Code ID Class Customized, no duplication Role Identification ID Class Customized, no duplication

[0244] The correspondence between menu codes and role identifiers is many-to-many, that is, the permissions of a menu can be assigned to multiple roles, and a role can have permissions for multiple menus.

[0245] The contents stored in the user role table are shown in Table 5:

[0246] Table 5 User role table

[0247] Property Name Data item category range Customer Number ID Class Customized, no duplication Role Identification ID Class Customized, no duplication

[0248] The relationship between customer number and role ID is many-to-many, that is, one customer can have multiple roles, and one role can be assigned to multiple customers.

[0249] S12. Use the menu management system to manage menu permissions. In the menu management system, for the input menu, the scene type (such as mobile phone, PC, TV, etc.) can be checked, and the role of the menu under the scene type can be checked.

[0250] For example, in the system, a total of 100 roles are set, the first 70 roles are fixed roles, and the last 30 roles are variable roles.

[0251] S13. Calculate the permission code of the menu. For each role, the last bit of the binary represents the PC permission, 1 for permission and 0 for no permission. The second to last bit represents the Pad permission, 1 for permission and 0 for no permission, and so on, supporting multiple scenarios. Finally, convert the binary number into the corresponding hexadecimal character, and the obtained character is the value of the role's position in the permission code. Using hexadecimal digits to support 4 different scenarios. Other character representation methods can also be used to support more scenarios.

[0252] S14, writing the calculated menu permission code into the database.

[0253] S15, perform a heat recovery operation to ensure that the menu permission code is effective. This step is applicable when the menu permission code table, menu role table, and user role table use Redis cache.

[0254] Hot recovery operation means that some information systems cache menus and menu permission information in the redis cache to prevent the system from consuming system resources and slow login speed by reading menus from the database every time you log in. In this way, you don't need to go to the database to get data every time. Getting data from the redis cache is much faster than getting data from the database.

[0255] When the menu management system is used to modify menu permissions, the menu permission code stored in the database is modified, so the redis cache needs to be cleared and retrieved from the database again. The operation at this time is called a hot recovery operation.

[0256] In a second aspect, the present application provides a menu permission verification method that supports permission differences in multiple scenarios, including the following steps:

[0257] S21. When the customer logs in to the system, the full menu is obtained. The first time it is read from the database and put into the cache, and then it is obtained from the cache.

[0258] Full menu: Full menu refers to all menus contained in the system, obtained from the database. The client can automatically obtain all menus that the currently logged-in user can access based on the role of the currently logged-in user.

[0259] S22, obtain the menu permission code table, menu role table and user role table. Read from the database and put into cache for the first time, and then obtain from cache.

[0260] S23. If the menu role table is empty, there is no variable role, and menu filtering without the participation of the variable role S24 is performed; if the menu role table is not empty, there is a variable role, and menu filtering with the participation of the variable role S25 is performed.

[0261] S24, perform menu filtering without the participation of variable roles. Put the vertex menu into the current menu set. For each menu in the menu set, query the cache to see whether the current menu has a permission code. If the current menu has a permission code, check whether the menu has the fixed role of the current user. If so, the menu is open to the user, and then obtain the submenus of the menu as the menu set, and recursively perform menu filtering without the participation of variable roles, such as Fig.14 If the permission code is not available, the menu is blocked. If the current menu does not have a permission code, the submenus of the menu are obtained as a menu set, and the menu filtering without the participation of the variable role is recursively performed. The execution ends and the process goes to S26.

[0262] Top menu: A system has only one top menu, and all submenus of the top menu are all first-level menus in the system. As shown in Table 6, it is a partial menu table of a bank's electronic banking system. The submenus of the top menu of the online banking system include: account menu, transfer menu, deposit menu, credit card menu, etc.

[0263] Table 6 Partial menu table of a bank's electronic banking system

[0264]

[0265] S25. Execute menu filtering with variable roles. Put the vertex menu into the current menu set. For each menu in the menu set, query the cache to see if the current menu has a permission code. If the current menu has a permission code, check whether the menu and the current user have the same variable role at the same time. If the menu and the current user have the same variable role at the same time, open the menu, and then obtain the submenus of the menu as the menu set. Recursively execute menu filtering with variable roles, such as Fig.15As shown. If the menu and the current user do not have the same role in the user role table at the same time, check whether the menu has the fixed role of the current user. If so, the menu is opened, and then the submenus of the menu are obtained as a menu set, and the menu filtering with the participation of variable roles is recursively executed. If not, the menu is blocked. If the current menu does not have an authorization code, the submenus of the menu are obtained as a menu set, and the menu filtering with the participation of variable roles is recursively executed. Execution ends and goes to S26.

[0266] Recursively perform menu filtering with variable roles: filter out menus that the current customer does not have access rights to, leaving only menus that the customer has access rights to. For the obtained open menus, it is also necessary to filter their submenus, because the customer may have access rights to the "Account" menu, but not to its submenus (for example: Account-Other Bank Accounts).

[0267] S26. Display menus that are still open after permission filtering in the system.

[0268] Specifically, the method for judging whether a menu has a fixed role of the current user according to the permission code includes the following steps:

[0269] S241. Obtain the device type of the user logging in and the user's fixed role.

[0270] S242. Obtain characters corresponding to the user's fixed role from the permission code of the menu, and convert the obtained characters into binary numbers.

[0271] S243. Obtain the value of the corresponding bit in the binary number corresponding to the user login device. If it is 1, the menu has the fixed role of the current user. If it is 0, the menu does not have the fixed role of the current user.

[0272] Specifically, judging whether a menu and the current user have the same variable role at the same time according to the permission code includes the following steps:

[0273] S251. Obtain the device type used by the user to log in.

[0274] S252, obtain all the variable roles of the current user from the user role table. For each variable role possessed by the user, execute S253-S254.

[0275] S253, obtaining the character corresponding to the variable role from the permission code of the menu, and converting the obtained character into a binary number.

[0276] S254. Obtain the value of the corresponding bit in the binary number corresponding to the user login device. If it is 1, the menu and the current user have the same variable role at the same time, and the judgment process ends. If it is 0 and the user does not have the next variable role, the menu and the current user do not have the same variable role at the same time, and the judgment process ends. Otherwise, obtain the next variable role of the user and continue to execute S253.

[0277] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0278] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0279] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0280] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. 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 application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A rights management method, characterized in that: Applied to an electronic device, a target character is logged into the electronic device, and the method includes: Acquire a first device identifier of the electronic device, where the first device identifier at least represents a device type of the electronic device; Obtaining a first role identifier of the target role; In the permission group, searching for a permission corresponding to the first role identifier and the first device identifier, and if a first target permission corresponding to the first role identifier and the first device identifier is found, determining that the target role has the first target permission on the electronic device, so that the target role can perform an operation corresponding to the first target permission on the electronic device; The permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier; The step of searching, in the permission group, for the permission corresponding to the first role identifier and the first device identifier includes: Get the first permission in the permission group as the current permission; Obtaining a preset role identifier and a preset device identifier corresponding to the current permission; Searching among the preset role identifiers corresponding to the current authority whether the first role identifier is included; If the first role identifier is found in the preset role identifiers corresponding to the current authority, obtaining the preset device identifier corresponding to the first role identifier according to the preset device identifier corresponding to the current authority; searching among preset device identifiers corresponding to the first role identifier whether the first device identifier is included; If the first device identifier is found in the preset device identifiers corresponding to the first role identifier, determining that the current permission is a first target permission corresponding to the first role identifier and the first device identifier; If the first role identifier is not found in the preset role identifiers corresponding to the current permission, or if the first device identifier is not found in the preset device identifiers corresponding to the first role identifier, obtain the next permission in the permission group as the new current permission, and return to the step of obtaining the preset role identifier and the preset device identifier corresponding to the current permission; The obtaining of the preset role identifier and the preset device identifier corresponding to the current authority includes: Obtaining a current permission code corresponding to the current permission; According to different values ​​corresponding to each digit in the current permission code, obtaining a preset role identifier corresponding to the current permission; Convert the numerical value corresponding to the preset role identifier into a binary number; A preset device identification corresponding to the current authority is obtained based on the binary number, wherein each digit in the binary number corresponds to a device identification.

2. The method according to claim 1, characterized in that In the permission group, searching for permissions corresponding to the first role identifier and the first device identifier includes: Get the first permission in the permission group as the current permission; Obtaining a preset role identifier and a preset device identifier corresponding to the current permission; Searching among preset device identifiers corresponding to the current permission whether the first device identifier is included; If the first device identifier is found in the preset device identifiers corresponding to the current authority, obtaining the preset role identifier corresponding to the first device identifier according to the preset role identifier corresponding to the current authority; Searching among preset role identifiers corresponding to the first device identifier whether the first role identifier is included; If the first device identifier is found in the preset role identifiers corresponding to the first device identifier, determining that the current permission is a first target permission corresponding to the first role identifier and the first device identifier; If the first device identifier is not found in the preset device identifiers corresponding to the current authority, or if the first role identifier is not found in the preset role identifiers corresponding to the first device identifier, obtain the next permission in the permission group as the new current permission, and return to execute the step of obtaining the preset role identifier and preset device identifier corresponding to the current authority.

3. The method according to claim 1, characterized in that After acquiring the first device identification of the electronic device and before acquiring the first role identification of the target role, the method further includes: Determining whether the target role has a second role identifier, where the second role identifier is different from the first role identifier; If the target role has the second role identifier, searching the permission corresponding to the second role identifier and the first device identifier in the permission group, and if a second target permission corresponding to the second role identifier and the first device identifier is found, determining that the target role has the second target permission on the electronic device, so that the target role can perform an operation corresponding to the second target permission on the electronic device, and the second target permission is a different permission from the first target permission; If the target role does not have the second role identifier, or if the permission corresponding to the second role identifier and the first device identifier is not found in the permission group, the step of obtaining the first role identifier of the target role is performed.

4. The method according to claim 1, characterized in that The first target permission includes at least one sub-permission, and each sub-permission in the first target permission corresponds to at least one preset role identifier and at least one preset device identifier; After determining that the target role has the first target permission on the electronic device, the method further includes: Among all sub-rights in the first target permission, all first target sub-rights corresponding to the first role identifier and the first device identifier are acquired, so that the target role can perform operations corresponding to the first target sub-rights on the electronic device.

5. The method according to claim 3, characterized in that: The second target permission includes at least one sub-permission, and each sub-permission in the second target permission corresponds to at least one preset role identifier and at least one preset device identifier; After determining that the target role has the second target permission on the electronic device, the method further includes: Among all sub-rights in the second target permission, all second target sub-rights corresponding to the second role identifier and the first device identifier are acquired, so that the target role can perform operations corresponding to the second target sub-rights on the electronic device.

6. A rights management device, characterized in that: Applied to an electronic device, a target role is logged on the electronic device, and the device comprises: A first device identification acquiring unit, configured to acquire a first device identification of the electronic device, wherein the first device identification at least represents a device type of the electronic device; A first role identification obtaining unit, used to obtain a first role identification of the target role; A first permission search unit is used to search for a permission corresponding to the first role identifier and the first device identifier in a permission group, and if a first target permission corresponding to the first role identifier and the first device identifier is found, determine that the target role has the first target permission on the electronic device, so that the target role can perform an operation corresponding to the first target permission on the electronic device; wherein the permission group includes one or more permissions, and each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier; The first permission searching unit is specifically used for: Obtain the first permission in the permission group as the current permission; obtain the preset role identifier and preset device identifier corresponding to the current permission; search whether the first role identifier is included in the preset role identifier corresponding to the current permission; if the first role identifier is found in the preset role identifier corresponding to the current permission, obtain the preset device identifier corresponding to the first role identifier according to the preset device identifier corresponding to the current permission; search whether the first device identifier is included in the preset device identifier corresponding to the first role identifier; if the first device identifier is found in the preset device identifier corresponding to the first role identifier, determine that the current permission is the first target permission corresponding to the first role identifier and the first device identifier; if the first role identifier is not found in the preset role identifier corresponding to the current permission, or if the first device identifier is not found in the preset device identifier corresponding to the first role identifier, obtain the next permission in the permission group as the new current permission, and return to the execution step: obtain the preset role identifier and preset device identifier corresponding to the current permission, and continue to trigger the first permission search unit; The obtaining of the preset role identifier and the preset device identifier corresponding to the current permission includes: obtaining the current permission code corresponding to the current permission; obtaining the preset role identifier corresponding to the current permission according to the different numerical values ​​corresponding to each digit in the current permission code; performing base conversion on the numerical value corresponding to the preset role identifier to obtain a binary number; and obtaining the preset device identifier corresponding to the current permission based on the binary number, wherein each digit in the binary number corresponds to a device identifier.

7. An electronic device, characterized in that: The target role is logged into the electronic device, including: A memory, used to store a computer program and data generated by the execution of the computer program; A processor, configured to execute the computer program to implement: obtaining a first device identifier of the electronic device, the first device identifier at least representing the device type of the electronic device; obtaining a first role identifier of the target role; searching for a permission corresponding to the first role identifier and the first device identifier in a permission group, and if a first target permission corresponding to the first role identifier and the first device identifier is found, determining that the target role has the first target permission on the electronic device, so that the target role can perform an operation corresponding to the first target permission on the electronic device; wherein the permission group contains one or more permissions, each permission in the permission group corresponds to at least one preset role identifier and at least one preset device identifier; searching for a permission corresponding to the first role identifier and the first device identifier in the permission group includes: obtaining a first permission in the permission group as a current permission; obtaining a preset role identifier corresponding to the current permission; identification and preset device identification; searching whether the first role identification is included in the preset role identification corresponding to the current permission; if the first role identification is found in the preset role identification corresponding to the current permission, obtaining the preset device identification corresponding to the first role identification according to the preset device identification corresponding to the current permission; searching whether the first device identification is included in the preset device identification corresponding to the first role identification; if the first device identification is found in the preset device identification corresponding to the first role identification, determining that the current permission is the first target permission corresponding to the first role identification and the first device identification; if the first role identification is not found in the preset role identification corresponding to the current permission, or if the first device identification is not found in the preset device identification corresponding to the first role identification, obtaining the next permission in the permission group as the new current permission, and returning to the execution step: obtaining the preset role identification and preset device identification corresponding to the current permission; The obtaining of the preset role identifier and the preset device identifier corresponding to the current permission includes: obtaining the current permission code corresponding to the current permission; obtaining the preset role identifier corresponding to the current permission according to the different numerical values ​​corresponding to each digit in the current permission code; performing base conversion on the numerical value corresponding to the preset role identifier to obtain a binary number; and obtaining the preset device identifier corresponding to the current permission based on the binary number, wherein each digit in the binary number corresponds to a device identifier.

8. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the rights management method as described in any one of claims 1 to 5 is implemented.

9. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the rights management method as described in any one of claims 1 to 5 are implemented.

Images