Task permission verification method and apparatus, non-volatile storage medium and electronic device

Abstract

The present application discloses a task permission verification method and apparatus, a non-volatile storage medium and an electronic device. The method comprises: a routing service system receiving a task permission verification request of a target task, wherein the task permission verification request carries a preset validation field, and the routing service system comprises a plurality of routing service modules; extracting the preset validation field of the target task from the task permission verification request; on the basis of the preset validation field, make a query about task permission information corresponding to the target task; and when the task permission information has been found, performing permission verification on the target task on the basis of the task permission information and the preset validation field, and after the verification is passed, confirming that the target task can be executed. The present application solves the technical problem of it not being possible to ensure data security due to the fact that permission verification is performed at an intermediate core node in related technologies.

Description

Task authority verification method, device, non-volatile storage medium and electronic device

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on December 8, 2023, with application number 2023116888233, entitled “Task Authority Verification Method, Device, Non-volatile Storage Medium and Electronic Device,” the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates to the field of data authority management, and specifically, to a task authority verification method, device, non-volatile storage medium and electronic device. Background Art

[0003] Related technologies typically manage data permissions using a central management node combined with pre-configured plug-ins. This approach is problematic in scenarios where metadata is accessed directly, bypassing the central core node. This makes it impossible to verify access permissions, compromising data security.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a task authority verification method, device, non-volatile storage medium and electronic device to at least solve the technical problem that data security cannot be guaranteed due to authority verification at the intermediate core node in the related technology.

[0007] According to one aspect of an embodiment of the present application, a task authority verification method is provided, including: a routing service system receives a task authority verification request for a target task, wherein the task authority verification request carries a preset check field, and the routing service system includes multiple routing service modules; extracts the preset check field of the target task from the task authority verification request; queries task authority information corresponding to the target task based on the preset check field; when the task authority information is queried, performs authority verification on the target task based on the task authority information and the preset check field, and confirms that the target task is executable after the verification passes.

[0008] In some embodiments, the preset check field includes a tenant name field, a task path field and an operation information field; the step of querying the task permission information corresponding to the target task based on the preset check field includes: retrieving the tenant name corresponding to the target task in the preset permission information based on the tenant name field and the task path field; when the tenant name is retrieved, obtaining the operation permission set corresponding to the tenant name, wherein the operation permission set includes all operation type information with execution permissions corresponding to the tenant name field.

[0009] In some embodiments, when task permission information is queried, the step of performing permission verification on the target task based on the task permission information and the preset verification field includes: determining the type of operation that the target task needs to perform based on the operation information field; comparing the type of operation that the target task needs to perform and the operation permission set corresponding to the tenant name field; when the comparison result is that the type of operation that the target task needs to perform is included in the operation permission set, confirming that the target task has passed the permission verification.

[0010] In some embodiments, the step of determining the type of operation that the target task needs to perform based on the operation information field includes: reading the operation information string stored in the operation information field; determining the operation type corresponding to each character position in the operation information string; and determining the type of operation that the target task needs to perform based on the character value in each character position.

[0011] In some embodiments, the step of retrieving the tenant name corresponding to the target task in the preset permission information based on the tenant name field and the task path field includes: searching the task path field in the preset permission information based on the task path field, and determining that the target task has no execution permission if the task path field is not retrieved; if the task path field is retrieved, searching the tenant name corresponding to the tenant name field from the tenant name associated with the task path field in the preset permission information based on the tenant name field, and confirming that the target task has no execution permission if the tenant name corresponding to the tenant name field is not retrieved.

[0012] In some embodiments, after the routing service system receives the task authority verification request for the target task, the task authority verification method further includes: obtaining task identification information of the target task from the task authority verification request, wherein the task identification information is a character string of a preset length; and determining a routing service module in the routing service system that verifies the task authority of the target task based on the task identification information.

[0013] In some embodiments, the steps of determining a routing service module for verifying the task authority of a target task in a routing service system based on task identification information include: determining the number of routing service modules that can provide task authority verification services; hashing the task identification information to obtain a target hash code; performing remainder processing on the target hash code based on the number of routing service modules to obtain a target remainder; and determining a routing service module for verifying the task authority of the target task in the routing service modules that can provide task authority verification services based on the target remainder.

