Cross-order multi-level authority authentication method, equipment, media and program product

Abstract

The embodiments of the present application provide a cross-order multi-level permission authentication method, device, medium and program product. The method includes: constructing an outer process interceptor responsibility chain; determining the initial resource demand corresponding to the current resource request; pulling the order set and determining the corresponding resource authority, and constructing the corresponding order interceptor responsibility chain; deducting the resource authority of each order interceptor based on the current resource demand in turn; if the order authority is satisfied, returning a successful result of the resource request; if the order authority is not satisfied, reversely rolling back the deducted resource authority and returning a permission authentication failure result. The embodiments of the present application construct a multi-level authentication responsibility chain for resource requests, and adopt an authentication process of first deducting authority and rolling back step by step, thereby avoiding the request blocking caused by the lock mechanism, thereby effectively improving the system response performance in high-concurrency request scenarios.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a cross-order multi-level authority authentication method, device, medium and program product. Background Art

[0002] Cloud services are computing resources and services provided on-demand through the Internet. With the development of Internet technology, cloud service subscription models are becoming more and more popular. Usually, cloud service rights are presented in the form of virtual orders.

[0003] In the permission authentication scenario of cloud service subscriptions, users may have multiple orders for the same type of cloud service. Therefore, the permissions granted by different orders can be accumulated during the same request for cloud service resources. For example, when the user's original order is not enough to deduct service resources, another order can be purchased and combined with the original order to obtain service permissions.

[0004] Currently, for cross-order permission authentication scenarios, existing solutions typically lock order permissions by adding locks, then individually checking whether the order permissions satisfy the resource request. If so, the order permissions are deducted; if not, the permissions are unlocked and an authentication failure is returned. However, in the high-concurrency scenario of cloud service subscriptions, using a locking solution can result in a large number of requests being blocked, impacting system responsiveness. Summary of the Invention

[0005] The purpose of the embodiments of the present application is to provide a cross-order multi-level authority authentication method, device, medium and program product to solve the problem of poor system response performance in cloud service high-concurrency request scenarios.

[0006] In a first aspect, an embodiment of the present application provides a cross-order multi-level permission authentication method, comprising:

[0007] Constructing an outer process interceptor responsibility chain for the current resource request; wherein the outer process interceptor responsibility chain includes an order adapter interceptor;

[0008] determining an initial resource requirement corresponding to the current resource request;

[0009] Utilizing the order adapter interceptor to pull an order set corresponding to the current resource request, and constructing an order interceptor responsibility chain corresponding to the order set; wherein the order set includes at least one order with a corresponding resource permission amount, and the order interceptor responsibility chain includes at least one order interceptor corresponding to the order set;

[0010] Deducting the resource authority of each order interceptor based on the current resource requirement in the responsibility chain order of the order interceptor responsibility chain until the current resource requirement is zero, or until the authentication process reaches the last order interceptor; wherein the current resource requirement is the remaining resource requirement after each authority deduction from the initial resource requirement;

[0011] When the current resource demand is zero, jump out of the outer process interceptor responsibility chain and return a successful resource request result;

[0012] When the authentication process reaches the last order interceptor and the resource permission amount corresponding to the current order interceptor is less than the current required resource amount, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, and the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

[0013] In an embodiment of the present application, by constructing a multi-level authentication responsibility chain for resource requests and adopting an authentication process of pre-deduction of permissions and step-by-step rollback, request blocking caused by the locking mechanism is avoided, thereby effectively improving the system response performance in high-concurrency request scenarios.

[0014] In some possible embodiments, when the authentication process reaches the last order interceptor and the resource permission amount corresponding to the current order interceptor is less than the current required resource amount, the deducted resource permission is rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out, and the permission authentication failure result is returned, including:

[0015] When the authentication process reaches the last order interceptor and the resource permission amount corresponding to the current order interceptor is less than the current required resource amount, determine whether the current authentication scenario allows partial success;

[0016] If so, jump out of the outer process interceptor responsibility chain and return a partial success result of the resource request based on the deducted resource authority;

[0017] If not, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

[0018] In an embodiment of the present application, permission authentication is performed based on whether partially successful authentication scenarios are allowed, thereby returning partial authentication success results or rolling back the deducted resources when authentication fails, thereby further improving the flexibility and scalability of cross-order permission authentication.

[0019] In some possible embodiments, each order has resource permissions in multiple permission authentication dimensions, each order interceptor includes a sub-authentication interceptor responsibility chain, and each sub-authentication interceptor responsibility chain includes multiple sub-authentication interceptors corresponding to the multiple permission authentication dimensions;

[0020] The resource authority of each order interceptor is deducted based on the current resource demand in the order of the responsibility chain of the order interceptor until the current resource demand is zero, or until the authentication process reaches the last order interceptor, including:

[0021] In the authentication process of each of the order interceptors, the resource authority amount of each of the sub-authentication interceptors is deducted based on the current resource demand amount in the order of the responsibility chain of the sub-authentication interceptor, until the authentication process reaches a sub-authentication interceptor whose resource authority amount is insufficient to deduct the current resource demand amount, or until the authentication process reaches the last sub-authentication interceptor;

[0022] When the authentication process reaches a sub-authentication interceptor whose resource permissions are insufficient to deduct the currently required resource permissions, based on the actual resource permissions deducted by the current sub-authentication interceptor, the deducted resource permissions of the previous sub-authentication interceptor are rolled back in reverse order according to the chain of responsibility, and the actual resource permissions deducted by the current sub-authentication interceptor are used as the current required resource permissions of the next sub-authentication interceptor to start the authentication process of the next sub-authentication interceptor.

[0023] When the authentication process reaches the last sub-authentication interceptor of the current order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, based on the actual resource amount deducted by the current sub-authentication interceptor, the deducted resource permissions of the previous sub-authentication interceptor are rolled back in reverse order according to the responsibility chain, and the remaining required resource amount after the settlement of the current sub-authentication interceptor is used as the current required resource amount of the next order interceptor to start the authentication process of the next order interceptor;

[0024] When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission corresponding to the current sub-authentication interceptor is less than the current required resource amount, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, and the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

[0025] In an embodiment of the present application, by constructing sub-authentication interceptor responsibility chains corresponding to multiple permission authentication dimensions within the order interceptor, the authentication requirements of multi-dimensional permissions across orders are met, the scalability of the authentication process is further improved, and the response performance of multi-dimensional permission authentication in high-concurrency request scenarios is improved.

