WO2024120316A1

WO2024120316A1 - System operation permission method and apparatus, and computer device and storage medium

Info

Publication number: WO2024120316A1
Application number: PCT/CN2023/135936
Authority: WO
Inventors: 陈泉富; 吴冬; 陈凯浩; 滕睿; 黄旭; 黄桢雄
Original assignee: 顺丰科技有限公司
Priority date: 2022-12-05
Filing date: 2023-12-01
Publication date: 2024-06-13
Also published as: CN118153010A

Abstract

A system operation permission method and apparatus, and a computer device and a storage medium. The system operation permission method comprises: acquiring login end information of an operator when logging in to a system of the current login end, wherein the login end information is used for representing the terminal type of the current login end; determining a permission authority of the operator according to identity information and the login end information of the operator; and acquiring an operation instruction of the operator, and on the basis of the permission authority, permitting the operation instruction of the operator. When authority permission for a user (i.e. an operator) is conducted, on the basis of both identity information of the user and login end information of the user, the authority possessed by the user at different login ends can be flexibly permitted, and if the user does not possess an operation instruction authority requested by the user, a corresponding operation cannot be performed. Therefore, operations of a user at different login ends can be flexibly permitted so as to adapt to diversified access modes of an information system, thereby improving the usage experience of the user.

Description

System operation permission method, device, computer equipment and storage medium

Technical Field

The present application belongs to the field of computer technology, and in particular, relates to a system operation permission method, device, computer equipment and storage medium.

Background of the Invention

At present, people's access to information systems has become more diverse. In the past, information processing mostly relied on computer clients. With the popularization of smart phones, people's way of processing information has also shifted from computers to mobile phones. However, in most cases, users only have the authority to process information on computer clients. When processing information on mobile phones, they often cannot process the corresponding information because the mobile phone does not have the authority, which reduces the user experience.

Summary of the invention

The embodiments of the present application provide a system operation permission method, apparatus, computer equipment and storage medium, which can adapt to the diverse access modes of the information system, thereby improving the user experience.

In a first aspect, an embodiment of the present application provides a system operation permission method, comprising: obtaining login information when an operator logs into the system of the current login end, wherein the login information is used to characterize the terminal type of the current login end; determining the operator's permission authority based on the operator's identity information and login information; obtaining the operator's operation instructions, and in combination with the permission authority, permitting the operator's operation instructions.

In an optional embodiment, the operator's permission rights are determined based on the operator's identity information and login information, including: determining the role type corresponding to the operator based on the identity information; determining the permission rights that the role type has for the current login based on the role type and login information through the correspondence between the role type, login information and permission rights.

In an optional embodiment, according to the role type and login information, the permission permissions possessed by the role type at the current login are determined through the correspondence between the role type, login information and permission permissions, including: according to the role type and login information, reading the role and permission correspondence table to obtain the permission ID of the role type at the current login; according to the permission ID, reading the query permission information table to obtain the permission name corresponding to the permission ID; based on the permission name, determining the permission permissions possessed by the role type at the current login.

In an optional embodiment, the operator's permission rights are determined based on the operator's identity information and login information, including: determining the role type corresponding to the operator based on the identity information; determining the permission level corresponding to the role type at the current login based on the role type and login information through the correspondence between the role type, login information and permission level; and determining, based on the permission level, at least one permission below the permission level as the operator's permission.

In an optional embodiment, the permission includes: at least one of function usage permission and data access permission, wherein function usage permission is the operator's permission to execute corresponding functions on the system page, and data access permission is the operator's permission to query data on the system page.

In the second aspect, an embodiment of the present application provides a system operation permission device, including: an acquisition module, used to obtain the login terminal information when the operator logs into the system of the current login terminal, wherein the login terminal information is used to characterize the terminal type of the current login terminal; an authority determination module, used to determine the operator's permission according to the operator's identity information and login terminal information; an authority permission module, used to obtain the operator's operation instructions, and in combination with the permission authority, permit the operator's operation instructions.

In a third aspect, an embodiment of the present application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, the system operation permission method described in the first aspect above is implemented.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the system operation permission method described in the first aspect is implemented.

In the system operation permission method provided in the embodiment of the present application, when the user (i.e., operator) permission is performed, the user's identity information and the user's login terminal information can be combined at the same time to flexibly permit the user's permissions at different login terminals. If the user does not have the requested operation instruction permission, the corresponding operation cannot be performed. Therefore, through the above-mentioned system operation permission method, the user's operations at different login terminals can be flexibly permitted to adapt to the diverse access methods of the information system, thereby improving the user's experience.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art 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.

FIG1 is a schematic diagram of a scenario of a system operation permission system provided in an embodiment of the present application.

FIG2 is a flow chart of a system operation permission method provided in an embodiment of the present application.

FIG. 3 is a schematic diagram of a process for obtaining identity information provided by an embodiment of the present application.

FIG4 is a flow chart of a system operation permission method provided in another embodiment of the present application.

FIG5 is a schematic diagram of a permission management page provided in an embodiment of the present application.

FIG6 is a schematic diagram of the structure of a system operation permission device provided in an embodiment of the present application.

FIG. 7 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.

FIG8 is a schematic diagram of the structure of a computer storage medium provided in an embodiment of the present application.

Mode for Carrying Out the Invention