[0014] According to another aspect of an embodiment of the present application, a task authority verification device is also provided, which is suitable for a routing service system including multiple routing service modules, including: a first processing module, used to receive a task authority verification request for a target task, wherein the task authority verification request carries a preset check field; a second processing module, used to extract the preset check word of the target task from the task authority verification request; a third processing module, used to query the task authority information corresponding to the target task based on the preset check field; a fourth processing module, used to perform authority verification on the target task based on the task authority information and the preset check field when the task authority information is queried, and confirm that the target task is executable after the verification is passed.

[0015] According to another aspect of an embodiment of the present application, a non-volatile storage medium is provided, which stores a program, wherein when the program is running, a device where the non-volatile storage medium is located is controlled to execute a task authority verification method.

[0016] According to another aspect of an embodiment of the present application, an electronic device is provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the task authority verification method is executed when the program is running.

[0017] In an embodiment of the present application, a routing service system is used to receive a task authority verification request for a target task, wherein the task authority verification request carries a preset check field, and the routing service system includes multiple routing service modules; the preset check field of the target task is extracted from the task authority verification request; the task authority information corresponding to the target task is queried based on the preset check field; when the task authority information is queried, the target task is verified based on the task authority information and the preset check field, and the target task is confirmed to be executable after the verification is passed. By verifying the task authority through the routing service system, the purpose of avoiding the execution of related tasks without verified authority in some scenarios is achieved, thereby achieving the technical effect of improving data security, and further solving the technical problem that data security cannot be guaranteed due to authority verification at the intermediate core node in the related technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] FIG1 is a schematic structural diagram of a routing service system provided according to an embodiment of the present application;

[0020] FIG2 is a flowchart of a task execution process provided according to an embodiment of the present application;

[0021] FIG3 is a flow chart of a task authority verification method according to an embodiment of the present application;

[0022] FIG4 is a schematic diagram of a preset check field provided according to an embodiment of the present application;

[0023] FIG5 is a schematic diagram of a permission indexing process provided according to an embodiment of the present application;

[0024] FIG6 is a schematic diagram of an operation information field provided according to an embodiment of the present application;

[0025] FIG7 is a schematic diagram of the structure of a task authority verification device provided according to an embodiment of the present application;

[0026] FIG8 is a schematic structural diagram of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0030] Ranger System: The Ranger system is an open-source data rights management and auditing system designed to help organizations manage and protect their data resources, including databases, file systems, and cloud storage. Ranger strengthens data security and compliance management by defining and managing access policies, auditing user behavior, implementing fine-grained rights control, and providing real-time monitoring and reporting. With Ranger, organizations can better protect sensitive data, reduce the risk of data breaches, and ensure compliant data access and use.

[0031] Central Management Node NameNode: The NameNode is the central management node of the Hadoop Distributed File System (HDFS). It manages the file system's namespace, including the naming and path information for files and directories. The NameNode also tracks the location of file data blocks within the cluster and coordinates the replication and movement of data blocks. It also handles client file system operation requests, such as creating, deleting, and modifying files. The NameNode's primary role is to maintain file system metadata and provide namespace operations.

[0032] Yarn tasks: Yarn tasks are used in software development, typically for building, packaging, and deploying code. Yarn tasks may include compiling code, running tests, generating documentation, creating executables, and more. These tasks help automate the development process, improving development efficiency and code quality. Yarn is a popular JavaScript package manager used to manage project dependencies and can perform a variety of tasks to manage projects.

[0033] Currently, intelligent routing services in related technologies are mostly used only for request forwarding or message transmission, and have not been applied to the area of ​​combining storage-computing separation technology with the Ranger system to implement permissions management for storage-computing separation data. Furthermore, when implementing data permissions management in conjunction with the Ranger system, big data clusters in related technologies typically manage task permissions through a central management node, the NameNode, supplemented by plugins. This inherently relies on centralized arbitration and does not support intelligent routing services.