[0026] In some possible embodiments, when the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out, and the permission authentication failure result is returned, including:

[0027] When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, determine whether the current authentication scenario is a scenario that allows partial success;

[0028] If so, then jump out of the outer process interceptor responsibility chain, and based on the remaining required resource amount after the current sub-authentication interceptor is settled, roll back the deducted resource permissions of other sub-authentication interceptors in reverse order according to the responsibility chain, and return a partial success result of the resource request based on the deducted resource permissions;

[0029] If not, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

[0030] In an embodiment of the present application, by providing an authentication scenario that allows partial success and rolling back the undeducted resource permissions layer by layer when partial authentication is successful, the flexibility and scalability of cross-order multi-dimensional permission authentication are further improved.

[0031] In some possible embodiments, the outer process interceptor responsibility chain further includes a cache interceptor;

[0032] Before determining the initial resource requirement corresponding to the current resource request, the method further includes:

[0033] Obtaining a historical authentication record of the current resource request based on the cache interceptor, and determining whether the current resource request meets a preset consumption-free authentication condition according to the historical authentication record;

[0034] When it is determined that the current resource request meets the consumption-free authentication condition, the outer process interceptor responsibility chain is jumped out and a successful result of the resource request is returned.

[0035] In an embodiment of the present application, a cache interceptor is added to the outer responsibility chain to omit the specific multi-order merge authentication process when it is determined that the consumption-free authentication conditions are met, thereby further improving the response efficiency of resource request authentication.

[0036] In some possible embodiments, using the order adapter interceptor to pull an order set corresponding to the current resource request and constructing an order interceptor responsibility chain corresponding to the order set includes:

[0037] Utilizing the order adapter interceptor to pull the order set corresponding to the current resource request, and obtaining the order authority consumption policy corresponding to the current resource request; wherein the order authority consumption policy is used to represent the consumption priority of each order in the order set;

[0038] An order interceptor responsibility chain corresponding to the order set is constructed based on the order authority consumption strategy.

[0039] In an embodiment of the present application, by determining the order of authorization authentication for each order based on the order authorization consumption strategy, the user's need for customized configuration of order consumption priority is met, and the flexibility of multi-order authorization authentication is further improved.

[0040] In some possible embodiments, the outer process interceptor responsibility chain further includes at least one authentication interceptor connected in series with the order adapter interceptor, and the authentication order of the at least one authentication interceptor is arranged before the order adapter interceptor.

[0041] In an embodiment of the present application, by adding at least one authentication interceptor before the order adaptation interceptor of the outer responsibility chain, the response efficiency in complex authentication process scenarios is further improved.

[0042] In a second aspect, an embodiment of the present application provides a cross-order multi-level authority authentication device, comprising:

[0043] An outer chain building module, used to build an outer process interceptor responsibility chain for the current resource request; wherein the outer process interceptor responsibility chain includes an order adapter interceptor;

[0044] A demand determination module, configured to determine an initial resource demand corresponding to the current resource request;

[0045] An order chain construction module is configured to use the order adapter interceptor to pull an order set corresponding to the current resource request and construct an order interceptor responsibility chain corresponding to the order set; wherein the order set includes at least one order with a corresponding resource permission amount, and the order interceptor responsibility chain includes at least one order interceptor corresponding to the order set;

[0046] an authority authentication module, configured to deduct the resource authority of each order interceptor based on the current resource requirement in the responsibility chain order of the order interceptor, until the current resource requirement is zero, or until the authentication process reaches the last order interceptor; wherein the current resource requirement is the remaining resource requirement after each authority deduction from the initial resource requirement;

[0047] A success result returning module is used to jump out of the outer process interceptor responsibility chain and return a successful result of the resource request when the current resource demand is zero;

[0048] The resource rollback module is used to roll back the deducted resource permissions in reverse order of the responsibility chain when the authentication process reaches the last order interceptor and the resource permissions corresponding to the current order interceptor are less than the current required resource permissions, jump out of the outer process interceptor responsibility chain and return the permission authentication failure result.

[0049] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor can implement the method described in any embodiment of the first aspect when executing the program.

[0050] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method described in any embodiment of the first aspect can be implemented.

[0051] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the method described in any embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] 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 use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0053] Figure 1 A flowchart of a cross-order multi-level permission authentication method provided in an embodiment of the present application;

[0054] Figure 2 This is a flowchart of the overall process of the cross-order multi-level permission authentication solution provided in the embodiment of the present application;

[0055] Figure 3 A schematic diagram of the structure of a cross-order multi-level authority authentication device provided in an embodiment of the present application;

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

[0057] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0058] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0059] It's important to note that with the development of internet technology, cloud service subscriptions are becoming increasingly popular. Cloud service permissions are often presented as virtual orders. In cloud service subscription permission authentication scenarios, users may have multiple orders for the same cloud service. Therefore, permissions granted by different orders can be cumulatively used during a single request for cloud service resources. For example, if a user's current order is insufficient to cover the desired service resource, they can purchase another order and combine it with their current order to obtain service permissions.

[0060] It is understandable that if it is a single resource consumption, then in an order permission set, if a single order is judged to meet the resource consumption, there is no need to consume across orders. If it does not meet the requirements, it will jump to the next order for judgment and resource consumption. If it is batch resource consumption, it is necessary to subdivide whether partial authentication consumption is allowed (partial authentication successful). For example, the requested resource amount is 100, and the user currently has two orders. The resource permission amounts of the two orders are 50 and 30 respectively, which are not enough to deduct the requested resource amount. If partial authentication consumption is allowed, the system can return 80 resources to the request. If partial authentication consumption is not allowed, the request authentication fails and no resource amount is returned.

[0061] In addition, cloud service subscriptions are divided into different permission authentication dimensions in most scenarios, such as the total amount that can be used, the amount that can be used per month, the amount that can be used per day, the amount that can be used per hour, etc. That is, the authentication consumption of permissions in the same order is also carried out in layers.

[0062] Currently, for cross-order permission authentication scenarios, existing solutions typically lock order permissions by adding locks, then individually checking whether the order permissions satisfy the resource request. If so, the order permissions are deducted; if not, the permissions are unlocked and an authentication failure is returned. However, in the high-concurrency request scenario of cloud service subscriptions, using a locking solution can result in a large number of requests being blocked, impacting system responsiveness. This is especially true in cross-order and multi-dimensional permission authentication models, where more resources are locked and the system responsiveness declines significantly.