At present, people's access to information systems has become more diverse. In the past, information processing mostly relied on computer clients. With the popularity of smart phones, people's way of processing information has also shifted from PC to mobile phones. However, when granting permissions, most systems do not consider flexible permissions for different login terminals. For example, most permission identification methods are not designed to consider permission identification for mobile phones. Although some authentication methods take into account the existence of multi-terminal access, they do not provide flexible permissions for users on different login terminals.

Therefore, the present application proposes a system operation permission method, which can flexibly permit users to operate at different login terminals, and can also avoid system risk problems caused by lack of permission control, thereby improving the flexibility and security of the system.

In order to illustrate the technical solution of the present application, specific embodiments are provided below.

As shown in FIG. 1 , FIG. 1 is a schematic diagram of a scenario of a system operation permission system provided in an embodiment of the present application. The system operation permission system may include a computer device 140 and multiple terminal devices 110 , 120 , and 130 .

The terminal devices 110, 120, 130 may be mobile terminal devices such as mobile phones, game consoles, tablet computers, or the terminal devices 110, 120, 130 may also be personal computers (PCs), such as laptop computers and desktop computers. Those skilled in the art will appreciate that the types of the terminal devices 110, 120, 130 may be the same or different, and the number may be more or less. For example, the number of the terminals may be one each, or the number of the terminals may be dozens or hundreds, or more. The embodiments of the present application do not limit the number of terminals and the type of devices.

The computer device 140 may be a server. For example, the computer device 140 may be an independent server, or a server network or server cluster composed of servers. For example, the computer device 100 includes but is not limited to a computer, a network host, a single network server, a plurality of network server sets, or a cloud server constructed by a plurality of servers. A cloud server is constructed by a large number of computers or network servers based on cloud computing.

The terminal devices 110, 120, 130 and the computer device 140 are connected via a communication network. Optionally, the communication network is a wired network or a wireless network.

The terminal devices 110, 120, and 130 in the embodiment of the present application are mainly used for operators to initiate calls, for example, the operator initiates logging into the system of the current login terminal, or the operator initiates viewing the permission, or the operator initiates executing an operation instruction, etc. The computer device 140 in the embodiment of the present application is mainly used to execute a system operation permission method when the operator at the terminal devices 110, 120, and 130 initiates a call. The specific content of the system operation permission method can be found in the description below. The system operation permission method can adapt to the diverse access methods of the information system, thereby improving the user experience.

In one example, a system operation permission device is integrated in the computer device 140 to execute the system operation permission method described below.

Those skilled in the art will appreciate that the application environment shown in FIG. 1 is merely an application scenario of the present application scheme, and is not intended to constitute a limitation on the application scenario of the present application scheme. Other application environments may also include more or fewer computer devices than those shown in FIG. 1 . For example, only one computer device is shown in FIG. 1 , and it is understandable that the system operation permission system may also include one or more other computer devices, which are not specifically limited here.

It should be noted that the scenario diagram of the system operation permission system shown in Figure 1 is merely an example. The risk warning system and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of the system operation permission system and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

The system operation permission method provided by the embodiment of the present application is described in more detail below in conjunction with Figures 2 to 5. The system operation permission method provided by the embodiment of the present application can be executed by the computer device 100 (e.g., the system operation permission device) shown in Figure 1. For the sake of simplicity and ease of description, the execution subject will be omitted in the subsequent method embodiments.

Referring to FIG. 2 , a flow chart of an embodiment of a system operation permission method is shown, which is used as an example but not as a limitation, and includes the following steps:

Step S1: obtaining the login terminal information when the operator logs into the system of the current login terminal, wherein the login terminal information is used to characterize the terminal type of the current login terminal;

Step S2: Determine the permission of the operator according to the identity information and login terminal information of the operator;

Step S3: Acquire the operation instruction of the operator, and authorize the operation instruction of the operator in combination with the permission authority.

The login terminal information refers to the terminal type used by the operator to log in to the system, for example, a mobile client or a computer client. Obtaining the login terminal information when the operator logs in to the system means obtaining whether the operator logs in on a computer client or a mobile client.

When granting permissions to users (i.e., operators), the user's identity information and the user's login terminal information can be combined at the same time to flexibly grant permissions to the user at different login terminals. If the user does not have the permissions corresponding to the operation instructions requested by the user, the corresponding operation cannot be performed. Therefore, through the above-mentioned system operation permission method, the user's operations at different login terminals can be flexibly permitted to adapt to the diverse access methods of the information system, thereby improving the user's experience. In addition, through the above-mentioned system operation permission method, system risk problems caused by the lack of permission control can also be avoided, thereby improving the flexibility and security of the system.

In an optional embodiment, the system operation permission method proposed in the present application can be used for a customer relationship management system with role-based permission control. In order to better understand the present application, first of all, a brief introduction to the customer relationship management system is given. The Customer Relationship Management (CRM) system refers to an information system that uses software, hardware and network technology to establish an enterprise to collect, manage, analyze and utilize customer information. With the management of customer data as the core, it records the various interactive behaviors that occur between the enterprise and the customer during the marketing and sales process, as well as the status of various related activities, and provides various data models to provide support for subsequent analysis and decision-making.