[0034] The problem with this approach of managing task permissions through a central management node is that in some scenarios, tasks can bypass the central management node and access metadata directly through the intelligent routing service. In this case, task permissions cannot be verified, resulting in data security issues.

[0035] In order to solve the above problems, relevant solutions are provided in the embodiments of the present application, which are described in detail below.

[0036] According to an embodiment of the present application, a method embodiment of a task authority verification method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0037] The present application provides a routing service system as shown in FIG1 , which can be used to perform the task authority verification method provided in the present application embodiment. In some embodiments, as can be seen from FIG1 , the system includes a routing service SDK 10 and multiple routing service modules 12. The routing service SDK 10 is used to respond to the task authority authentication request and determine the corresponding routing service module 12 to verify the task authority.

[0038] In some embodiments of the present application, the task execution process for verifying task permissions using the routing service system provided in FIG1 is shown in FIG2 . When a task requires execution, the ResourceManager HA (High Availability Resource Manager) dispatches the task to the NodeManager (Node Manager). When executing a Yarn task, the NodeManager first requests task permissions verification from the routing service SDK 10 via the cluster data I / O (cluster data interaction interface). The routing service SDK 10 determines the routing service module 12 to verify the Yarn task based on the task's identification information. After parsing the Yarn task's data access request, the routing service module 12 determines the Yarn task's permissions and, in conjunction with the Ranger system, verifies the Yarn task's permissions, including verifying whether the tenant initiating the task has permission to access the data and whether it has permission to perform specific operations on the data. After verification, the routing service module 12 retrieves the specified metadata from the metadata storage module and returns it to the NodeManager, which then continues executing the Yarn task.

[0039] As an optional implementation, each routing service module 12 and the Ranger system may adopt an asynchronous communication mode.

[0040] In the above operating environment, an embodiment of the present application provides a task authority verification method, as shown in FIG3 , which includes the following steps:

[0041] Step S302: The routing service system receives a task authority verification request for the target task, wherein the task authority verification request carries a preset check field. The routing service system includes multiple routing service modules.

[0042] In the technical solution provided in step S302, after the routing service system receives the task authority verification request for the target task, it can also determine the routing service module that specifically performs authority verification on the target task in the routing service system based on the task authority verification request, which specifically includes the following steps: obtaining task identification information of the target task from the task authority verification request, wherein the task identification information is a character string of a preset length; and determining the routing service module that verifies the task authority of the target task in the routing service system based on the task identification information.

[0043] As an optional implementation, the step of determining a routing service module for verifying the task authority of a target task in a routing service system based on task identification information includes: determining the number of routing service modules that can provide task authority verification services; hashing the task identification information to obtain a target hash code; performing remainder processing on the target hash code based on the number of routing service modules to obtain a target remainder; and determining a routing service module for verifying the task authority of the target task in the routing service modules that can provide task authority verification services based on the target remainder.

[0044] In some embodiments, the above-mentioned task permission verification request can also be integrated into a data access request or a task execution request. The routing service system can hash the inode ID (task identification information, usually a 64-bit integer value) in the task permission verification request through the built-in routing service SDK, and then perform a remainder processing on the obtained hash code according to the number of intelligent routing services, thereby calculating which routing service module the current request is sent to by the routing service SDK for task permission verification. Among them, the inode ID is a code used to uniquely identify a file or folder object in the storage and computing separation metadata technology. For example, assuming that there are currently 3 routing service modules in an idle state, the target task can be verified for permission. Then, after performing a remainder processing based on the number of routing service modules, the remainder obtained has three cases: 0, 1, and 2. These three cases correspond to a routing service module respectively. In this way, the routing service module that performs permission verification on the target task can be determined based on the remainder calculation result.

[0045] Step S304: extracting the preset verification field of the target task from the task authority verification request;

[0046] In the technical solution provided in step S304, the extracted preset check fields are shown in FIG4 , including the tenant name field “uname string”, the task path field “path string” and the operation information field “mmask byte”.

[0047] Step S306: querying the task authority information corresponding to the target task based on the preset verification field;