[0063] In response to the problems existing in the above-mentioned prior art, the embodiments of the present application propose the following improvements: 1. Design an authentication method of responsibility chain within responsibility chain, define an order adapter interceptor as one of the interceptors in the outer responsibility chain, pull the order set of the current resource request in the order adapter interceptor and build a corresponding inner order-level interceptor to form an order interceptor responsibility chain; further, define a hierarchical inspection interceptor (sub-authentication interceptor) in each order-level interceptor to form a permission-level responsibility chain (sub-authentication interceptor chain). In this way, the permission authentication process is abstracted and streamlined, and the scalability is stronger; 2. Adopt an unlocked authentication method and ensure the ultimate consistency of the authority. During the authentication process, through the design of the responsibility chain, a hierarchical rollback is performed when the interceptor authentication fails or partially passes. The rollback operation is mainly divided into three levels: permission level (sub-authentication interceptor responsibility chain), order level (order interceptor responsibility chain) and outer responsibility chain level (outer process interceptor responsibility chain). The rollback solutions at each level do not interfere with each other, and the permission rollback at the fine-grained level does not affect the scheduling of the outer responsibility chain, thereby ensuring the abstract internal coupling of the system and further improving the system's responsiveness.

[0064] like Figure 1 As shown, the embodiment of the present application provides a cross-order multi-level permission authentication method, which may include the following steps:

[0065] S1. Build an outer process interceptor responsibility chain for the current resource request; wherein the outer process interceptor responsibility chain includes an order adapter interceptor.

[0066] It should be noted that when a user wants to obtain a resource or service from a cloud service, they can initiate a resource acquisition request (i.e., a current resource request). The method of the embodiment of the present application can be executed by the cloud server. When the cloud server responds to the user's current resource request, it builds an outer process interceptor responsibility chain for the current resource request. The outer process interceptor responsibility chain can include one or more authentication interceptors and at least one order adapter interceptor.

[0067] S2. Determine the initial resource requirement corresponding to the current resource request.

[0068] It's important to note that cloud services are an internet-based service model that provides users with computing resources, storage space, applications, and more through remote servers. Users can access these services on demand without having to install or maintain hardware and software locally. When responding to a resource request, a cloud server can obtain the user's initial resource requirements, such as 50GB of storage space or 100 usage limits for a specific tool.

[0069] S3. Use the order adapter interceptor to pull the order set corresponding to the current resource request, and build an order interceptor responsibility chain corresponding to the order set; wherein, the order set includes at least one order with corresponding resource authority, and the order interceptor responsibility chain includes at least one order interceptor corresponding to the order set.

[0070] In the outermost responsibility chain (outer process interceptor responsibility chain), the order adapter interceptor is mainly used to pull the order set corresponding to the current resource request and build the corresponding order interceptor responsibility chain based on the order set. After pulling the order set, the permissions of each order can be normalized according to the resource type currently requested.

[0071] For example, the user ID of the current user can be obtained based on the current resource request, and then one or more orders corresponding to the user ID can be pulled from the pre-stored subscription order database (other authentication interceptors can be used before the order adapter interceptor to filter user requests without subscription permissions or no orders), forming a corresponding order set, where each order has a certain amount of resource permissions, and the specific amount of resource permissions is mainly determined by the type of package purchased by the user and the usage.

[0072] It should be noted that the order interceptor responsibility chain includes one or more order interceptors. Each order interceptor corresponds one-to-one to each order in the order set. Therefore, each order interceptor is granted a resource authority amount consistent with the corresponding order. The authority authentication process of multiple order interceptors is carried out in sequence, and the order consumption order can be customized by the user.

[0073] S4. According to the responsibility chain order of the order interceptor responsibility chain, the resource authority of each order interceptor is deducted based on the current resource demand until the current resource demand is zero, or until the authentication process reaches the last order interceptor; wherein, the current resource demand is the remaining resource demand after each authority deduction from the initial resource demand.

[0074] The initial resource requirement enters the authentication process of the order interceptor responsibility chain. In the first order interceptor, the current resource requirement is the initial resource requirement. Each time the initial resource requirement passes through an order interceptor, the corresponding authenticated resource requirement will be deducted, and the remaining resource requirement will be used as the current resource requirement of the next order interceptor.

[0075] It should be noted that when the resource authority corresponding to an order interceptor is not enough to deduct the current resource demand, the current resource demand will be reduced according to the resource authority corresponding to the order interceptor, and the remaining resource demand will enter the next order interceptor, and the above authority deduction process will be repeated until the current resource demand is reduced to zero. Otherwise, the authentication process will flow through each order interceptor in turn and finally reach the last order interceptor in the order interceptor responsibility chain.

[0076] It can be understood that there are mainly two types of requests for the authentication process of the order interceptor responsibility chain: 1. After the authentication process passes through one or more order interceptors, if all the resource requirements requested by the user are met, the authentication is successful; 2. After the authentication process passes through one or more order interceptors, if the resource requirements requested by the user are not met, the authentication process enters the last order interceptor.

[0077] S5. When the current resource demand is zero, jump out of the outer process interceptor responsibility chain and return the result of successful resource request.

[0078] It should be noted that when an order interceptor deducts resources based on its own authority and reduces the current resource demand to zero, it means that the user's order authority has covered the initial resource demand of the current request, and the request is deemed to be authenticated successfully. At this time, the responsibility chain process is reversed from the current order interceptor until the outer process interceptor responsibility chain is jumped out, and the corresponding data service is returned to the user based on the deducted resource authority (returning the successful result of the resource request). At the same time, the resource authority of the user's order set is deducted based on the deducted resource authority. Orders whose resource authority is deducted to zero can be deleted.

[0079] For example, the initial resource requirement currently requested by the user is 10. The user has two orders with resource permissions of 20 and 15 respectively. The two order interceptors constructed are order interceptor 1 (resource permission is 20) and order interceptor 2 (resource permission is 15). After the authentication process starts, the initial resource requirement enters order interceptor 1. The resource permission of order interceptor 1 becomes 10 after deducting the initial resource requirement from 20. The initial resource requirement is reduced to zero after being consumed by order interceptor 1. At this time, the authentication is successful, and the responsibility chain is reversed and the data service with a resource amount of 10 is returned to the user.

[0080] S6. When the authentication process reaches the last order interceptor and the resource permissions corresponding to the current order interceptor are less than the current required resource permissions, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, and the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