A good customer relationship management system cannot do without flexible control of permissions. Therefore, the system operation permission method proposed in this application can adopt role-based permission control (RBAC). Role-based permission control refers to indirectly granting user permissions by associating users with roles and roles with permissions. After a user is assigned a role, he or she will obtain all permissions under the role. With the addition of the role relationship, you only need to define permissions for the role and then assign users with the same permissions to the same role, which is convenient to use; and when you need to adjust the user's permissions, When making batch adjustments, you only need to adjust the permissions corresponding to the roles associated with the users. There is no need to adjust permissions for every user. This greatly improves the efficiency of permission adjustment and reduces the probability of missing permissions.

Referring to FIG. 3 , a process of obtaining identity information provided in an embodiment of the present application is shown, which is provided as an example but not as a limitation, and includes the following contents.

S11: Obtaining the account information and login verification information input by the operator on the system login interface.

The account information may be the user ID or user email address entered by the operator when logging into the system, and the login verification information may be the account password, dynamic email verification code or voice verification code entered by the operator when logging into the system.

S12: Verify the operator's login operation based on the account information and login verification information.

S13: When the operator's login operation verification is passed, the operator's identity information is determined based on the account information.

In a possible embodiment, when the operator's login operation verification is passed, a preset user identity information table is read according to the account information to determine the operator's identity information.

The user identity information table includes the mapping relationship between the user's account information and the user's identity information. According to the user's account information, the unique corresponding user's identity information can be determined. By determining the user's identity information through the user's account information, the operator does not need to enter sensitive personal identity information, such as ID card number, when logging into the system, thereby avoiding the leakage of personal information.

In other possible embodiments, when the operator logs into the system, he can also directly enter his identity information for verification, for example, he can enter his ID number and verify it through fingerprint or face recognition. The above login verification method is only for exemplary purposes, and this application includes but is not limited to this.

The above process is explained below in conjunction with specific usage scenarios. Take the example of a user entering a mobile phone number to log in to the system. For the user, when the user enters the mobile phone number on the login interface, he or she can choose to log in by password verification or by dynamic mobile phone verification code verification. For the computer device, the above mobile phone number and password can be obtained, or the system obtains the above mobile phone number and verification code and performs verification. If the verification is successful, that is, the system can be logged in by password verification or by dynamic mobile phone verification code verification, the user's identity information is determined based on the mobile phone number when the user logs in to the system, that is, the mobile phone number used by the user to log in to the system is read from the user identity information table.

The user identity information table is shown in Table 1, which includes: user ID (USER ID), user work number (EMP CODE), user name (USER NAME), user email (EMAIL), user phone (PHONE), user ID number (ID NUM) and user organization (ORG). According to the mobile phone number used by the operator to log in to the system, when reading the identity information of the current login account (i.e., the operator) in the user identity information table, only USER ID can be determined. It should be noted that USER ID and user have a one-to-one correspondence.

For example, if user Chen xx uses his mobile phone number 134xxxx5678 to log in to the system, then based on the mobile phone number 134xxxx5678, the USER ID corresponding to the mobile phone number 134xxxx5678 is read as 1 in the user identity information table.

By using the mobile phone number used by the user when logging into the system, the user ID corresponding to the mobile phone number used by the user to log into the system is read in the user identity information table, and the identity information of the user who logged into the system can be determined.

Table 1

Referring to FIG. 4 , a process of step S2 provided in an embodiment of the present application is shown, which is provided as an example but not as a limitation, and includes the following contents.

S21: Determine the role type corresponding to the operator according to the identity information of the operator.

In a possible embodiment, the role type of the current operator (ie, the operator) is read from the identity-role correspondence table according to the operator's identity information. The identity-role correspondence table includes the correspondence between the user's identity information and the role type.

Exemplarily, the user role types include: system administrator, headquarters administrator, regional administrator, sales manager, account manager, branch salesperson or courier, etc.

In an optional embodiment, the role type of the user can be configured in advance, or it can be flexibly configured as needed. Exemplarily, the flexible configuration of the role type of the user may include the following two methods: adding roles to users and adding users to roles. Adding roles to users means that the computer device (i.e., the backend) obtains the role granted to a certain user by the developer on the user management page. For example, the backend may obtain multiple roles added to the user at one time by the developer on the user management page. Adding users to roles means that the backend obtains multiple users selected by the developer on the role management page for a certain role, thereby achieving the purpose of granting roles to batches of users.

It should be noted that the above-mentioned developers have code development capabilities, and they play the role of administrators on the back end, configuring permissions for users or operators, and users or operators are users who log in to the system on the front end and perform corresponding operations according to corresponding permissions.

The identity and role correspondence table is shown in Table 2, which includes: the mapping relationship between user ID (USER ID) and role ID (ROLE_ID). Exemplarily, according to the operator's USER ID, the operator's ROLE_ID is read in the identity and role correspondence table.

Further, the user role information table is shown in Table 3, which includes: role ID (ROLE_ID) and role type (ROLE_TYPE). Exemplarily, according to ROLE_ID, the user role information table is read to determine the role type of the user.

The above process is explained below in conjunction with a specific usage scenario. Taking the user with USER ID 1 as an example, according to the USER ID, read Table 2, and you can get that the ROLE_ID corresponding to the user with USER ID 1 is 1. Further, according to the ROLE_ID, read Table 3, and you can get that the ROLE_TYPE of ROLE_ID 1 is the regional administrator. Through the above process, it can be determined that the ROLE_TYPE corresponding to the user with USER ID 1 is the regional administrator.