[0048] In the technical solution provided in step S306, the preset check field includes a tenant name field, a task path field and an operation information field; the step of querying the task permission information corresponding to the target task based on the preset check field includes: retrieving the tenant name corresponding to the target task in the preset permission information based on the tenant name field and the task path field; when the tenant name is retrieved, obtaining the operation permission set corresponding to the tenant name, wherein the operation permission set includes all operation type information with execution permission corresponding to the tenant name field.

[0049] In some embodiments of the present application, the step of retrieving the tenant name corresponding to the target task in the preset permission information based on the tenant name field and the task path field includes: retrieving the task path field in the preset permission information based on the task path field, and determining that the target task has no execution permission if the task path field is not retrieved; if the task path field is retrieved, retrieving the tenant name corresponding to the tenant name field from the tenant name associated with the task path field in the preset permission information based on the tenant name field, and confirming that the target task has no execution permission if the tenant name corresponding to the tenant name field is not retrieved.

[0050] In some embodiments, the indexing process for searching for permissions for a target task is shown in Figure 5. First, a search is performed in the first-level index based on the task path field within the preset permissions information. Then, a further search is performed in the second-level index based on the tenant name field within the preset permissions information to obtain the set of operational permissions corresponding to the target task. For example, this indicates whether the target task can perform read, write, or execute operations. A value other than true indicates that the target task can perform the operation.

[0051] Step S308 : When the task authority information is found, the target task is verified based on the task authority information and the preset verification field, and the target task is confirmed to be executable after the verification passes.

[0052] As an optional implementation method, when task permission information is queried, the step of performing permission verification on the target task based on the task permission information and the preset verification field includes: determining the type of operation that the target task needs to perform based on the operation information field; comparing the type of operation that the target task needs to perform and the operation permission set corresponding to the tenant name field; when the comparison result is that the type of operation that the target task needs to perform is included in the operation permission set, confirming that the target task has passed the permission verification.

[0053] In some embodiments of the present application, the step of determining the type of operation that the target task needs to perform based on the operation information field includes: reading the operation information string stored in the operation information field; determining the operation type corresponding to each character position in the operation information string; and determining the type of operation that the target task needs to perform based on the character value in each character position.

[0054] In some embodiments, the operation information string is shown in FIG6 . Different operation types correspond to different bits in the string, and the values ​​include 0 and 1. A value of 0 indicates that the target task does not need to perform the corresponding operation, and a value of 1 indicates that the target task needs to perform the corresponding operation. The operation required to be performed by the target task is then compared with the operation permission information of the target task to determine whether the target task has execution permission for the operation required to be performed.

[0055] The invention adopts a routing service system to receive a task authority verification request of a target task, wherein the task authority verification request carries a preset check field, and the routing service system includes multiple routing service modules; extracts the preset check field of the target task from the task authority verification request; queries the task authority information corresponding to the target task based on the preset check field; when the task authority information is queried, performs authority verification on the target task based on the task authority information and the preset check field, and confirms that the target task is executable after the verification is passed. By verifying the task authority through the routing service system, the purpose of avoiding the execution of related tasks without verified authority in some scenarios is achieved, thereby achieving the technical effect of improving data security, and further solving the technical problem that data security cannot be guaranteed due to authority verification at the intermediate core node in the related technology.

[0056] In addition, by adopting the task authority verification method provided in the embodiment of the present application, the routing service system verifies the task authority, which is equivalent to placing the data authority management and authentication work in the metadata access layer for execution, breaking away from the limitations of the cluster center node logic and avoiding the possible risk of bypassing the authentication step during data access.

[0057] An embodiment of the present application provides a task authority verification device, which is suitable for use in the routing service system shown in Figure 1. Figure 7 is a schematic structural diagram of the device. As shown in Figure 7, the device includes: a first processing module 70, which is used to receive a task authority verification request for a target task, wherein the task authority verification request carries a preset check field; a second processing module 72, which is used to extract the preset check word of the target task from the task authority verification request; a third processing module 74, which is used to query the task authority information corresponding to the target task based on the preset check field; a fourth processing module 76, which is used to perform authority verification on the target task based on the task authority information and the preset check field when the task authority information is queried, and confirm that the target task is executable after the verification is passed.