[0081] It should be noted that if the current resource demand has not been reduced to zero after passing through each order interceptor in turn, the authentication process will eventually reach the last order interceptor in the order interceptor responsibility chain. If the resource authority of the order interceptor is greater than or equal to the current resource demand, the user's resource acquisition request can be met. Otherwise, if the resource authority corresponding to the order interceptor is less than the current resource demand, the accumulated resource authority of all the user's orders is not enough to cover the resources requested by the user this time, and it is regarded as an authentication failure. At this time, it is necessary to roll back the resource permissions deducted by each order interceptor in reverse order according to the responsibility chain (order interceptor responsibility chain).

[0082] Based on this, the embodiment of the present application constructs a multi-level authentication responsibility chain for resource requests, adopts an authentication process of pre-deduction of permissions and step-by-step rollback, avoids request blocking caused by the locking mechanism, and effectively improves the system response performance in high-concurrency request scenarios.

[0083] In some possible embodiments, step S6, when the authentication process reaches the last order interceptor and the resource permissions corresponding to the current order interceptor are less than the current required resource permissions, roll back the deducted resource permissions in reverse order of the responsibility chain, jump out of the outer process interceptor responsibility chain, and return a permission authentication failure result, may include:

[0084] S601: When the authentication process reaches the last order interceptor and the resource authority corresponding to the current order interceptor is less than the current required resource amount, determine whether the current authentication scenario is a scenario that allows partial success;

[0085] S602: If yes, then jump out of the outer process interceptor responsibility chain and return a partial success result of the resource request based on the deducted resource authority;

[0086] S603: If not, roll back the deducted resource permissions in reverse order according to the responsibility chain, jump out of the outer process interceptor responsibility chain and return the permission authentication failure result.

[0087] It should be noted that in batch resource consumption scenarios, you can configure whether to allow partial authentication success. When the user's order resource permissions are not sufficient to cover the resources requested this time, for scenarios where partial success is allowed, the corresponding data or services are returned based on the user's order's existing resource permissions. For scenarios where partial success is not allowed, the authentication is judged to have failed, no data or services are returned, and the order permissions deducted in advance are rolled back.

[0088] Based on this, by performing permission authentication based on whether partially successful authentication scenarios are allowed, partial authentication success results are returned or the deducted resources are rolled back when authentication fails, thereby further improving the flexibility and scalability of cross-order permission authentication.

[0089] In some possible embodiments, each order has resource permissions in multiple permission authentication dimensions, each order interceptor includes a sub-authentication interceptor responsibility chain, and each sub-authentication interceptor responsibility chain includes multiple sub-authentication interceptors corresponding to the multiple permission authentication dimensions;

[0090] Step S4, in accordance with the responsibility chain order of the order interceptor, deducts the resource authority of each order interceptor based on the current resource demand until the current resource demand is zero, or until the authentication process reaches the last order interceptor, which may include:

[0091] S401. In the authentication process of each order interceptor, the resource authority of each sub-authentication interceptor is deducted based on the current resource demand in the order of the responsibility chain of the sub-authentication interceptor, until the authentication process reaches a sub-authentication interceptor whose resource authority is insufficient to deduct the current resource demand, or until the authentication process reaches the last sub-authentication interceptor.

[0092] It should be noted that the authentication consumption for an order can be divided into multiple different permission authentication dimensions (two or more dimensions), such as the total usable amount, the monthly usable amount, and the daily usable amount. For example, assuming that the resource permissions for a user's order are 100 (total usable amount), 50 (monthly usable amount), and 20 (daily usable amount), if the user initiates a resource acquisition request for a resource amount of 15 (less than or equal to 20), the order meets the consumption requirements. If the user initiates a resource acquisition request for a resource amount of 30 (greater than 20), the order does not meet the consumption requirements and needs to merge the consumption across orders.

[0093] In each order interceptor, there is a sub-authentication interceptor responsibility chain. Each sub-authentication interceptor responsibility chain includes multiple sub-authentication interceptors corresponding to multiple authority authentication dimensions. For example, multiple authority authentication dimensions include total dimension, monthly dimension and daily dimension. Then, each order interceptor includes a sub-authentication interceptor responsibility chain of "sub-authentication interceptor 1 (corresponding to total dimension) - sub-authentication interceptor 2 (corresponding to monthly dimension) - sub-authentication interceptor 3 (corresponding to daily dimension)".

[0094] It should be noted that in the authentication process of a single order interceptor, permissions are deducted in the sub-authentication interceptors of each dimension in turn according to the current remaining resource demand, until the sub-authentication interceptor of the last dimension (such as the day dimension). If all dimensions of the current order interceptor meet the resource demand requested by the user, the permissions are deducted in turn and the data or service is returned, and the responsibility chain of each level is reversed; if the resource permissions of a certain level in the current order interceptor are not enough to deduct the current resource demand, the authentication process needs to enter the next order interceptor after completing the last sub-authentication interceptor of the current order interceptor.

[0095] S402. When the authentication process reaches a sub-authentication interceptor where the resource authority amount is insufficient to deduct the currently required resource amount, based on the actual resource amount deducted by the current sub-authentication interceptor, the deducted resource authority of the previous sub-authentication interceptor is rolled back in reverse order of the responsibility chain, and the actual resource amount deducted by the current sub-authentication interceptor is used as the currently required resource amount of the next sub-authentication interceptor to start the authentication process of the next sub-authentication interceptor.

[0096] It should be noted that in each order interceptor, even if the resource authority of a certain sub-authentication interceptor is not enough to deduct the current required resource amount, it will eventually go to the last sub-authentication interceptor of the current order interceptor. Among them, in the previous sub-authentication interceptor, if the resource authority is not enough to deduct the current required resource amount, the current required resource amount will be reduced according to the resource authority of the sub-authentication interceptor. After settlement, the remaining required resource amount is the insufficient resource amount for deduction, and the previous other sub-authentication interceptors are rolled back in reverse based on this resource amount. At the same time, the resource amount deducted by the current sub-authentication interceptor is used as the current required resource amount of the next sub-authentication interceptor. And so on, until the last sub-authentication interceptor of the current order interceptor is reached.

[0097] S403. When the authentication process reaches the last sub-authentication interceptor of the current order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, based on the actual resource amount deducted by the current sub-authentication interceptor, the deducted resource permissions of the previous sub-authentication interceptor are rolled back in reverse order according to the responsibility chain, and the remaining required resource amount after the settlement of the current sub-authentication interceptor is used as the current required resource amount of the next order interceptor to start the authentication process of the next order interceptor.