Through the user ID, the role ID corresponding to the user ID of the current login person (i.e., operator) is read in the identity and role correspondence table, and through the role ID, the role type is read in the user role information table, thereby determining the role type of the current user (i.e., operator) who has logged into the system.

Table 2

table 3

S22: According to the role type and the login terminal information, the permission permissions possessed by the role type at the current login terminal are determined through the correspondence between the role type, the login terminal information and the permission permissions.

The correspondence between the role type, the login terminal information and the permission can be stored in the database in the form of at least one of a role-permission correspondence table and a query permission information table.

The table of roles and permissions is shown in Table 4, which includes: the mapping relationship between role ID (ROLE_ID), permission ID (PERMISSION_ID) and effective end (EFFECTIVE END). The table of query permission information is shown in Table 5, which includes: permission ID (PERMISSION_ID), parent node ID (PARENT_ID), permission name (PERMISSION_NAME), resource type (SOURCE_TYPE) and module type (MODULE_TYPE). In a possible embodiment, according to the user's role type and login end information, the table of roles and permissions is read to determine the permission that the role type has at the current login end.

However, reading the role and permission correspondence table can only obtain the permission ID (PERMISSION_ID) of the permission that the role type has at the current login end. Therefore, in order to determine the specific content of the permission that the role type has at the current login end, you can also read the query permission information table.

Table 4

table 5

The above process is explained below in conjunction with specific usage scenarios. Taking ROLE_ID as 1 as an example, according to ROLE_ID, by reading the role and permission correspondence table, it can be obtained that if the current login end is the mobile end (that is, the effective end is the App end), then this role type has the permission permissions of PERMISSION_ID 1 and 2 on the App end. If the current login end is the computer end (that is, the effective end is the PC end), then this role type only has the permission permission of PERMISSION_ID 1 on the PC end. Further, according to PERMISSION_ID, by reading the query permission information table, it can be obtained that the permission name corresponding to PERMISSION_ID 1 is View Customer File Management, that is, the permission permissions possessed by this role type include the permission permission to view the menu of Customer File Management, and the permission name corresponding to PERMISSION_ID 2 is View Customer List, and the permission permissions possessed by this role type also include the permission permission to view the function of View Customer List. Through the above process, it can be determined that the permissions owned by the role type with ROLE_ID 1 include: permission to use the customer profile management menu and permission to view the customer list on the App side, and only permission to view the customer list on the PC side.

In the above implementation, the role is used as an intermediary to first determine the user's role type, and then determine the user's permissions based on the role type and login information. The reason for this operation is that the RBAC permission model is based on five basic tables in the database, including: (1) User table (USER), used to store user identity information; (2) Role table (ROLE), used to store role information; (3) Permission table (PERMISSION), used to store permission information; (4) Permission and role association table (PERMISSION_ASSIGNMENT, PA), used to store the correspondence between roles and permissions; (5) User and role association table (USER_ASSIGNMENT, UA), used to store the correspondence between users and roles. The advantage of such a configuration is that roles and permissions are in a many-to-many relationship, that is, a role can have multiple permissions, and the same permission can be granted to multiple roles. Therefore, the permission configuration process is simpler and more flexible.

Since the process of computer equipment configuration is to configure permissions to roles and roles to users, roles can also be used to establish the relationship between users and permissions in the process of granting permissions. When granting permissions, multiple permissions corresponding to the role can be granted at one time, without having to grant each permission separately, which makes the operation easier.

In other optional implementations of the present application, the permission can also be uniquely matched to the user's unique identifier or identity information, that is, the permission for each person can be the same or different. The permission corresponds to the unique identifier or identity information, rather than the role type, so that the permission for each user can be uniquely customized, which is not described in detail in this application.

In the implementation mode that can be realized in the present application, through step S22, the permission rights possessed by the role type at the current login end can be obtained, that is, this is only the permission of the permission level corresponding to the role type at the current login end. Therefore, in order to obtain the permission rights of operators in batches, it is also possible to determine the permission level corresponding to the role type at the current login end based on the role type and login end information and the correspondence between the role type, login end information and the permission level; according to the permission level, determine at least one permission below the permission level as the operator's permission.

It should be understood that steps S21 and S22 are implementation methods for obtaining the operator's permission rights, and the above-mentioned determination of at least one permission below the permission level based on the permission level is also an implementation method for obtaining the operator's permission rights. These two implementation methods do not conflict, that is, these two implementation methods can exist at the same time.

In an optional embodiment, each permission level includes at least one permission, and the permission levels are in an inclusive relationship, that is, the first permission level includes all permissions in the second permission level, the second permission level includes all permissions in the third permission level, and so on.

Therefore, by using the role type and login information to determine the user's permission level, there is no need to determine the user's permissions one by one. As long as the permission level is determined, all permissions of the user are determined. This method is efficient and fast.

In an optional embodiment, the permission level can be set as needed, and only the relationship between the two permission levels is used as an example here. Specifically, the two permission levels include a primary permission level and a secondary permission level. When the permission level of the operator at the current login terminal is the secondary permission level, the operator has the permission under the secondary permission level; when the permission level of the operator at the current login terminal is the primary permission level, the operator has at least one permission under the secondary permission level (for example, all permissions under the secondary permission level) in addition to the permission under the primary permission level.

