Access permission management method, access permission management device and readable storage medium

Abstract

Provided in the present application are an access permission management method, an access permission management device and a readable storage medium. The access permission management method is applied to a server, comprising: upon receiving user login information sent by a client, calling corresponding local user data on the basis of the user login information; on the basis of the local user data, generating access character strings corresponding to the local user data and sending same to the client; upon receiving the access character strings sent by the client, calling the local user data corresponding to the access character strings; on the basis of the local user data, generating a message header carrying a permission identifier and sending same to an application program; and upon receiving access permission information returned, on the basis of the message header, by the application program, accessing the application program.

Description

Access right management method, access right management device and readable storage medium

[0001] This application claims priority to Chinese patent application No. 202311631437.0 filed on December 1, 2023, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the technical field of electronic digital data processing, and in particular to an access rights management method, an access rights management device, and a readable storage medium. Background Art

[0003] Existing methods for enabling client-side token access to switch applications only consider basic authentication and access control, without considering the division of permissions between different user roles. As a result, most switches only support basic user addition and token-based access, failing to meet the requirements for fine-grained permission control and user rights management.

[0004] Therefore, the commonly used method of accessing switch applications has the defect of being unable to perform fine-grained permission control on switch users and manage user permissions.

[0005] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Technical issues

[0006] The main purpose of this application is to provide an access rights management method, aiming to solve the problem of being unable to manage multiple users of a switch. Technical Solutions

[0007] To achieve the above objectives, this application provides an access rights management method, which is applied to a server. The access rights management method includes the following steps:

[0008] When receiving the user login information sent by the client, calling the corresponding local user data according to the user login information;

[0009] generating, based on the local user data, an access string corresponding to the local user data and sending the access string to the client;

[0010] After receiving the access string sent by the client, calling the local user data corresponding to the access string;

[0011] Generate and send a message header carrying an authorization identifier to the application based on the local user data; and

[0012] When the access permission information returned by the application based on the message header is received, the application is accessed.

[0013] In one embodiment, the step of generating and sending a message header carrying an authorization identifier to the application based on the local user data includes:

[0014] When the permission level of the local user data is basic permission, a message header carrying a first-level permission identifier is generated and sent;

[0015] When the permission level of the local user data is monitoring permission, generating and sending a message header carrying a secondary permission identifier; and

[0016] When the authority level of the local user data is management authority, a message header carrying a third-level authority identifier is generated and sent.

[0017] In one embodiment, after receiving the access string sent by the client, the step of calling the local user data corresponding to the access string includes:

[0018] performing an expiration verification on the access string based on the expiration field in the access string;

[0019] When determining that the access string is invalid, sending an access string invalidation notification to the client; and

[0020] After determining that the access string is valid, the local user data is called according to the access string.

[0021] In one embodiment, the step of performing expiration verification on the access string based on the expiration field in the access string includes:

[0022] Reading the expiration field in the access string and the access time in the session record corresponding to the access string;

[0023] determining the validity period corresponding to the access string according to the expiration field, and determining the offline period of the client according to the difference between the current time and the access time;

[0024] When the offline time is greater than or equal to the valid time, determining that the access string is invalid; and

[0025] When the offline duration is less than the valid duration, it is determined that the access character string is valid.

[0026] In one embodiment, after the step of accessing the application upon receiving the access permission information returned by the application based on the message header, the method further includes:

[0027] Refresh the access time in the session record of the access string.

[0028] In one embodiment, before the step of refreshing the access time in the session record of the access string, the method further includes:

[0029] Determining whether the access string carries a scheduled task identifier; and

[0030] When the access string carries a timed task identifier, the step of refreshing the access time in the session record of the access string is not performed.

[0031] In one embodiment, upon receiving user login information sent by the client, the step of calling corresponding local user data according to the user login information includes:

[0032] After receiving the user login information, encrypt and encapsulate the user login information based on the random encryption string to generate ciphertext information, and send the ciphertext information to the user management process;

[0033] The user management process obtains the corresponding decryption algorithm from the encryption library based on the encryption identifier of the ciphertext information;

[0034] Decrypting the encrypted information based on the decryption algorithm to obtain the local user data; and

[0035] Generate online users based on the local user data and add them to the user management table.

[0036] In addition, the present application also provides an access rights management method, which is applied to an application program, and the access rights management method includes the following steps:

[0037] When receiving a message header sent by the server, reading the permission identifier carried in the message header, and determining the permission level corresponding to the permission identifier based on the permission identifier; and

[0038] Verifying whether the permission level is greater than or equal to the local permission level;

[0039] If so, generate and send access permission information to the server;

[0040] If not, an access denial message is generated and sent to the server.

[0041] In addition, to achieve the above-mentioned purpose, the present application also provides an access permission management device, which includes a memory, a processor, and an access permission management program stored on the memory and runnable on the processor. When the access permission management program is executed by the processor, the steps of the access permission management method described above are implemented.

[0042] In addition, to achieve the above-mentioned purpose, the present application also provides a computer-readable storage medium, on which a permission management program is stored. When the permission management program is executed by a processor, the steps of the permission management method described above are implemented. Beneficial effects

[0043] Embodiments of the present application provide an access rights management method that ensures accurate authentication of logged-in users by invoking corresponding local user data based on user login information. Furthermore, an access string corresponding to the local user data is generated and sent to a client. Because the access string contains user information, a request to access switch-related applications can be made directly from the server based on the access string. Furthermore, since access does not require a username and password, the security of the local user data is ensured. Upon receiving the access string from the client, the local user data corresponding to the access string is invoked, and a message header carrying a permission identifier is generated and sent to the application, allowing the application to verify whether the user has permission to use the application's functions, thereby achieving fine-grained permission control. Upon receiving access permission information returned by the application based on the message header, the application is accessed, ensuring that only users with the required permission levels can use switch-related applications, thereby achieving user access management and control. Therefore, by verifying and controlling access rights through user login information, local user data, access strings, and message headers, fine-grained permission control and user permission management for switch users is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for describing the embodiments. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without inventive work.

[0045] FIG1 is a schematic diagram of the architecture of the hardware operating environment of the access rights management device involved in an embodiment of the present application;

[0046] FIG2 is a flowchart of a first embodiment of the access rights management method of the present application;

[0047] FIG3 is a flow chart of a second embodiment of the access rights management method of the present application;

[0048] FIG4 is a flow chart of a third embodiment of the access rights management method of the present application.

[0049] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. Modes for Carrying Out the Invention

[0050] The present application discloses an access rights management method, which is applied to a server. Upon receiving user login information from a client, the server calls corresponding local user data based on the user login information; generates and sends an access string corresponding to the local user data to the client based on the local user data; upon receiving the access string from the client, calls the local user data corresponding to the access string; generates and sends a message header carrying a permission identifier to an application based on the local user data; and upon receiving access permission information returned by the application based on the message header, accesses the application. This improves the management capabilities of switch users and the security of local user data.

[0051] To better understand the above technical solutions, exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0052] As an implementation scheme, FIG1 is a schematic diagram of the architecture of the hardware operating environment of the access rights management device involved in the embodiment of the present application.

[0053] As shown in Figure 1 , the access rights management device may include a processor 101, such as a central processing unit (CPU), memory 102, and a communication bus 103. Memory 102 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. Memory 102 may also be a storage device independent of processor 101. Communication bus 103 facilitates communication between these components.

[0054] Those skilled in the art will appreciate that the structure shown in FIG1 does not limit the access permission management device, and may include more or fewer components than shown, or combine certain components, or arrange components differently.

[0055] As shown in FIG1 , the memory 102 as a computer-readable storage medium may include an operating system, a data storage module, a network communication module, a user interface module, and an access rights management program.

[0056] In the access permission management device shown in FIG1 , the processor 101 and the memory 102 may be provided in the access permission management device. The access permission management device calls the access permission management program stored in the memory 102 via the processor 101 and performs the following operations:

[0057] When receiving the user login information sent by the client, calling the corresponding local user data according to the user login information;

[0058] generating, based on the local user data, an access string corresponding to the local user data and sending the access string to the client;

[0059] After receiving the access string sent by the client, calling the local user data corresponding to the access string;

[0060] Generate and send a message header carrying an authorization identifier to the application based on the local user data;

[0061] When the access permission information returned by the application based on the message header is received, the application is accessed.

[0062] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0063] When the permission level of the local user data is basic permission, a message header carrying a first-level permission identifier is generated and sent;

[0064] When the permission level of the local user data is monitoring permission, generating and sending a message header carrying a secondary permission identifier;

[0065] When the authority level of the local user data is management authority, a message header carrying a third-level authority identifier is generated and sent.