[0058] In some embodiments of the present application, after the first processing module 70 receives the task authority verification request for the target task, the first processing module 70 is further used to: obtain task identification information of the target task from the task authority verification request, wherein the task identification information is a character string of a preset length; and determine a routing service module in the routing service system that verifies the task authority of the target task based on the task identification information.

[0059] In some embodiments of the present application, the steps of the first processing module 70 determining the routing service module that verifies the task authority of the target task in the routing service system based on the task identification information include: determining the number of routing service modules that can provide task authority verification services; hashing the task identification information to obtain a target hash code; performing remainder processing on the target hash code based on the number of routing service modules to obtain a target remainder; and determining the routing service module that verifies the task authority of the target task in the routing service modules that can provide task authority verification services based on the target remainder.

[0060] In some embodiments of the present application, the preset check field includes a tenant name field, a task path field, and an operation information field; the step of the third processing module 74 querying the task permission information corresponding to the target task based on the preset check field includes: retrieving the tenant name corresponding to the target task in the preset permission information based on the tenant name field and the task path field; when the tenant name is retrieved, obtaining the operation permission set corresponding to the tenant name, wherein the operation permission set includes all operation type information with execution permissions corresponding to the tenant name field.

[0061] In some embodiments of the present application, the step of the third processing module 74 retrieving the tenant name corresponding to the target task in the preset permission information based on the tenant name field and the task path field includes: retrieving the task path field in the preset permission information based on the task path field, and determining that the target task has no execution permission if the task path field is not retrieved; if the task path field is retrieved, retrieving the tenant name corresponding to the tenant name field from the tenant name associated with the task path field in the preset permission information based on the tenant name field, and confirming that the target task has no execution permission if the tenant name corresponding to the tenant name field is not retrieved.

[0062] In some embodiments of the present application, when the fourth processing module 76 queries the task permission information, the steps of performing permission verification on the target task based on the task permission information and the preset verification field include: determining the type of operation that the target task needs to perform based on the operation information field; comparing the type of operation that the target task needs to perform with the operation permission set corresponding to the tenant name field; and when the comparison result is that the type of operation that the target task needs to perform is included in the operation permission set, confirming that the target task has passed the permission verification.

[0063] In some embodiments of the present application, the steps of the fourth processing module 76 determining the type of operation that needs to be performed for the target task based on the operation information field include: reading the operation information string stored in the operation information field; determining the operation type corresponding to each character position in the operation information string; and determining the type of operation that needs to be performed for the target task based on the character value in each character position.

[0064] It should be noted that the various modules in the above-mentioned task authority verification device can be program modules (for example, a set of program instructions that implement a certain specific function) or hardware modules. For the latter, it can be expressed in the following forms, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.

[0065] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 8 shows a hardware structure block diagram of an electronic device 80 for implementing a task authority verification method. As shown in Figure 8, the electronic device 80 may include one or more (802a, 802b, ..., 802n are used in the figure to illustrate) processors 802 (the processor 802 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 804 for storing data, and a transmission module 806 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It will be understood by those skilled in the art that the structure shown in Figure 8 is only for illustration and does not limit the structure of the above-mentioned electronic device. For example, the electronic device 80 may also include more or fewer components than those shown in Figure 8, or have a configuration different from that shown in Figure 8.

[0066] It should be noted that the one or more processors 802 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry". The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuitry may be a single independent processing module, or may be incorporated in whole or in part into any of the other components of the electronic device 80. As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0067] The memory 804 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the task authority verification method in the embodiment of the present application. The processor 802 executes various functional applications and data processing by running the software programs and modules stored in the memory 804, that is, implementing the above-mentioned task authority verification method. The memory 804 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 804 may further include a memory remotely located relative to the processor 802, and these remote memories may be connected to the electronic device 80 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0068] Transmission device 806 is used to receive or send data via a network. Specific examples of the aforementioned network may include a wireless network provided by the communications provider of computer terminal 80. In one embodiment, transmission device 806 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 806 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0069] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the electronic device 80 .

[0070] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0071] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0072] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0073] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0074] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the relevant technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0075] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A task authority verification method, comprising: The routing service system receives a task authority verification request of a target task, wherein the task authority verification request carries a preset verification field, and the routing service system includes a plurality of routing service modules; Extracting the preset verification field of the target task from the task authority verification request; Querying the task authority information corresponding to the target task according to the preset verification field; When the task authority information is found, the target task is verified for authority based on the task authority information and the preset verification field, and the target task is confirmed to be executable after the verification passes.