For example, the permission permissions under the second-level permission level include the permission to view customer information, and the permission permissions under the first-level permission level include the permission to create, modify and delete customer information; if user A has the second-level permission level on the computer client, then when he logs into the system on the computer client, he will have the right to view customer information; if user B has the first-level permission level on the computer client, then when he logs into the system on the computer client, he will have the right to view customer information and the right to create, modify and delete customer information; if user C has the second-level permission level on the mobile client and the first-level permission level on the computer client, then when he logs into the system on the mobile client, he can only view customer information but cannot create, modify and delete user information. Modification and deletion. When they log in to the system on a computer client, they have the right to view customer information, and have the right to create, modify and delete customer information.

In an implementation manner that can be realized in the present application, the permission includes at least one of function use permission and data access permission.

For example, the function usage permission includes the permission to view the function menu. In an optional embodiment, after the user logs in to the system, the computer device (i.e., the back end) can directly determine whether the user has the permission to view the function menu based on the identity information and the login terminal information. If the user has the permission to view the function menu, an instruction to display the function menu under the corresponding permission is sent to the terminal device (i.e., the front end), and accordingly, the front end displays the function menu under the corresponding permission for the user.

In other optional embodiments, after the user logs in to the system, the backend can determine the permission that the role type corresponding to the operator has at the current login terminal through the correspondence between the role type, the login terminal information and the permission. If the permission is the permission to view the function menu, the backend sends an instruction to display the function menu under the corresponding permission to the frontend, and accordingly, the frontend displays the function menu under the corresponding permission for the user. Exemplarily, if the backend determines that the role type of the user is an account manager, and the account manager has the permission to view the customer management menu, then the frontend sends an instruction to display the customer management menu, and accordingly, the frontend displays the customer management menu for the user; if the backend determines that the role type of the user is a courier, and the courier has the permission to view the order management menu, then the frontend sends an instruction to display the order management menu, and accordingly, the frontend displays the order management menu for the user; if the backend determines that the role type of the user is a sales manager, and the sales manager has the permission to view the supplier management menu, then the frontend sends an instruction to display the supplier management menu, and accordingly, the frontend displays the supplier management menu for the user.

Furthermore, in an optional embodiment, the function usage permission also includes the permission to use the function button.

Exemplarily, the function button includes at least one of a view button, a new button, a modify button, a delete button, and an audit button. For example, when in use, the user clicks the delete button, the backend receives the click instruction sent by the frontend, and verifies whether the function usage permission of the user's role type at the current login end includes the permission to use the delete button. If the function usage permission of the role type at the current login end includes the permission to use the delete button, the user is permitted to execute the operation instruction of the delete button, and accordingly, the user can proceed to the next step; if the function usage permission of the role type at the current login end does not include the permission to use the delete button, a prompt of no permission is sent to the frontend, and correspondingly, the frontend prompts the user that he does not have the permission to delete the button.

In the above embodiment, although the user can see certain buttons on the system page after logging into the system, the user may not have the authority to perform corresponding operations on these buttons. Therefore, this can be optimized. That is, in another possible implementation, only an instruction to display the buttons for which the user has the authority is sent to the front end. That is, on the system page, the buttons for which the user does not have the authority will be hidden to achieve the purpose of "visible and operable". It should be understood that "visible and operable" means that if the user can see the button on the system page, the user can perform corresponding operations on the button. To achieve the purpose of "visible and operable", it can also be achieved through the cooperation of the front end. For example, the front end caches the user's authority information, and the back end determines whether the user has the corresponding authority based on the authority information. If the user has the corresponding authority, an instruction to display the button corresponding to the authority is sent to the front end. Correspondingly, the front end displays the button corresponding to the authority to the user; if the user does not have the authority, the back end determines whether the user has the corresponding authority. If there is corresponding permission, no instruction to display the button corresponding to the permission is sent to the front end, that is, the button corresponding to the permission will be hidden on the system page.

In an optional embodiment, the data access permission includes at least one of permission to access a data type and permission to access a data range.

Exemplarily, the data types include: at least one of customer data, business opportunity data, and contract data, and the data range includes: at least one of data I created, data I collaborated with, data of my subordinates, data of my authorized area, and data of my authorized industry.

In an optional embodiment, different role types have different data access permissions, so even on the same page of the system, users of different role types may see different data.

For example, when the courier, regional administrator and headquarters administrator request to view the customer list in the system, the front end will send an instruction to the back end requesting to view the customer category. Accordingly, the back end will send different data to the front end according to the different role types corresponding to each user, so as to display different data in the system. For example, the courier can see the customer list under his name, the regional administrator can see the customer list in the authorized area, and the headquarters administrator can see the customer list of all areas.

By dividing the permission into function usage permission and data access permission, you can flexibly permit function usage permission and data access permission separately, so that different role types have different function usage permission and data access permission at different login ends. Therefore, the permission of permissions becomes more flexible.

In other possible implementations, only function usage rights may be included. When a user is permitted to use a certain function, all data related to the function are permitted to be operated by the user.