[0066] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0067] performing an expiration verification on the access string based on the expiration field in the access string;

[0068] When it is determined that the access string is invalid, sending an access string invalidation prompt to the client;

[0069] After determining that the access string is valid, the local user data is called according to the access string.

[0070] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0071] Reading the expiration field in the access string and the access time in the session record corresponding to the access string;

[0072] determining the validity period corresponding to the access string according to the expiration field, and determining the offline period of the client according to the difference between the current time and the access time;

[0073] When the offline time is greater than or equal to the valid time, determining that the access character string is invalid;

[0074] When the offline duration is less than the valid duration, it is determined that the access character string is valid.

[0075] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0076] Refresh the access time in the session record of the access string.

[0077] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0078] Determine whether the access string carries a scheduled task identifier;

[0079] When the access string carries a timed task identifier, the step of refreshing the access time in the session record of the access string is not performed.

[0080] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0081] After receiving the user login information, encrypt and encapsulate the user login information based on the random encryption string to generate ciphertext information, and send the ciphertext information to the user management process;

[0082] The user management process obtains the corresponding decryption algorithm from the encryption library based on the encryption identifier of the ciphertext information;

[0083] Decrypting the encrypted information based on the decryption algorithm to obtain the local user data;

[0084] Generate online users based on the local user data and add them to the user management table.

[0085] In one embodiment, the processor 101 may be configured to call the access permission management program stored in the memory 102 and perform the following operations:

[0086] When receiving a message header sent by the server, reading the permission identifier carried in the message header, and determining the permission level corresponding to the permission identifier based on the permission identifier;

[0087] Verifying whether the permission level is greater than or equal to the local permission level;

[0088] If so, generate and send access permission information to the server;

[0089] If not, an access denial message is generated and sent to the server.

[0090] Based on the hardware architecture of the above-mentioned access permission management device, an embodiment of the access permission management method of the present application is proposed.

[0091] It should be noted that, in the embodiment of the present application, one end of the switch is connected to the client through a network; the other end of the switch is connected to the server through a network.

[0092] 2 , in a first embodiment, the access permission management method is applied to a server side, and the access permission management method includes the following steps:

[0093] Step S100: When user login information sent by the client is received, corresponding local user data is called according to the user login information.

[0094] In this embodiment, when the server receives the user login information sent by the client, the server calls the corresponding local user data in the user management table based on the user login information. In one embodiment, the client can be a computer, a printer, an IP camera, a network storage device, etc. The user login information includes a user name and a user password. Local user data includes but is not limited to user identity information, user permission information, user access data, etc. The user management table includes the local user data of all online users, where online users refer to registered users. In one embodiment, after receiving the user login information sent by the client, it is necessary to first determine whether the user login information matches the user data in the Linux database; then, when the user login information matches the user data in the Linux database, the detailed local user data is called from the background management terminal.

[0095] In one embodiment, after a client connects to a switch already connected to a server, the server requests login information from the client through the switch. After receiving the user login information, the server encrypts and encapsulates it based on a random encryption string, generating ciphertext information and sending it to the user management process. The user management process is a program running on the server that handles user login requests, verifies user identities, and manages local user data and permissions. It should be noted that the random encryption string is obtained from a local database and is an encrypted identifier generated by combining the username and password, which is used to encrypt the user's password.

[0096] After receiving the ciphertext information, the user management process retrieves the corresponding decryption algorithm from the encryption library based on the encryption identifier of the ciphertext information. Then, using the decryption algorithm, the ciphertext information is decrypted to obtain the local user data. Based on the local user data, an online user is generated and added to the user management table. After decrypting the ciphertext information to obtain the local user data, the local user data may be verified to ensure its accuracy. The encryption library is allocated to the user management process during system initialization.

[0097] This ensures that only administrators can see all local user data in the user management process, and that local user data does not include user passwords or encryption strings, thereby ensuring the security of external data. Furthermore, since different encryption libraries are assigned to different switch-related applications during system initialization, only applications whose encryption libraries include the corresponding decryption algorithms can decrypt received ciphertext information. Therefore, encrypting local user data and transmitting it to the user management process prevents it from being intercepted during transmission, improving the security of local user data transmission.

[0098] Step S200: Generate and send an access string corresponding to the local user data to the client according to the local user data.

[0099] In this embodiment, after accessing the local user data corresponding to the user login information, the server generates an access string corresponding to the local user data and sends this access string to the client via the switch. It should be noted that the client is the one that sent the user login information. The access string is used by the client to access data on the switch.