[0098] It should be noted that when the authentication process reaches the last sub-authentication interceptor of the current order interceptor (not the last order interceptor), there will be two situations: 1. The current resource demand has been reduced to zero, which means that the orders so far have met the resource permission consumption and the authentication is returned as successful; 2. The resource permission corresponding to the current sub-authentication interceptor is less than the current required resource amount, which means that the orders so far are still insufficient to deduct the permission consumption and it is necessary to proceed to the next order to obtain permission.

[0099] For the second situation mentioned above, the previous sub-authentication interceptors in this order interceptor are rolled back according to the actual amount of resources deducted by the current sub-authentication interceptor, and the remaining required resources after settlement of the current sub-authentication interceptor (the last sub-authentication interceptor of the current order interceptor) are used as the current required resources of the next order interceptor to start the authentication process of the next order interceptor.

[0100] It should be noted that in any sub-authentication interceptor, the resource authority may be insufficient to deduct the current resource demand. In this case, the part of the resources that the current sub-authentication interceptor cannot deduct needs to roll back the previously deducted resource authorities in sequence. For example, when the resource authority in the monthly dimension (such as 50) is less than the current resource demand (such as 60), the insufficient resource authority is 10, and the resource authority in the previous dimension (such as the total dimension) needs to be rolled back (the rollback amount is 10); after passing through the sub-authentication interceptor in the monthly dimension, the current resource demand becomes 50, and enters the sub-authentication interceptor in the daily dimension (assuming the resource authority is 20), then the insufficient resource amount is 50-20=30, and it is necessary to reversely roll back the resource authority in the monthly dimension and the resource authority in the total dimension by 30 respectively. Since the user's initial resource requirement is 60, and the current order interceptor only completes 20 resource permissions, there is still 60-20=40 resource requirements, and the authentication process of the next order interceptor is entered, and so on, until the current resource requirement is reduced to zero, or the last order interceptor is reached.

[0101] S404. When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource authority corresponding to the current sub-authentication interceptor is less than the current required resource authority, the deducted resource authority is rolled back in reverse order according to the responsibility chain, and the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

[0102] It should be noted that when the authentication process reaches the sub-authentication interceptor of the last order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is still less than the current required resource amount, it means that the accumulated resource permissions of all the user's orders are not enough to cover the resources currently requested, and the authentication failure is returned. At the same time, all resources that have been deducted in this authentication process are rolled back in reverse.

[0103] Based on this, by constructing sub-authentication interceptor responsibility chains corresponding to multiple permission authentication dimensions within the order interceptor, the authentication requirements of multi-dimensional permissions across orders are met, the scalability of the authentication process is further improved, and the response performance of multi-dimensional permission authentication in high-concurrency request scenarios is improved.

[0104] In some possible embodiments, step S404, when the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out, and the permission authentication failure result is returned, which may include:

[0105] S4041. When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, determine whether the current authentication scenario is a scenario that allows partial success;

[0106] If so, then the outer process interceptor responsibility chain is jumped out. Based on the remaining required resource amount after settlement of the current sub-authentication interceptor, the deducted resource permissions of other sub-authentication interceptors are rolled back in reverse order of the responsibility chain, and a partial success result of the resource request is returned based on the deducted resource permissions.

[0107] S4043. If not, roll back the deducted resource permissions in reverse order according to the responsibility chain, jump out of the outer process interceptor responsibility chain and return the permission authentication failure result.

[0108] It should be noted that when the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource authority corresponding to the current sub-authentication interceptor is less than the current required resource amount, it can be determined whether the current authentication scenario is a scenario that allows partial success. If partial authentication is allowed, a partial success result of the resource request is returned based on the resource authority that has been successfully deducted in all order interceptors. The remaining required resource amount after settlement of the current sub-authentication interceptor (the last sub-authentication interceptor of the last order interceptor) is the amount of resources that have not been successfully deducted so far. Based on the amount of resources that have not been successfully deducted, the previous sub-authentication interceptors of the current order interceptor are rolled back. It can be understood that since in other order interceptors before the current order interceptor, when the resource authority of a certain sub-authentication interceptor was insufficient for deduction, the relevant rollback operation has been performed, therefore, in this process (the authentication process of the last sub-authentication interceptor of the last order interceptor), there is no need to perform a resource rollback operation on other order interceptors.

[0109] Based on this, by providing authentication scenarios that allow partial success and rolling back the undeducted resource permissions layer by layer when partial authentication is successful, the flexibility and scalability of cross-order multi-dimensional permission authentication are further improved.

[0110] See also Figure 2 The embodiment of the present application provides a cross-order multi-level (and multi-dimensional) permission authentication system based on the concept of optimistic locking. It adopts the responsibility chain and adapter mode to dynamically encapsulate multiple orders into an order interceptor chain, and each order interceptor has multiple sub-authentication interceptors. By adopting a lock-free approach, the problem of excessive use of permissions is avoided, and a reverse hierarchical rollback solution is provided for step-by-step authentication and incomplete authentication. The ultimate consistency of permissions is guaranteed through the seamless rollback of the sub-chain and the rule verification rollback of the outer layer. The authentication process is abstracted into a cascading responsibility chain black box. The responsibility interceptors at each level have a single responsibility and do not interfere with each other, thus realizing cross-order multi-level and multi-dimensional permission authentication and consumption. At the same time, due to the single responsibility of each interceptor, the scalability of the authentication system is effectively improved, and the system response performance is maximized in high-concurrency request scenarios.

[0111] The embodiment of the present application constructs a three-level interceptor responsibility chain to implement the cross-order multi-dimensional authentication process, including the outermost outer process interceptor responsibility chain, the middle order interceptor responsibility chain, and the inner sub-authentication interceptor responsibility chain.

[0112] Note that when the authentication process enters an internal sub-authentication interceptor, to avoid overuse issues caused by concurrency, the Redis auto-increment operation can be used to increment the current dimension's usage by 1. The resulting usage (after deducting the resource demand) is then compared with the resource permissions for that dimension in the current order. If verification passes, the process proceeds to the next sub-authentication interceptor (or the sub-authentication interceptor responsibility chain of the next order interceptor) for verification. If verification fails (insufficient resource permissions), the excess usage (demand minus permissions) is calculated, and a partial overlimit exception is thrown. The main verification process in the sub-authentication interceptor responsibility chain catches the exception and reverses the loop from the current sub-authentication interceptor to enter the rollback process. Resources that do not exceed permissions (actually deducted resources) proceed to the next sub-authentication interceptor for verification of the next dimension.