In a possible implementation, the permissions corresponding to each role type can be configured in advance or flexibly configured as needed. For example, flexibly configuring the correspondence between role types and permissions includes: configuring different permissions for different role types on the front-end permission management page, and configuring the corresponding effective end (i.e., App end or PC end) for the permissions.

Exemplarily, on the permission management page, the developer first selects the role type of the regional administrator. At this time, the backend determines the role type as the regional administrator. Next, the developer checks the function usage permission to view the customer list, and selects the effective end as the mobile phone and the computer. At this time, the backend determines that the function usage permission corresponding to the role type of the regional administrator is to view the customer list and determines the effective end as the mobile phone and the computer. Next, the developer selects the data range that can be viewed by the role type of the regional administrator as the customer information in the region, and selects the effective end as the mobile phone and the computer. At this time, the backend determines that the data range that can be viewed by the role type of the regional administrator is the customer information in the region and the effective end is the mobile phone and the computer.

Through the above permission configuration process, users with the role type of regional administrator can have the following permissions: they can view the customer list on the computer and mobile phone, and the scope of the customer list viewed is all customer information in the region.

In the permission management page, you can also flexibly configure the permissions for using the function buttons. As shown in Figure 5, in the data permission management page, the developer selects the role of account manager. At this time, the backend determines the role type as account manager and checks the view, modify and delete functions for customer data. At this time, the backend determines that the account manager can view, modify and delete customer data. For business opportunity data, check the view, modify and delete functions. At this time, the backend determines that the account manager Opportunity data can be viewed, modified, and deleted. For contract data, no function is selected. At this time, the backend determines that the account manager does not do anything with the contract data. Through the above configuration, users with the account manager role type can have the following permissions: view, modify, and delete customer data, view, modify, and delete opportunity data, and do not have any operation permissions on contract data.

In the implementation method that can be realized in the present application, according to the identity information and the login terminal information, the permission of the operator is determined, including: according to the identity information, the role type of the operator is determined; according to the role type and the login terminal information, the corresponding function code and data field of the permission are determined through the correspondence between the preset role type, the login terminal information and the permission; according to the function code and the data field, the function use permission and data access permission of the operator are determined. It should be understood that, as described above, the correspondence between the preset role type, the login terminal information and the permission is stored in the database in the form of at least one of the role and permission correspondence table (i.e., Table 4) and the query permission information table (i.e., Table 5), the function code can be understood as the PERMISSION_ID (permission ID) in Table 4 and Table 5, and the data field can be understood as the permission name (PERMISSION_NAME) in Table 5. In addition, the function code can also be understood as generated by the back end after the user enters a function request on the system page.

Specifically, first read the role and permission correspondence table based on the role type and login information to determine the corresponding permitted function code, then read the query permission information table based on the function code to determine the data field, and finally determine the operator's function usage permission or data access permission based on the function code and data field.

For example, if PERMISSION_ID in Table 4 is 4, which corresponds to the function code, and the data field is "My" in Table 5, then the operator's permission is the data access right, that is, querying the data created by himself. For another example, if PERMISSION_ID in Table 4 is 2, which corresponds to the function code, and the data field is "View Customer List" in Table 5, then the operator's permission is the function use right, that is, the function of viewing the customer list.

In the implementation method that can be realized in this application, the backend determines the user's role type based on the identity information. When the user enters a function request on the system page, the backend will generate a function code corresponding to the function request. For function usage permissions, the backend reads the role and permission correspondence table through the function code to determine whether the user's role type has the permission corresponding to the function code, that is, whether the user has the permission to perform this function. If the user's role type has the permission corresponding to the function code, it means that the user has the permission to operate this function; if the user's role type does not have the permission corresponding to the function code, it means that the user does not have the permission to operate this function. For data access rights, the backend uses the function code to read the role and permission correspondence table to determine whether the user's role type has the permission corresponding to the function code, that is, whether the user has the permission to access the data. If the user's role type has the permission corresponding to the function code, it means that the user has data access rights. The backend then reads the query permission information table based on the function code to determine the data field. Finally, based on the relationship between the data resource table and the data field, it reads the data type and data range that the user is allowed to access, and sends the data type and data range to the front end for user access. If the user's role type does not have the permission corresponding to the function code, it means that the user has no data access rights. It should be understood that the data resource table is used to store data of a certain data type and data range. For example, if the data field is "my" and the data type is customer data, the user's data access rights are my customer data.

In an implementation method that can be implemented in the present application, step S3 may include: obtaining the function code corresponding to the operation instruction input by the operator, and determining whether there is function usage permission corresponding to the function code in the permission permissions; if there is function usage permission corresponding to the function code in the permission permissions, based on the function usage permission, permitting the operator's operation instruction.

In an implementation method that can be realized in the present application, step S3 may also include: obtaining the function code corresponding to the operation instruction input by the operator, and determining whether there is data access permission corresponding to the function code in the permission authority; if there is data access permission corresponding to the function code in the permission authority, based on the data access permission, reading the data resource table to permit the operator's operation instruction.

There will be a data field in the data access permission. For example, if the data access permission is my customer data, the data field will be "my". Therefore, based on the data field in the data access permission, the data resource table can be read to obtain the data type (i.e., customer data) and data range (i.e., my) of the data access permission.