[0100] Because the access string is sent to the client, the client can use it to access the connected switch-related applications on the server and manage the switch. Accessing switch-related applications on the server using the access string eliminates the tedious task of frequently entering usernames and passwords, improving user access convenience.

[0101] Step S300: After receiving the access string sent by the client, call the local user data corresponding to the access string.

[0102] In this embodiment, when a client accesses a switch-related application through the server, it sends an access string to the server to request access to the switch-related application. After receiving the access string from the client, the server uses the access string to query the corresponding local user data and access the local user data.

[0103] In one embodiment, after receiving the access string, the server performs an expiration verification on the access string. In one embodiment, the access string includes a time limit field, wherein the time limit field is used for expiration verification. Specifically, the time limit field in the access string and the last access time in the session record corresponding to the access string are read. Then, based on the time limit field, the valid duration corresponding to the access string is determined, and based on the difference between the current time and the last access time, the offline duration of the client is determined. When the offline duration is greater than or equal to the valid duration, the access string is determined to be invalid; when the offline duration is less than the valid duration, the access string is determined to be valid. Specifically, the step of determining the offline duration of the client based on the difference between the current time and the access time is implemented by calculation by the server.

[0104] After the access string is verified for expiration, if it is determined that the access string is invalid, an access string invalidation prompt is sent to the client; if it is determined that the access string is valid, the step of calling local user data according to the access string is executed.

[0105] In one embodiment, after determining that an access string has expired, the session record corresponding to the expired access string is deleted, so that the corresponding local user data cannot be accessed the next time the access string is received. In this case, if the user needs to access a switch-related application on the server, they need to re-enter their user login information on the client to obtain a new access string, and then access the switch-related application using the new access string.

[0106] By performing expiration verification on the access string, you can ensure that the access string is valid within a certain period of time, prevent malicious attackers from tampering with or reusing expired access strings, and thus prevent unauthorized access and ensure user data security.

[0107] Step S400: Generate and send a message header carrying an authorization identifier to an application based on the local user data.

[0108] In this embodiment, after the server accesses the local user data corresponding to the access string, it generates a message header carrying a permission identifier based on the local user data and then sends the message header to the application. In one embodiment, when the permission level of the local user data is basic permission, a message header carrying a first-level permission identifier is generated and sent; when the permission level of the local user data is monitoring permission, a message header carrying a second-level permission identifier is generated and sent; when the permission level of the local user data is management permission, a message header carrying a third-level permission identifier is generated and sent; and when the permission level of the local user data is standard permission, a message header carrying a fourth-level permission identifier is generated and sent.

[0109] In one embodiment, users with basic permissions can access switch-related applications on the server side; users with monitoring permissions can not only access switch-related applications on the server side, but also use the monitoring function to monitor the switch; users with standard permissions can not only access applications and use the monitoring function, but also use most switch-related applications to configure the switch; users with management permissions, in addition to the above permissions, also have the permission to perform systematic management of the switch.

[0110] It should be noted that fine-grained permission control refers to controlling the specific functions, operations, or data of switch applications during the user permission allocation process. This allows for more detailed permission management, tailored to the specific permission requirements of different users. Users with administrative permissions can refine permissions to a finer granularity based on actual needs, enabling flexible permission management. This control approach improves server-side security, preventing unauthorized users from accessing sensitive data or performing unauthorized operations.

[0111] Since users with administrative privileges can set the privileges of other users, user privileges can be adjusted according to the needs of the product and user management plan, thereby achieving privilege management for switch users, so that only users with the required privilege levels can use switch-related applications.

[0112] Step S500: When receiving the access permission information returned by the application based on the message header, access the application.

[0113] In this embodiment, the server sends a message header containing a permission identifier to the application and then waits for a response from the application. If the response from the application indicates that access is permitted, the application is allowed access. The server then sends the data obtained during the access to the client, allowing the client to operate the switch-related application.

[0114] For example, assume the server receives user login information with username aaa and password bbb. Based on the received login information, the server searches the user management table for the corresponding local user data. It then generates an access string XY1Z23 based on the local user data and sends it to the client via the switch.

[0115] After receiving the access string XY1Z23 from the client, the server performs an expiration check on the access string. Assuming the access string is valid, the server finds that the user permission level corresponding to the access string XY1Z23 in the local user data is standard permission. It then generates and sends a message header with a level 4 permission identifier to the application.