[0113] For example, suppose in the daily sub-authentication interceptor, the order allows the user to access N resources (resource authority quantity) every day. The user requests N1 resources (resource demand quantity) this time. The amount used that day is recorded in redis. After entering the daily sub-authentication interceptor, the amount used today is first incremented in redis. The value after increment is assumed to be N2. Compare the values ​​of N2 and N. If N>=N2, it means that the daily-level interceptor verification has passed. If N1+N>N2>N, it means that N1+N-N2 resources have been successfully authenticated, and N2-N resources have failed to be authenticated.

[0114] It should be noted that the resource demand to be authenticated is the user's initial resource demand when entering the first sub-authentication interceptor. After passing each interceptor, the resource authority of this dimension may be less than the resource demand, resulting in only part of the resource demand passing the verification and entering the next sub-authentication interceptor. The resource demand that fails to pass the verification enters the reverse rollback process. After all sub-authentication interceptors are verified, the resource demand that finally passes the verification is the resource amount that can be consumed by the current resource request.

[0115] After an order interceptor's authentication and verification, if the authenticated resource quantity equals the current resource requirement (the resource requirement has been reduced to zero), authentication passes, and there's no need to proceed to the next order interceptor. If the authenticated resource quantity is less than the current resource requirement (the resource requirement has not been reduced to zero), the next order interceptor is entered, where the chained authentication and interception process of the sub-authentication interceptor is repeated.

[0116] Each time an order interceptor is passed, the amount of resources currently required (the current resource demand) is checked. If the current resource demand is 0, it means that the order interceptors that have passed the verification have met the user's total resource demand, and the authentication is successful. If the amount of resources required after settlement of an order interceptor is not 0, the next order interceptor is entered. If the amount of resources required after passing all order interceptors is still not 0, it means that the resource demand requested by the user exceeds the accumulated resource authority of all orders, and the authentication failure is returned, or scheduling is performed based on whether the current scenario allows partial success.

[0117] If a partially successful authentication scenario is allowed, that is, the actual deducted resource permissions are inconsistent with the resource requirements requested by the user, the corresponding business data will be returned based on the actual deducted resource quantities, and the resource permissions at each level will be rolled back in sequence based on the unsuccessful resource requirements.

[0118] If the authentication scenario does not allow partial success, that is, sufficient permissions are required for authentication to be considered successful, no resource business data will be returned, and the outer layer rollback process will be reversed to roll back according to the permission deduction details saved in the global context.

[0119] It should be noted that the rollback process is the reverse of the authentication process. Starting from the last order interceptor, the permissions deducted for the current order are retrieved from the global context, and the rollback begins at the last sub-chain interceptor. Once all sub-chains are rolled back, the current order interceptor is rolled back, and the process reverses to the next order interceptor. It should be noted that to prevent locking from affecting system responsiveness, the rollback process can also utilize Redis's auto-increment function. A negative auto-increment value is equivalent to a decrement.

[0120] Based on this, the cross-order multi-level permission authentication and deduction process is encapsulated using a three-layer interceptor responsibility chain. Each layer of the interceptor chain performs its own duties. The outer process interceptor responsibility chain promotes the overall process control. The order-level interceptor is responsible for the sub-chain process control and the corresponding rollback process control. The sub-chain interceptor is responsible for permission verification in different dimensions.

[0121] It should be noted that the process of the order-level interceptor includes the forward authentication process and the reverse rollback process. The authentication process is from the first sub-authentication interceptor to the last sub-authentication interceptor in sequence, and the rollback process is from the sub-authentication interceptor that currently needs to be rolled back to the first sub-authentication interceptor in reverse. The authentication of each sub-authentication interceptor may trigger the rollback process. When the Nth sub-authentication interceptor needs to be rolled back, the sub-authentication interceptors to be rolled back are N, N-1,...1 in sequence. When the N+1th sub-authentication interceptor needs to be rolled back, the sub-authentication interceptors to be rolled back are N+1, N, N-1,...1 in sequence.

[0122] Based on this, by using the method of advance deduction and layer-by-layer rollback, and with the help of the security capabilities of Redis's self-incrementing competitive resource threads, the locking behavior of multi-level permission authentication across orders is avoided, and the mechanism of layer-by-layer rollback is used to ensure that permissions are not overused. While ensuring the ultimate consistency of order permissions, the response performance of the authentication system in high-concurrency request scenarios is greatly improved. At the same time, the responsibilities of each level of the responsibility chain are single, and the maintainability and scalability of the system are enhanced through the abstract interceptor chain with similar functions.

[0123] In some possible embodiments, the outer process interceptor responsibility chain further includes a cache interceptor;

[0124] Before S2, it can also include:

[0125] S101. Obtain historical authentication records of the current resource request based on the cache interceptor, and determine whether the current resource request meets the preset consumption-free authentication conditions based on the historical authentication records;

[0126] S102: When it is determined that the current resource request meets the consumption-free authentication condition, the outer process interceptor responsibility chain is jumped out, and a successful result of the resource request is returned.

[0127] It should be noted that, considering that in actual scenarios, certain types of resources only require one authorization authentication within a certain period of time, for example, a resource that needs to be unlocked before viewing only needs to be unlocked once within the same day, and can be viewed an unlimited number of times on that day without the need for authorization authentication and consuming permissions each time.

[0128] Therefore, a cache interceptor can be added to the outer process interceptor responsibility chain. Before the order adapter interceptor starts working (or before step S2), the cache interceptor can be used as the first interceptor in the outer process interceptor responsibility chain. Based on the cache interceptor, the historical authentication record corresponding to the current resource request is obtained. If the resource type allows consumption-free authentication within a certain period of time, and the authentication time and authority information of the historical authentication record are judged to meet the consumption-free authentication conditions, then the current resource request authentication is directly judged to be successful, and the outer responsibility chain is jumped out and the corresponding data or service is returned without entering the order pulling and authority authentication process from S2 to S6. Otherwise, if the cache interceptor determines that the current resource request does not meet the consumption-free authentication conditions, the step process of steps S2 to S6 is executed normally.

[0129] Based on this, by adding a cache interceptor to the outer responsibility chain, the specific multi-order merging authentication process is omitted when it is judged that the consumption-free authentication conditions are met, thereby further improving the response efficiency of resource request authentication.

[0130] In some possible embodiments, step S3, using the order adapter interceptor to pull the order set corresponding to the current resource request and constructing an order interceptor responsibility chain corresponding to the order set, may include:

[0131] S301. Use the order adapter interceptor to pull the order set corresponding to the current resource request and obtain the order authority consumption policy corresponding to the current resource request; wherein the order authority consumption policy is used to represent the consumption priority of each order in the order set;

[0132] S302: Construct an order interceptor responsibility chain corresponding to the order set based on the order authority consumption strategy.

[0133] It should be noted that in the embodiment of the present application, the core of the outer process interceptor responsibility chain is the order adapter interceptor. The order adapter interceptor is responsible for obtaining the user's order set and the permission set of each order and normalizing the permission information data, and dynamically creating an order interceptor responsibility chain based on the order set.

[0134] When a user initiates a current resource request, they can configure the permission consumption priority for multiple existing orders according to their needs. That is, the user can prioritize the resource permissions of the order they want to deduct first. When the resource permissions of the order are insufficient, the user can obtain the next order and deduct the permissions, and so on.

[0135] When building the order interceptor responsibility chain corresponding to the order collection, it is built in order according to the order permission consumption strategy configured by the user.

[0136] Based on this, by determining the order of authorization authentication for each order according to the order authorization consumption strategy, the user's demand for customized configuration of order consumption priority is met, and the flexibility of multi-order authorization authentication is further improved.

[0137] It should be noted that the embodiment of the present application integrates multi-order and multi-dimensional permissions, and abstracts the authentication processes at all levels into permission interceptors based on the principle of high cohesion and low coupling. Through the construction of a three-layer responsibility chain and an internal rollback process, users are allowed to customize the use priority of orders. At the same time, multiple orders can be merged to achieve cumulative use of permissions, thereby improving the response performance of the system in high-concurrency request scenarios and ensuring the ultimate consistency of permissions. Since the overall process is highly abstract, whether it is the outer process interceptor responsibility chain or the inner sub-authentication interceptor extension, it only needs to follow the corresponding interface specifications, that is, the authentication verification process and rollback process can be customized according to needs, thereby quickly and conveniently enriching the verification rules, and it is also conducive to expanding the sales scenario of cloud service subscriptions.

[0138] In some possible embodiments, the outer process interceptor responsibility chain further includes at least one authentication interceptor connected in series with the order adapter interceptor, and the authentication order of the at least one authentication interceptor is before that of the order adapter interceptor.

[0139] It should be noted that in the outer process interceptor responsibility chain, in addition to the cache interceptor and order adapter interceptor, other authentication interceptors can also be defined and configured according to needs, such as resource cleanup interceptor, data type filtering interceptor, user IP interceptor, etc. The specific interception function can be set according to needs.

[0140] At the same time, the authentication order of different authentication interceptors can also be defined as required. Each authentication interceptor can be in series, forming an outer process interceptor responsibility chain together with the cache interceptor and / or order adapter interceptor. It should be noted that, unlike the cache interceptor, other authentication interceptors are usually configured to enter the next authentication interceptor after the previous authentication interceptor passes the authentication, until entering the order adapter interceptor, or, when an authentication interceptor fails to authenticate, it jumps out of the outer process interceptor responsibility chain and returns authentication failure.

[0141] Based on this, by adding at least one authentication interceptor before the order adaptation interceptor in the outer responsibility chain, the response efficiency in complex authentication process scenarios is further improved.

[0142] Please refer to Figure 3 , Figure 3 The following is a block diagram showing the composition of the cross-order multi-level authority authentication device provided by some embodiments of the present application. It should be understood that the cross-order multi-level authority authentication device is similar to the above Figure 1 Corresponding to the method embodiment, it is able to execute each step involved in the above method embodiment. The specific functions of the cross-order multi-level authority authentication device can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0143] Figure 3 The cross-order multi-level authority authentication device includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the cross-order multi-level authority authentication device, and the cross-order multi-level authority authentication device includes:

[0144] The outer chain building module 310 is used to build the outer process interceptor responsibility chain of the current resource request; wherein the outer process interceptor responsibility chain includes the order adapter interceptor;

[0145] The demand determination module 320 is configured to determine an initial resource demand corresponding to the current resource request;

[0146] An order chain construction module is configured to utilize an order adapter interceptor to retrieve an order set corresponding to a current resource request and construct an order interceptor responsibility chain corresponding to the order set; wherein the order set includes at least one order with a corresponding resource permission, and the order interceptor responsibility chain includes at least one order interceptor corresponding to the order set;

[0147] The authority authentication module 330 is configured to deduct the resource authority of each order interceptor based on the current resource requirement in the responsibility chain order of the order interceptor until the current resource requirement is zero or until the authentication process reaches the last order interceptor; wherein the current resource requirement is the remaining resource requirement after each deduction of the initial resource requirement;

[0148] The success result return module 340 is used to jump out of the outer process interceptor responsibility chain and return the resource request success result when the current resource demand is zero;

[0149] The resource rollback module 350 is used to roll back the deducted resource permissions in reverse order of the responsibility chain when the authentication process reaches the last order interceptor and the resource permissions corresponding to the current order interceptor are less than the current required resource permissions, jump out of the outer process interceptor responsibility chain and return the permission authentication failure result.

[0150] It can be understood that the above-mentioned device embodiment corresponds to the method embodiment of the present invention. The cross-order multi-level permission authentication device provided by the embodiment of the present invention can implement the cross-order multi-level permission authentication method provided by any method embodiment of the present invention.

[0151] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method, and will not be described in detail here.

[0152] like Figure 4 As shown, some embodiments of the present application provide an electronic device 400, which includes: a memory 410, a processor 420, and a computer program stored in the memory 410 and executable on the processor 420, wherein the processor 420 reads the program from the memory 410 through the bus 430 and executes the program to implement a method such as any embodiment of the above-mentioned cross-order multi-level authority authentication method.

[0153] Processor 420 can process digital signals and can include various computing architectures, such as a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements a combination of multiple instruction sets. In some examples, processor 420 can be a microprocessor.

[0154] The memory 410 can be used to store instructions executed by the processor 420 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all functions of one or more modules described in the embodiments of this application. The processor 420 of the embodiment of the present disclosure can be used to execute the instructions in the memory 410 to implement the method shown above. The memory 410 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memory known to those skilled in the art.

[0155] Some embodiments of the present application further provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method described in the method embodiment is executed.

[0156] Some embodiments of the present application further provide a computer program product, which, when running on a computer, enables the computer to execute the method described in the method embodiment.

[0157] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similarities between the various embodiments can be referred to in conjunction with each other. For device embodiments, since they are generally similar to method embodiments, their description is relatively simple, and for relevant details, reference can be made to the description of the method embodiments.