In addition, after determining the user's function usage permissions, the backend can also obtain the data field requested by the user, and then read the data resource permission table based on the data field to determine the user's data access permissions under the current function usage permissions.

The method embodiment of the present application is described in detail above in conjunction with Figures 1 to 5, and the device embodiment of the present application is described in detail below in conjunction with Figures 6 and 7. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so the part not described in detail can refer to the previous method embodiment.

As shown in FIG. 6 , the system operation permission device 600 includes: an acquisition module 601 , a permission determination module 602 , and a permission permission module 603 .

The acquisition module 601 is used to acquire the login terminal information when the operator logs into the system of the current login terminal, wherein the login terminal information is used to characterize the terminal type of the current login terminal.

The authority determination module 602 is used to determine the permission of the operator according to the identity information and login terminal information of the operator.

The permission module 603 is used to obtain the operation instruction of the operator and permit the operation instruction of the operator in combination with the permission authority.

When granting permissions to users (i.e., operators), the user's identity information and the user's login terminal information can be combined to flexibly grant permissions to the user at different login terminals. If the user does not have the permissions corresponding to the requested operation instruction, the corresponding operation cannot be performed. Therefore, through the above-mentioned system operation permission device, the user's operations at different login terminals can be flexibly permitted to adapt to the diverse access methods of the information system, thereby improving the user's experience. In addition, through the above-mentioned system operation permission device, system risk problems caused by the lack of permission control can also be avoided, thereby improving the flexibility and security of the system.

In some embodiments of the present application, the authority determination module 602 is specifically used to: determine the role type corresponding to the operator based on identity information; determine the permission permissions that the role type has at the current login end based on the role type and login end information through the correspondence between the role type, login end information and permission permissions.

In some embodiments of the present application, when the authority determination module 602 determines the permission that the role type has for the current login terminal according to the role type and the login terminal information, through the correspondence between the role type, the login terminal information and the permission, Specifically used for: reading the role and permission correspondence table according to the role type and login information, and obtaining the permission ID of the role type at the current login; reading the query permission information table according to the permission ID, and obtaining the permission name corresponding to the permission ID; based on the permission name, determining the permission that the role type has at the current login.

In some embodiments of the present application, the authority determination module 602 is specifically used to: determine the role type corresponding to the operator based on identity information; determine the authority level corresponding to the role type at the current login end through the correspondence between the role type, login end information and authority level based on the role type and login end information; and determine, based on the authority level, at least one authority below the authority level as the operator's permitted authority.

In some embodiments of the present application, the permission includes: at least one of function usage permission and data access permission, wherein function usage permission is the permission of the operator to execute the corresponding function on the system page, and data access permission is the permission of the operator to query data on the system page.

In some embodiments of the present application, the function usage permission includes at least one of the permission to use the function button and the permission to view the function menu.

In some embodiments of the present application, the data access permission includes at least one of permission to access a data type and permission to access a data range.

In some embodiments of the present application, the permission permission module 603 is specifically used to: obtain the function code corresponding to the operation instruction input by the operator; determine whether there is function usage permission corresponding to the function code in the permission permissions; if there is function usage permission corresponding to the function code in the permission permissions, based on the function usage permission, permit the operator's operation instruction.

In some embodiments of the present application, the permission permission module 603 is specifically used to: obtain the function code corresponding to the operation instruction input by the operator; determine whether there is data access permission corresponding to the function code in the permission permission; if there is data access permission corresponding to the function code in the permission permission, based on the data access permission, read the data resource table to permit the operator's operation instruction, wherein the data resource table is used to store data.

In some embodiments of the present application, the system operation permission device 600 also includes: a verification module, which is used to obtain the account information and login verification information entered by the operator in the system login interface, and verify the operator's login operation based on the account information and login verification information; if the operator's login operation verification is passed, the operator's identity information is determined based on the account information.

The system operation permission device shown in FIG. 6 may also exist in other module components, which are not limited here, as long as the corresponding functions can be achieved.

In addition, what is shown in FIG. 6 is only one embodiment of the system operation permission device, not all embodiments. Based on the embodiment of the system operation permission device in this application, all other embodiments obtained by those skilled in the art without making any creative work are within the scope of protection of this application.

FIG7 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. The computer device 700 includes: at least one processor 701 (only one processor is shown in FIG7 ), a memory 702, and a computer program 703 stored in the memory 702 and running on at least one processor 701. When the processor 701 executes the computer program 703, the above-mentioned system operation permission method is implemented.

The computer device may include, but is not limited to, a processor 701 and a memory 702. Those skilled in the art will appreciate that FIG. 7 is merely an example of a computer device 700 and does not limit the computer device 700. The computer device 700 may include more or fewer components than shown in the figure, or may combine certain components, or may include different components, such as an input/output device or a network access device.

The processor 701 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

In some embodiments, the memory 702 may be an internal storage unit of the computer device 700, such as a hard disk or memory of the computer device 700. In other embodiments, the memory 702 may also be an external storage device of the computer device 700, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card or a flash card (Flash Card) equipped on the computer device 700. Further, the memory 702 may also include both an internal storage unit of the computer device 700 and an external storage device of the computer device 700. The memory 702 is used to store an operating system, an application program, a boot loader (BootLoader), data and other programs, such as program code of a computer program. The memory 702 may also be used to temporarily store data that has been output or is to be output.