[0116] Assuming that the server receives the access permission information returned by the application, it accesses the switch-related application according to the access permission information.

[0117] In the technical solution provided by this embodiment, the corresponding local user data is retrieved based on the user login information to ensure accurate authentication of the logged-in user. An access string corresponding to the local user data is generated and sent to the client. Because the access string contains user information, the server can directly request access to switch-related applications based on the access string. Furthermore, since access does not require a username and password, the security of the local user data is ensured. Upon receiving the access string from the client, the local user data corresponding to the access string is retrieved, and a message header carrying a permission identifier is generated and sent to the application to verify whether the user has permission to use the application's functions, thereby achieving fine-grained permission control. Upon receiving the access permission information returned by the application based on the message header, the application is accessed, ensuring that only users with the required permission levels can use the switch-related applications, thereby achieving management and control of user access. Therefore, by verifying and controlling access rights through user login information, local user data, access strings, and message headers, fine-grained permission control and user permission management are achieved for switch users.

[0118] 3 , based on the above embodiment, in a second embodiment, after the step of accessing the application upon receiving the access permission information returned by the application based on the message header, the step further includes:

[0119] Step S600: Refresh the access time in the session record of the access string.

[0120] In this embodiment, when accessing an application, the server refreshes the access time in the session record corresponding to the access string to extend the access string's validity period. The session record may include the username, access string, access time, validity period, user IP address, user permission level, and online status. It should be noted that session records are only accessible to applications that have the relevant encryption library. Therefore, since external applications do not have access permissions, session records are only accessible locally and are not published externally, thereby ensuring the security of local user data.

[0121] In the technical solution provided in this embodiment, the effective duration of the character string is extended by refreshing the access time, so as to avoid the situation where the access to the character string becomes invalid after a short offline time.

[0122] Furthermore, before the step of refreshing the access time in the session record of the access string, the method further includes:

[0123] Determine whether the access string carries a scheduled task identifier;

[0124] When the access string carries a timed task identifier, the step of refreshing the access time in the session record of the access string is not performed.

[0125] In this embodiment, timed data and user-initiated access data are separated to distinguish between user access and timer access. Therefore, before refreshing the access time in the session record, a determination is made as to whether the access string carries a timed task identifier. If so, refreshing the access time in the session record for the access string is not performed.

[0126] In the technical solution adopted in this embodiment, by determining whether the access character string carries a timed task identifier, it is determined whether the access operation is a user access or a timer access, thereby ensuring the accuracy of the calculation of the user's offline time.

[0127] 4 , based on the above embodiment, in a third embodiment, the access permission management method is applied to an application program, and the access permission management method includes the following steps:

[0128] Step S700: When a message header sent by the server is received, the permission identifier carried in the message header is read, and the permission level corresponding to the permission identifier is determined based on the permission identifier;

[0129] Step S800: Verify whether the authority level is greater than or equal to the local authority level;

[0130] Step S810: If yes, generate and send access permission information to the server;

[0131] Step S820: If not, generate and send access denial information to the server.

[0132] In this embodiment, after receiving the message header sent by the server, the application reads the message header to obtain the permission identifier carried in the message header, and then determines the user's permission level based on the permission identifier. The permission identifier can be a first-level permission identifier, a second-level permission identifier, a third-level permission identifier, or a fourth-level permission identifier; correspondingly, the permission level can be basic permission, monitoring permission, management permission, or standard permission.

[0133] After determining the user's permission level, the system verifies whether the permission level is greater than or equal to the local permission level. If so, it generates and sends an access permission message to the server. If not, it generates and sends an access denial message to the server. The access permission message informs the client server that the client is allowed to access the application; the access denial message informs the server that the client that sent the access string is not authorized to access the application.

[0134] In the technical solution provided by this embodiment, the application verifies the permission identifier carried in the message header to determine whether the client requesting access is authorized to access the application. This enables user permission management, ensuring that only users with the required permission levels can use switch-related applications, ensuring the security of application data.

[0135] Furthermore, those skilled in the art will appreciate that all or part of the steps in the method of the above-described embodiment can be implemented by instructing the relevant hardware through a computer program. The computer program includes program instructions, which can be stored in a computer-readable storage medium. The program instructions are executed by at least one processor in the access rights management device to implement the steps in the method of the above-described embodiment.