2. The task authority verification method according to claim 1, wherein: The preset verification field includes a tenant name field, a task path field and an operation information field; the step of querying the task authority information corresponding to the target task according to the preset verification field includes: Retrieving the tenant name corresponding to the target task in the preset permission information according to the tenant name field and the task path field; In the case where the tenant name is retrieved, an operation permission set corresponding to the tenant name is obtained, wherein the operation permission set includes all operation type information with execution permissions corresponding to the tenant name field.

3. The task authority verification method according to claim 2, wherein: When the task authority information is queried, the step of performing authority verification on the target task according to the task authority information and the preset verification field includes: Determining the type of operation that needs to be performed on the target task according to the operation information field; Compare the operation type to be performed by the target task with the operation permission set corresponding to the tenant name field; If the comparison result shows that the types of operations that the target task needs to execute are all included in the operation permission set, it is confirmed that the target task passes the permission verification.

4. The task authority verification method according to claim 3, wherein: The step of determining the type of operation to be performed by the target task according to the operation information field comprises: Read the operation information character string stored in the operation information field; Determine the operation type corresponding to each character position in the operation information string; The type of operation that the target task needs to perform is determined according to the character value in each character position.

5. The task authority verification method according to claim 2, wherein: The step of retrieving the tenant name corresponding to the target task in the preset permission information according to the tenant name field and the task path field comprises: According to the task path field, searching for the task path field in the preset permission information, and determining that the target task has no execution permission if the task path field is not retrieved; In the case where the task path field is retrieved, the tenant name corresponding to the tenant name field is retrieved from the tenant names associated with the task path field in the preset permission information based on the tenant name field, and in the case where the tenant name corresponding to the tenant name field is not retrieved, it is confirmed that the target task has no execution permission.

6. The task authority verification method according to claim 1, wherein: After the routing service system receives the task authority verification request of the target task, the task authority verification method further includes: Acquire task identification information of the target task from the task authority verification request, wherein the task identification information is a character string of a preset length; The routing service module for verifying the task authority of the target task is determined in the routing service system according to the task identification information.

7. The task authority verification method according to claim 6, wherein: The step of determining, in the routing service system according to the task identification information, a routing service module for verifying the task authority of the target task comprises: Determine the number of the routing service modules that can provide task authority verification services; Performing hash coding on the task identification information to obtain a target hash code; Performing remainder processing on the target hash code according to the number of the routing service modules to obtain a target remainder; The routing service module for verifying the task authority of the target task is determined in the routing service module that can provide the task authority verification service according to the target remainder.

8. The task authority verification method according to claim 1 further comprises: Before the routing service system receives the task permission verification request of the target task, The task authority verification request is integrated into the data access request or the task execution request.

9. A task authority verification device, applicable to a routing service system including a plurality of routing service modules, comprising: A first processing module is used to receive a task authority verification request of a target task, wherein the task authority verification request carries a preset verification field; A second processing module, configured to extract the preset verification word of the target task from the task authority verification request; A third processing module, configured to query task authority information corresponding to the target task according to the preset verification field; The fourth processing module is used to perform permission verification on the target task according to the task permission information and the preset verification field when the task permission information is queried, and confirm that the target task is executable after the verification is passed.

10. A non-volatile storage medium storing a program, wherein: When the program is running, the device where the non-volatile storage medium is located is controlled to execute the task authority verification method described in any one of claims 1 to 8.

11. An electronic device, comprising: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the task authority verification method described in any one of claims 1 to 8 when running.

Images