In addition, FIG. 7 shows only one embodiment of a computer device, rather than all embodiments. All other embodiments obtained by those skilled in the art based on the computer device embodiment in this application without any creative work shall fall within the scope of protection of this application.

Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the division of the above modules is used as an example for illustration. In actual applications, the above functions can be assigned to different modules as needed, that is, the internal structure of the device can be divided into different modules to complete all or part of the functions described above. The modules in the above embodiments can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the modules in the above device can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

8 , an embodiment of the present application further provides a computer-readable storage medium 800 , which stores a computer program 801 , and when the computer program 801 is executed by a processor, the above-mentioned system operation permission method is implemented.

The computer program 801 includes computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer readable storage medium 800 may at least include: any entity or device capable of carrying the computer program code to a terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electric carrier signal, a telecommunication signal and a software distribution medium, such as a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk.

In addition, FIG. 8 shows only one embodiment of a computer-readable storage medium, rather than all embodiments. All other embodiments obtained by those skilled in the art based on the computer-readable storage medium embodiment in this application without any creative work shall fall within the scope of protection of this application.

An embodiment of the present application provides a computer program product. When the computer program product is executed on a mobile terminal, the mobile terminal executes the above-mentioned system operation permission method.

In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

A system operation permission method, characterized by comprising:

Acquire the login terminal information when the operator logs into the system of the current login terminal, wherein the login terminal information is used to characterize the terminal type of the current login terminal;

Determining the permission of the operator according to the identity information of the operator and the login terminal information;

The operation instruction of the operator is obtained, and the operation instruction of the operator is permitted in combination with the permission.
The system operation permission method according to claim 1, wherein determining the permission authority of the operator according to the identity information of the operator and the login terminal information comprises:

Determining the role type corresponding to the operator according to the identity information;

According to the role type and the login terminal information, the permission permissions possessed by the role type at the current login terminal are determined through the correspondence between the role type, the login terminal information and the permission permissions.
The system operation permission method according to claim 2, characterized in that the determining the permission that the role type has at the current login terminal according to the role type and the login terminal information through the correspondence between the role type, the login terminal information and the permission includes:

According to the role type and the login terminal information, read the role-authority correspondence table to obtain the authority ID of the role type at the current login terminal;

According to the permission ID, read the query permission information table to obtain the permission name corresponding to the permission ID;

Based on the permission name, the permission that the role type has at the current login terminal is determined.
The system operation permission method according to any one of claims 1 to 3, characterized in that the step of determining the permission of the operator according to the identity information of the operator and the login terminal information comprises:

Determining the role type corresponding to the operator according to the identity information;

According to the role type and the login terminal information, through the correspondence between the role type, the login terminal information and the permission level, determine the permission level corresponding to the role type at the current login terminal;

According to the authority level, at least one authority below the authority level is determined as the permitted authority of the operator.
The system operation permission method according to any one of claims 1 to 4 is characterized in that the permission includes: at least one of function usage permission and data access permission, wherein the function usage permission is the permission of the operator to execute the corresponding function on the page of the system, and the data access permission is the permission of the operator to query data on the page of the system.
The system operation permission method according to claim 5, characterized in that the function uses The permission includes at least one of a permission to use a function button and a permission to view a function menu.
The system operation permission method according to claim 5 or 6 is characterized in that the data access permission includes at least one of the permission to access the data type and the permission to access the data range.
The system operation permission method according to any one of claims 1 to 7, characterized in that the obtaining of the operation instruction of the operator and, in combination with the permission authority, permitting the operation instruction of the operator comprises:

Obtaining a function code corresponding to the operation instruction input by the operator;

Determining whether there is a function usage permission corresponding to the function code in the permission;

When the permission rights include the function usage rights corresponding to the function code, the operation instruction of the operator is permitted based on the function usage rights.
The system operation permission method according to any one of claims 1 to 8, characterized in that the obtaining of the operation instruction of the operator and, in combination with the permission authority, permitting the operation instruction of the operator comprises:

Obtaining a function code corresponding to the operation instruction input by the operator;

Determining whether there is data access permission corresponding to the function code in the permission;

In the case that the permission includes data access rights corresponding to the function code, a data resource table is read based on the data access rights to permit the operation instruction of the operator, wherein the data resource table is used to store data.
The system operation permission method according to any one of claims 1 to 9, further comprising:

Acquiring account information and login verification information input by the operator on the login interface of the system, and verifying the login operation of the operator based on the account information and the login verification information;

If the operator's login operation verification is passed, the operator's identity information is determined based on the account information.
A system operation permission device, characterized by comprising:

An acquisition module, used to acquire the login terminal information when the operator logs into the system of the current login terminal, wherein the login terminal information is used to characterize the terminal type of the current login terminal;

An authority determination module, used to determine the permission of the operator according to the identity information of the operator and the login terminal information;

The permission module is used to obtain the operation instruction of the operator and, in combination with the permission authority, permit the operation instruction of the operator.
A computer device, characterized in that it includes a memory, a processor, and a computer program stored in the memory and running on the processor, and when the processor executes the computer program, the system operation permission method according to any one of claims 1 to 10 is implemented.
A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the system operation permission method according to any one of claims 1 to 10 is implemented.