[0136] Therefore, the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores an access permission management program, and when the access permission management program is executed by a processor, the steps of the access permission management method described in the above embodiment are implemented.

[0137] The computer-readable storage medium may be any computer-readable storage medium that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk.

[0138] It should be noted that since the storage medium provided in the embodiments of this application is the storage medium used to implement the method of the embodiments of this application, based on the method described in the embodiments of this application, those skilled in the art will be able to understand the specific structure and deformation of the storage medium, and therefore will not be described in detail here. All storage media used in the method of the embodiments of this application fall within the scope of protection to be provided by this application.

[0139] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0140] This application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate a device for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0141] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0142] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0143] It should be noted that in the claims, any reference signs placed between parentheses shall not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claim. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The present application may be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The use of the words first, second and third etc. does not indicate any order. These words may be interpreted as names.

[0144] Although the optional embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the optional embodiments and all changes and modifications that fall within the scope of the present application.

[0145] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A method for managing access rights, wherein: The access permission management method is applied to the server side, and the access permission management method includes the following steps: When receiving the user login information sent by the client, calling the corresponding local user data according to the user login information; According to the local user data, generating and sending an access string corresponding to the local user data to the client; After receiving the access string sent by the client, calling the local user data corresponding to the access string; Generate and send a message header carrying an authorization identifier to an application program based on the local user data; and When the access permission information returned by the application based on the message header is received, the application is accessed.

2. The access rights management method according to claim 1, wherein: The step of generating and sending a message header carrying an authority identifier to an application according to the local user data comprises: When the permission level of the local user data is basic permission, generating and sending a message header carrying a first-level permission identifier; When the permission level of the local user data is monitoring permission, generating and sending a message header carrying a secondary permission identifier; and When the authority level of the local user data is management authority, a message header carrying a third-level authority identifier is generated and sent.

3. The access rights management method according to claim 1, wherein: After receiving the access string sent by the client, the step of calling the local user data corresponding to the access string includes: Based on the expiration field in the access string, performing an expiration verification on the access string; After determining that the access string is invalid, sending an access string invalidation prompt to the client; and After determining that the access character string is valid, the local user data is called according to the access character string.

4. The access rights management method according to claim 3, wherein: The step of performing an expiration verification on the access string based on the expiration field in the access string comprises: Reading the expiration field in the access string and the access time in the session record corresponding to the access string; Determine the validity period corresponding to the access string according to the time limit field, and determine the offline period of the client according to the difference between the current time and the access time; and When the offline time is greater than or equal to the valid time, determining that the access string is invalid; When the offline duration is less than the valid duration, it is determined that the access character string is valid.

5. The access rights management method according to claim 1, wherein: After the step of accessing the application upon receiving the access permission information returned by the application based on the message header, the method further includes: Refresh the access time in the session record of the access string.

6. The access rights management method according to claim 5, wherein: Before the step of refreshing the access time in the session record of the access string, the method further includes: Determining whether the access string carries a scheduled task identifier; and When the access string carries a scheduled task identifier, the step of refreshing the access time in the session record of the access string is not performed.

7. The access rights management method according to claim 1, wherein: When receiving the user login information sent by the client, the step of calling the corresponding local user data according to the user login information includes: After receiving the user login information, encrypt and encapsulate the user login information based on the random encryption string to generate ciphertext information, and send the ciphertext information to the user management process; The user management process obtains the corresponding decryption algorithm in the encryption library based on the encryption identifier of the ciphertext information; Based on the decryption algorithm, decrypt the ciphertext information to obtain the local user data; and Generate online users based on the local user data and add them to the user management table.

8. A method for managing access rights, wherein: The access permission management method is applied to an application program, and the access permission management method comprises the following steps: When receiving a message header sent by the server, reading the permission identifier carried in the message header, and determining the permission level corresponding to the permission identifier according to the permission identifier; and Verifying whether the permission level is greater than or equal to the local permission level; If so, generate and send access permission information to the server; If not, generate and send access denial information to the server.

9. An access rights management device, wherein: The access permission management device comprises: a memory, a processor, and an access permission management program stored in the memory and executable on the processor, wherein the access permission management program is configured to implement the steps of the access permission management method according to any one of claims 1 to 8.

10. A readable storage medium, wherein: The readable storage medium stores an access permission management program, and when the access permission management program is executed by the processor, the steps of the access permission management method according to any one of claims 1 to 8 are implemented.

Images