[0158] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of the devices, methods, and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment, or a portion of code, and the module, program segment, or a portion of code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0159] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0160] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or 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 USB flash drives, mobile hard drives, read-only memories (ROM), random access memories (RAM), magnetic disks or optical disks.

[0161] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0162] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0163] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A cross-order multi-level authority authentication method, characterized in that: include: Constructing an outer process interceptor responsibility chain for the current resource request; wherein the outer process interceptor responsibility chain includes an order adapter interceptor; determining an initial resource requirement corresponding to the current resource request; Utilizing the order adapter interceptor to pull an order set corresponding to the current resource request, and constructing an order interceptor responsibility chain corresponding to the order set; wherein the order set includes at least one order with a corresponding resource permission amount, and the order interceptor responsibility chain includes at least one order interceptor corresponding to the order set; Deducting the resource authority of each order interceptor based on the current resource requirement in the responsibility chain order of the order interceptor responsibility chain until the current resource requirement is zero, or until the authentication process reaches the last order interceptor; wherein the current resource requirement is the remaining resource requirement after each authority deduction from the initial resource requirement; When the current resource demand is zero, jump out of the outer process interceptor responsibility chain and return a successful resource request result; When the authentication process reaches the last order interceptor and the resource permissions corresponding to the current order interceptor are less than the current required resource permissions, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out, and the permission authentication failure result is returned; The responsibility chain order refers to the order from the first interceptor to the last interceptor in the responsibility chain; The rollback operation of the deducted resource permissions in reverse order of the responsibility chain includes: Perform the rollback operation in the reverse order from the interceptor that currently needs to be rolled back to the first interceptor.

2. The cross-order multi-level authority authentication method according to claim 1 is characterized in that: When the authentication process reaches the last order interceptor and the resource permissions corresponding to the current order interceptor are less than the current required resource permissions, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out, and the permission authentication failure result is returned, including: When the authentication process reaches the last order interceptor and the resource permission amount corresponding to the current order interceptor is less than the current required resource amount, determine whether the current authentication scenario allows partial success; If so, jump out of the outer process interceptor responsibility chain and return a partial success result of the resource request based on the deducted resource authority; If not, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

3. The cross-order multi-level authority authentication method according to claim 1 is characterized in that: Each order has resource permissions in multiple permission authentication dimensions, each order interceptor includes a sub-authentication interceptor responsibility chain, and each sub-authentication interceptor responsibility chain includes multiple sub-authentication interceptors corresponding to the multiple permission authentication dimensions; The resource authority of each order interceptor is deducted based on the current resource demand in the order of the responsibility chain of the order interceptor until the current resource demand is zero, or until the authentication process reaches the last order interceptor, including: In the authentication process of each of the order interceptors, the resource authority amount of each of the sub-authentication interceptors is deducted based on the current resource demand amount in the order of the responsibility chain of the sub-authentication interceptor, until the authentication process reaches a sub-authentication interceptor whose resource authority amount is insufficient to deduct the current resource demand amount, or until the authentication process reaches the last sub-authentication interceptor; When the authentication process reaches a sub-authentication interceptor whose resource permissions are insufficient to deduct the currently required resource permissions, based on the actual resource permissions deducted by the current sub-authentication interceptor, the deducted resource permissions of the previous sub-authentication interceptor are rolled back in reverse order according to the chain of responsibility, and the actual resource permissions deducted by the current sub-authentication interceptor are used as the current required resource permissions of the next sub-authentication interceptor to start the authentication process of the next sub-authentication interceptor. When the authentication process reaches the last sub-authentication interceptor of the current order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, based on the actual resource amount deducted by the current sub-authentication interceptor, the deducted resource permissions of the previous sub-authentication interceptor are rolled back in reverse order according to the responsibility chain, and the remaining required resource amount after the settlement of the current sub-authentication interceptor is used as the current required resource amount of the next order interceptor to start the authentication process of the next order interceptor; When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission corresponding to the current sub-authentication interceptor is less than the current required resource amount, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, and the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

4. The cross-order multi-level authority authentication method according to claim 3 is characterized in that: When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource authority corresponding to the current sub-authentication interceptor is less than the current required resource authority, the deducted resource authority is rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out, and the authority authentication failure result is returned, including: When the authentication process reaches the last sub-authentication interceptor of the last order interceptor, and the resource permission amount corresponding to the current sub-authentication interceptor is less than the current required resource amount, determine whether the current authentication scenario is a scenario that allows partial success; If so, then jump out of the outer process interceptor responsibility chain, and based on the remaining required resource amount after the current sub-authentication interceptor is settled, roll back the deducted resource permissions of other sub-authentication interceptors in reverse order according to the responsibility chain, and return a partial success result of the resource request based on the deducted resource permissions; If not, the deducted resource permissions are rolled back in reverse order according to the responsibility chain, the outer process interceptor responsibility chain is jumped out and the permission authentication failure result is returned.

5. The cross-order multi-level authority authentication method according to claim 1 is characterized in that: The outer process interceptor responsibility chain also includes a cache interceptor; Before determining the initial resource requirement corresponding to the current resource request, the method further includes: Obtaining a historical authentication record of the current resource request based on the cache interceptor, and determining whether the current resource request meets a preset consumption-free authentication condition according to the historical authentication record; When it is determined that the current resource request meets the consumption-free authentication condition, the outer process interceptor responsibility chain is jumped out and a successful result of the resource request is returned.

6. The cross-order multi-level authority authentication method according to claim 1 is characterized in that: The utilizing the order adapter interceptor to pull the order set corresponding to the current resource request and constructing an order interceptor responsibility chain corresponding to the order set includes: Utilizing the order adapter interceptor to pull the order set corresponding to the current resource request, and obtaining the order authority consumption policy corresponding to the current resource request; wherein the order authority consumption policy is used to represent the consumption priority of each order in the order set; An order interceptor responsibility chain corresponding to the order set is constructed based on the order authority consumption strategy.

7. The cross-order multi-level authority authentication method according to claim 1 is characterized in that: The outer process interceptor responsibility chain also includes at least one authentication interceptor connected in series with the order adapter interceptor, and the authentication order of the at least one authentication interceptor is arranged before the order adapter interceptor.

8. An electronic device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the cross-order multi-level authority authentication method described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, executes the cross-order multi-level authority authentication method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the cross-order multi-level authority authentication method described in any one of claims 1 to 7.

Images