A permission data processing method, system and storage medium

Abstract

The present application relates to the field of computers, and discloses a permission data processing method, system and storage medium. When the method is applied to the management end, it includes: publishing a software development kit so that the application end integrates the software development kit to communicate with the management end; maintaining various interface information and user data in real time; generating a permission association path according to the interface information so that the application end performs interface permission verification on the user operation request according to the permission association path; sending user data to the application end so that the application end performs data permission verification on the user operation request. In the present application, the application end can quickly implement the permission verification function by integrating the software development kit to run the permission control logic therein, avoiding code changes on the application end, and reducing the code logic intrusion of the business layer.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a permission data processing method, system and storage medium. Background Art

[0002] At present, in order to ensure the security of data access within the system, corresponding permission checks need to be set. Generally speaking, these permission check functions need to be written in the underlying code before the system goes online, and once the code is written and set, it cannot be easily changed. This means that if you want to change the permission settings, you need to rewrite the code and re-release the system, which greatly reduces the flexibility of the system permission check configuration. Summary of the invention

[0003] In view of this, in order to solve the problems existing in the prior art, the present application provides a permission data processing method, system and storage medium.

[0004] In a first aspect, the present application provides a permission data processing method, which is applied to a management end, comprising:

[0005] Release a software development kit so that the application end integrates the software development kit to communicate with the management end, and runs the permission control logic in the software development kit to intercept user operation requests through corresponding interfaces and perform permission verification on the user operation requests;

[0006] Maintaining interface information and user data of each interface in real time; the interface is an internal interface of the application end or an interface supported by the application end;

[0007] Generate a permission association path according to the interface information, so that the application end performs interface permission verification on the user operation request according to the permission association path;

[0008] The user data is sent to the application end, so that the application end performs data permission verification on the user operation request according to the user data through a corresponding interface.

[0009] In a second aspect, the present application provides a permission data processing method, which is applied to an application end, wherein the application end includes multiple interfaces and a logic controller, each of the interfaces is connected to the logic controller, and the method includes:

[0010] Integrate the software development kit released by the management end to communicate with the management end; wherein the software development kit includes permission control logic;

[0011] Run the permission control logic, intercept the user operation request at the corresponding interface, and perform permission verification on the user operation request; the permission verification includes one or both of interface permission verification and data permission verification; the user operation request is used to allow access to the logic controller after determining that the permission verification has passed.

[0012] In an optional implementation manner, if the permission check is an interface permission check, performing permission check on the user operation request includes:

[0013] The permission association path of the current interface and the user information used to initiate the user operation request are obtained, and the user information is subjected to permission verification according to the permission association path.

[0014] In an optional implementation manner, performing permission verification on the user information according to the permission association path includes:

[0015] Determine whether there is a first authority path including the user information in the authority association path, and whether there is a second authority path including the current interface information;

[0016] If the first permission path and the second permission path exist, determining whether the first permission path and the second permission path can be spliced ​​into a complete permission association path;

[0017] If yes, then determine that the interface permission check passes;

[0018] If not, it is determined that the interface permission check fails.

[0019] In an optional implementation manner, obtaining the permission association path of the current interface includes:

[0020] Requesting the management end for first local associated path data, and obtaining internally stored second local associated path data; wherein the first local associated path data and the second local associated path data do not overlap;

[0021] A complete permission association path of the current interface is obtained according to the first local association path data and the second local association path data.

[0022] In an optional implementation manner, if the permission check is a data permission check, performing permission check on the user operation request includes:

[0023] Obtaining permission annotation information and user data on the logic controller corresponding to the user operation request;

[0024] According to the permission annotation information, verification data for performing data permission verification is obtained from the user operation request; wherein the permission annotation information is used to indicate the data type and field information for which data permission verification needs to be performed;

[0025] Determining whether the user data is consistent with the verification data;

[0026] If they are consistent, it is determined that the data permission check has passed;

[0027] If they are inconsistent, it is determined that the data permission check fails.

[0028] In an optional embodiment, it also includes:

[0029] If the verification data cannot be obtained from the user operation request, the user operation request is forwarded to the logic controller, so that the logic controller obtains the target user data from the management end and performs permission verification on the user operation request according to the target user data.

[0030] In a third aspect, the present application provides a rights data processing system, including:

[0031] A management terminal, used to execute the permission data processing method of the first aspect;

[0032] The application side is used to execute the permission data processing method of the second aspect.

[0033] In a fourth aspect, the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor is used to execute the computer program to implement the aforementioned permission data processing method.

[0034] In a fifth aspect, the present application provides a computer storage medium storing a computer program, which, when executed on a processor, implements the aforementioned permission data processing method.

[0035] The embodiments of the present application have the following beneficial effects:

[0036] An embodiment of the present application provides a method for processing permission data, which is applied to a management end, including: publishing a software development kit so that an application end integrates the software development kit to communicate with the management end, and running the permission control logic in the software development kit to intercept user operation requests through the corresponding interface of the application end and then perform permission verification on the user operation request; maintaining interface information and user data of each interface in real time; generating a permission association path based on the interface information, so that the application end performs interface permission verification on the user operation request based on the permission association path; and sending user data to the application end, so that the application end performs data permission verification on the user operation request based on the user data through the corresponding interface. The embodiment of the present application embeds permission control logic into the application end through a software development kit, and realizes the communication connection and data docking between the application end and the management end through the software development kit. The application end can quickly implement the permission verification function internally by running the permission control logic, avoiding the system re-release caused by changing the code on the application end, and reducing the code logic intrusion of the business layer; at the same time, based on the permission control logic, the permission data can be set and changed in real time on the management end, and the updated permission data can be directly used to complete the permission verification without the need for additional processing on the application end, thereby improving the flexibility of the permission verification configuration and reducing the subsequent maintenance cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solution of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present application and should not be regarded as limiting the scope of protection of the present application. In each of the drawings, similar parts belonging to the same part are numbered similarly.

[0038] Figure 1 A schematic diagram of the structure of the authority data processing system in an embodiment of the present application is shown;

[0039] Figure 2 A first flow chart of the method for processing management-side execution authority data in an embodiment of the present application is shown;

[0040] Figure 3 A first flow chart of a method for processing application-side execution authority data in an embodiment of the present application is shown;

[0041] Figure 4 A second flow chart of the method for processing application-side execution authority data in an embodiment of the present application is shown;

[0042] Figure 5 A third flow chart of the application-side execution permission data processing method in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0043] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments.

[0044] The components of the embodiments of the present application generally described and shown in the drawings herein may be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0045] Hereinafter, the terms "including", "having" and their cognates, which may be used in various embodiments of the present application, are intended only to indicate specific features, numbers, steps, operations, elements, components, or combinations of the foregoing items, and should not be understood as first excluding the existence of one or more other features, numbers, steps, operations, elements, components, or combinations of the foregoing items or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations of the foregoing items.

[0046] Furthermore, the terms “first”, “second”, “third”, etc. are merely used for distinguishing descriptions and are not to be understood as indicating or implying relative importance.

[0047] Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meanings as those generally understood by those skilled in the art to which the various embodiments of the present application belong. The terms (such as those defined in generally used dictionaries) will be interpreted as having the same meanings as the contextual meanings in the relevant technical field and will not be interpreted as having idealized meanings or overly formal meanings unless clearly defined in the various embodiments of the present application.

[0048] The embodiment of the present application provides a permission data processing system. For example, Figure 1 As shown, the system includes a management terminal 100 and an application terminal 200; wherein the management terminal 100 encapsulates a software development kit (SDK) and publishes the SDK. The application terminal 200 can integrate the SDK, and then realize the communication connection and data docking between the management terminal 100 and the application terminal 200 through the SDK; wherein the SDK includes permission control logic and corresponding configuration data, etc.; the application terminal 200 performs permission verification operations by running the permission control logic, and performs data docking with the management terminal 100.

[0049] That is, the application end 200 runs the permission control logic by integrating the SDK to perform the corresponding permission verification operation. This means that the application end 200 does not need to develop an additional system framework code for executing permission control, nor does it need to add additional corresponding code at the business layer. It can achieve permission control of user operation requests initiated by users with less business logic intrusion. In addition, the management end 100 can also manage the permission data required by the application end 200 in real time, so as to send updated permission data to the application end 200 in real time through data docking with the application end 200, without the need for the application end 200 to control the permission data, thereby avoiding memory usage of the application end 200.

[0050] For reference, the application end 200 includes a plurality of interfaces and a logic controller, each interface being connected to a logic controller, wherein a user can access the logic controller through each interface and then execute a corresponding user operation request.

[0051] It can be understood that the user logs in to the application end 200 and initiates a user operation request. The user operation request carries the interface address of the target interface. The target interface of the application end 200 corresponds to receiving the user operation request, so that the user operation request can access the logic controller through the corresponding interface of the application end 200; wherein, the application end 200 runs the permission control logic so that each interface of the application end 200 intercepts the user operation request initiated by the user and performs a permission check on it. During this process, the application end 200 can obtain permission data from the management end 100, and perform a check on the user operation request based on the permission data. If the operation request passes the corresponding permission check, the operation request is allowed to access the logic controller.

[0052] It should be noted that the permission management includes permission verification at two different levels: permission verification at the interface level (i.e., interface permission verification) and permission verification at the data level (i.e., data permission verification); the application end 200 can perform one or both of the above two permission verifications based on the permission control logic.

[0053] Furthermore, the management end 100 can correspondingly manage the user data used to perform data permission verification in the application end 200 and the corresponding interface permission information of each interface used to perform interface permission verification. Then, the management end 100 sends the updated user data to the application end 200 in real time and updates the interface permission information of the application end 200 in real time, so that the application end 200 can take effect in real time the permission information configuration of the interface based on the configuration of the management end 100, and receive the user data sent by the management end 100, so that the application end 200 does not need to additionally manage related permission data, reduces memory usage and avoids interference with other business functions and business data.

[0054] Correspondingly, in one example, Figure 2 As shown, the process of the management terminal 100 performing data processing may include the following steps:

[0055] S110, released software development kit.

[0056] S120, maintaining interface information and user data of each interface in real time.

[0057] S130, generating a permission association path according to the interface information, so that the application end 200 performs interface permission verification on the user operation request according to the permission association path.

[0058] S140, sending the user data to the application end 200, so that the application end 200 performs data permission verification on the user operation request according to the user data through the corresponding interface.

[0059] The management end 100 pre-creates a software development kit (SDK) containing permission control logic; wherein, the SDK contains necessary classes, interfaces, methods, etc. for integrating permission management functions into applications, and the SDK internally encapsulates the core logic of permission verification, including functions such as identifying user requests, calling permission verification methods, and returning verification results.

[0060] Then, the management end 100 publishes the SDK, and the publishing method includes but is not limited to network services (such as HTTP, API, etc.) or broadcasting. Then, the application end 200 can integrate the SDK published by the management end 100 and run the permission control logic of the SDK to perform permission management. Specifically, the permission control logic is used to intercept user operation requests through the corresponding interface of the application end 200 and then perform permission verification on the user operation requests.

[0061] In one example, a management backend is also developed and deployed inside the management end 100, which can maintain and manage the permission data and resources required in the application end 200, such as interfaces and user data, in real time. In addition, the management end 100 realizes data interaction with the SDK running on the application end 200 through the management backend, and the management backend can dynamically configure the interface information and user data used by the application end 200 to perform permission verification, and push or broadcast updated user data to the SDK of the application end 200 in real time; then, the application end 200 performs permission verification based on the interface information and user data maintained in real time by the management end 100.

[0062] It should be noted that in the process of executing interface permission verification and data permission verification, both interface permission verification and data permission verification can be implemented through permission association paths. Furthermore, the management background can manage and configure the permission association paths used to execute interface permission verification and data permission verification accordingly. That is, when the management background maintains interface information and user data, it can generate corresponding permission association paths according to the interface information and user data respectively. The permission association path can be understood as a virtually set association relationship; wherein, the permission association path containing interface information represents the association relationship related to each interface and used for interface permission verification; the permission association path containing user data indicates the association relationship related to each user and used for data permission verification.

[0063] For example, the permission association path related to the interface permission verification process can be set to include four parameter items: "user--role--menu--interface"; among them, a sub-path can be formed between two adjacent parameter items, such as "user-role", "role-menu", and "menu-interface", and the three sub-paths can be spliced ​​into a complete interface permission path.

[0064] Furthermore, the management end 100 maintains detailed information of the interface used to perform permission verification in real time in the management background, such as interface name, purpose, access path, etc., and if a new interface is needed to be added for permission verification, it is only necessary to configure the permission association path of the new interface in the management background, so that the target interface of the application end 200 (that is, the new interface maintained by the management end 100) can have the function of executing permission verification, thereby realizing dynamic configuration of the interface permission verification function.

[0065] Specifically, if the application end 200 needs to add the permission control logic of the corresponding interface, the interface information (such as interface address, etc.) of the interface to be added can be entered through the management background of the management end 100, and then the sub-path in the corresponding permission association path can be updated according to the interface information. The corresponding interface can be quickly enabled to have the interface permission verification function without modifying additional code, etc., thereby improving the flexibility of the permission control configuration.

[0066] For example, the interface information to which the permission control logic needs to be added can be entered into the corresponding interface configuration page in the management background, and the permission association path for the interface can be bound on that page to complete the configuration of the interface permission control logic of the interface, thereby generating or updating the binding rules for interface permissions (permission association path) to clarify which interfaces can be accessed by which users or roles, etc. Furthermore, the interface configured with the relevant permission control logic can intercept user operation requests initiated by users and perform interface permission verification on the user operation requests.

[0067] Among them, the process of the management end 100 maintaining the interface information of the newly added interface can be to only modify or add the "Menu-Interface" sub-path to change the information of the parameter item "Interface" in the sub-path to the interface information corresponding to the newly added interface (such as the name or number of the newly added interface or the interface address, etc., which is used to uniquely indicate the newly added interface); then, the updated "Menu-Interface" sub-path can be selected from the currently maintained "User-Role", "Role-Menu" sub-paths as needed to splice into a complete permission association path.

[0068] In one example, the permission association path related to the data permission verification process can be set to include three parameter items: "user-role-data". Similar to the interface permission path, a sub-path can be formed between two adjacent parameter items in the data permission association path, such as "user-role" and "role-data", and the two sub-paths can be spliced ​​into a complete data permission path.

[0069] The management end 100 can also enter or update the user's permission data (i.e., the permission association path used to perform data permission verification) in the management background, including but not limited to the data objects that the user can access, the operation type (such as reading, writing), and whether there are specific access restrictions, etc. Based on the data permission information, the management background can generate or update the relationship between the user and the data resources that can be requested or accessed, clarify which users or roles can access which data resources, etc., so that the application end 200 can perform data permission verification on the user operation request intercepted by the interface based on the user data.

[0070] Similar to maintaining the interface information of the newly added interface, if the management end 100 needs to maintain the updated user data for authority verification, the authority association path corresponding to the user data can also be adjusted accordingly.

[0071] For example, if you need to add data access rights for a new user, then search for the "user-role" sub-path from the maintained permission association path related to data permission verification, and change the information of the "user" parameter item in the sub-path to the new user's identification information such as the user name, which is used to uniquely indicate the new user; then, the updated "user-role" sub-path can be selected from the target sub-path in the currently maintained "role-data" sub-path to splice into a complete permission association path as needed.

[0072] Obviously, in this embodiment, when the management terminal 100 maintains the interface information and user data by means of the permission association path, if the interface information and user data used for permission verification need to be changed, only one sub-path in the maintained relevant permission association path can be updated, without changing all the associations, thereby reducing the amount of data required to be changed, simplifying the change process, improving the change efficiency, and facilitating subsequent maintenance work. In addition, if the currently maintained permission association path cannot meet the needs, a new permission association path can be adaptively generated according to the needs to supplement it, that is, this embodiment can flexibly adjust the permission association path to meet the different needs of users.

[0073] In addition, the management backend supports a real-time or near real-time data synchronization mechanism, thereby ensuring that the permission data updated in the background (including the permission association path corresponding to the interface permission check and the data permission check, etc.) can be quickly reflected in the SDK of the application end 200, that is, the updated user data is sent to the application end 200 in real time, so that the application end 200 performs permission checks on the user operation requests initiated by the user according to the updated user data and the internally stored user data. Among them, the update process of the user data includes adding or modifying; if the updated user data is the modified permission data, then when performing permission checks, the application end 200 can only perform the verification operation according to the updated user data.

[0074] In one example, when the application end 200 receives a user operation request, it performs interface permission verification and data permission verification on the user operation request according to the user data and interface permission binding information obtained from the management end 100. If the user operation request initiated by the user matches the corresponding interface permission and / or data permission, the user is allowed to access the logic controller to execute the user operation request; otherwise, an error message is returned or the operation is blocked.

[0075] It can be seen that this embodiment can build a dynamic, flexible and secure permission management system through the permission control logic, ensuring that only authorized user operation requests can be executed, effectively preventing unauthorized access and misoperation, and improving the security of data access and requests on the application side 200.

[0076] The following is a detailed description of the process of the application end 200 performing permission verification by taking an example only.

[0077] For example, Figure 3 As shown, the process of the application end 200 performing permission data processing may include the following steps:

[0078] S210, integrating the software development kit released by the management terminal 100 to establish a communication connection with the management terminal 100.

[0079] S220, running the permission control logic in the software development kit, intercepting the user operation request at the corresponding interface, and performing permission verification on the user operation request.

[0080] In one embodiment, during the process of integrating the software development kit (i.e., SDK), the application end 200 packages the SDK as a dependency of the application. During the application running process, the permission control logic in the SDK will automatically take effect. Then, the application end 200 can use the permission control logic to verify the permission of user operation requests initiated by each user, so as to improve the security of each user's access to the logic controller.

[0081] Among them, the application end 200 can perform one or both of the interface permission check and the data permission check on the user operation request initiated by each user based on actual needs; optionally, if two permission checks are performed, the execution order of the two permission checks can also be set accordingly according to the needs, such as the two checks can be performed simultaneously or one after the other; and, if the result of any one of the permission checks is not passed, the user operation request is discarded, and the verification failure information is fed back to the user. For example, the permission check at the interface level is first performed on the intercepted user operation request, and then the permission check at the data level is performed, and if the permission check at the interface level fails, the permission check at the data level is not performed, and the user operation request is discarded.

[0082] When performing interface permission verification, the application end 200 can determine from the permission data corresponding to the user based on the user information whether the user has a complete permission path including the four parameter items of user, role, menu and interface; if the user has an incomplete permission path (such as a sub-path that only includes the "user-role" part, etc.) or has no corresponding permission path, it means that the user does not have the permission to access the logic controller through the current interface, that is, the interface permission verification fails; otherwise, it means that the interface permission verification passes.

[0083] In some examples, when performing data permission verification, the application end 200 can determine whether the user has a complete permission path including the three parameter items of user, role, and data from the user data corresponding to the user based on the user information; if the user has an incomplete permission path (such as a sub-path that only includes the "user-role" part, etc.) or has no corresponding permission path, it means that the user does not have the permission to access the logic controller through the current user operation request, that is, the data permission verification fails; otherwise, it means that the data permission verification passes.

[0084] Among them, various parameter items involved in the above-mentioned interface authority path and data authority path can be adjusted accordingly according to actual needs, and this embodiment does not limit this.

[0085] This embodiment manages the permission information of data and interfaces through the permission association path. On the one hand, the permission data of the interface or data corresponding to each user can be quickly located from the permission path through user information, and the association relationship between each parameter item in the permission association path can be managed conveniently, thereby improving management efficiency. On the other hand, when the permission data of the interface or data is subsequently updated (such as adding or deleting the permission association relationship corresponding to the role type), only the permission path of the part that needs to be updated can be adjusted, without adjusting the association relationship between all data, thereby reducing the amount of data that needs to be updated and reducing the workload of data updating, thereby improving data updating efficiency.

[0086] In one example, the process of the application end 200 performing interface permission verification on the user operation request is to obtain the permission association path of the current interface and the user information used to initiate the user operation request, and perform permission verification on the user information according to the permission association path.

[0087] For example, Figure 4 As shown, the process of the application end 200 performing interface authority verification may include the following steps:

[0088] S410, determining whether there is a first authority path including user information in the authority association path, and whether there is a second authority path including current interface information.

[0089] S420: If the first permission path and the second permission path exist, determine whether the first permission path and the second permission path can be spliced ​​into a complete permission association path.

[0090] S430: If the first permission path and the second permission path can be spliced ​​into a complete permission association path, it is determined that the interface permission check has passed.

[0091] S440: If the first permission path and the second permission path cannot be combined into a complete permission association path, it is determined that the interface permission check fails.

[0092] Exemplarily, after the corresponding interface intercepts a user operation request, it determines whether there is a first permission path corresponding to the user information and a second permission path corresponding to the current interface information from the permission data obtained from the management end 100 or the permission data stored internally in the application end 200 based on the user information corresponding to the user operation request and the interface information corresponding to the current interface.

[0093] That is, from the permission association path, determine whether there is a sub-path containing the two parameter items of "user-role" (i.e. corresponding to the first permission path mentioned above) based on the user information, and determine whether there is a sub-path containing the two parameter items of "menu--interface" (i.e. corresponding to the second permission path mentioned above) based on the interface information; if both sub-paths exist, further determine whether the two sub-paths can be spliced ​​into a complete permission association path maintained by the management end 100.

[0094] If the above two sub-paths cannot be spliced ​​into a permission-associated path, it means that the user does not have the corresponding interface permission, and it is determined that the interface permission check corresponding to the user operation request fails; otherwise, it is determined that the interface permission check passes.

[0095] For example, when the application end 200 performs an interface permission check on a user operation request intercepted at the current interface, it first obtains a sub-path (referred to as sub-path A) containing the two parameter items "user-role" from among multiple permission-associated paths related to the interface permission check process (such as the four parameter items "user-role-menu-interface") based on the user information corresponding to the user operation request, wherein the "user" parameter item in the sub-path indicates the user name in the user information, and the "role" parameter item indicates the user identity in the user information.

[0096] And, according to the interface information corresponding to the current interface, a sub-path (recorded as sub-path B) including the two parameter items "menu-interface" is obtained from the aforementioned permission association path. Among them, the "interface" parameter item in the sub-path indicates the name or number or interface address of the current interface, which is used to uniquely indicate the interface.

[0097] Then, it is determined whether sub-path A and sub-path B can be spliced ​​into a complete permission association path maintained in the management terminal 100 .

[0098] This process can be understood as: a complete path (denoted as path X) including four parameter items of "user-role-menu-interface" is formed according to sub-path A and sub-path B; wherein, if the path X is a complete permission-associated path maintained by the management terminal 100, path X can be formed according to sub-path A and sub-path B, and then it is determined that the interface permission check has passed; conversely, if the path X is not a complete permission-associated path maintained by the management terminal 100, a complete permission-associated path cannot be formed according to sub-path A and sub-path B, and then it is determined that the interface permission check has failed.

[0099] In one example, to reduce memory usage, the application end 200 may store only part of the permission association path, that is, the application end 200 may pre-store part of the association relationship in the permission association path, and the other part is obtained from the management end 100 when verification is needed.

[0100] It can be understood that for each complete permission association path in the interface permission data, one, two or three sub-paths in the same permission association path can be stored in the application end 200, and the remaining sub-paths in the permission association path can be stored in the management end 100; wherein, for a complete permission association path, the number of sub-paths stored by the application end 200 and the management end 100 is set accordingly according to actual needs, and this embodiment does not limit it; for example, the application end 200 can store the sub-path containing the two parameter items "menu-interface" correspondingly, and the remaining sub-paths are stored correspondingly in the management end 100. Further, if the application end 200 needs to perform interface permission verification, the corresponding remaining sub-paths are obtained from the management end 100 according to user information or interface information.

[0101] It can be understood that before executing the interface permission check, the application end 200 can first request the first local associated path data from the management end 100 according to the user information or the interface information, and obtain the second local associated path data stored internally; wherein the first local associated path data and the second local associated path data do not overlap or partially overlap, and then, the permission associated path of the current interface is determined according to the first local associated path data and the second local associated path data. The first local associated path data and the second local associated path data can be data containing permission associated sub-paths corresponding to multiple interfaces or only contain permission path data corresponding to the current interface; that is, the first local associated path data is the partial sub-path data corresponding to the target interface stored by the management end 100, and the second local associated path data is the partial sub-path data corresponding to the target interface stored by the application end 200.

[0102] For example, determine whether there is data of a complete permission association path corresponding to the current interface in the first local association path data and the second local association path data. If it is determined that it contains data that can constitute a complete permission association path corresponding to the current interface, it means that the user has the corresponding interface permission, and the interface permission check corresponding to the user operation request passes; otherwise, it is determined that the interface permission check fails.

[0103] Optionally, after completing the interface permission check, the application end 200 may delete the sub-path requested from the management end 100 to reduce the amount of data that the application end 200 needs to store and release the corresponding memory space.

[0104] In some examples, such as Figure 5As shown, the process of the application end 200 performing data permission verification on the intercepted user operation request may include the following steps:

[0105] S510, obtaining permission annotation information and user data on the logical controller corresponding to the user operation request.

[0106] S520, obtaining verification data for performing data permission verification from the user operation request according to the permission annotation information.

[0107] S530, determining whether the user data is consistent with the verification data.

[0108] S540: If the user data is consistent with the verification data, it is determined that the data permission verification has passed.

[0109] S550: If the user data is inconsistent with the verification data, it is determined that the data authority verification fails.

[0110] The logic controller is pre-bound with permission annotation information, which is used to indicate the data type and field information that need to perform data permission verification. That is, when a user logs in to the application end 200 and initiates a user operation request (such as querying orders, modifying orders, and other normal business operations) to access the logic controller, the application end 200 performs data permission verification on the user operation request intercepted by the corresponding interface through the permission annotation information bound to the logic controller.

[0111] Furthermore, the application end 200 obtains verification data corresponding to the data type and field information indicated in the permission annotation information from the intercepted user operation request through the permission annotation information, and compares the verification data with the user data stored internally or requested from the management end 100; wherein, if the verification data is consistent with the user data, it is determined that the data permission check has passed; otherwise, it is determined that the data permission check has failed.

[0112] The user data indicates the association relationship between each user and the corresponding accessible data resources.

[0113] In one example, similar to the interface permission verification process, the management end 100 can associate and store user data through a permission association path when maintaining user data, and the application end 200 can also perform data permission verification based on the corresponding permission association path.

[0114] When a user logs in to the application end 200 to request access to the logic controller, the application end 200 intercepts the user operation request through the corresponding interface and obtains the user's information. Based on the user information, the role corresponding to the logged-in user and the data bound to the role can be obtained (that is, the permission association path corresponding to the user is found through the user information), so as to determine whether the user has the authority to access or request the corresponding data object in the logic controller.

[0115] Among them, the application end 200 obtains a sub-path (which can be recorded as sub-path C) containing the two parameter items "user-role" in the permission association path related to the data permission verification process (such as the three parameter items "user-role-data") according to the user information, wherein the "user" parameter item in the sub-path indicates the user name in the user information, and the "role" parameter item indicates the user identity in the user information.

[0116] Then, based on the aforementioned sub-path C, a sub-path (denoted as sub-path D) containing the two parameter items "role-data" is searched from the permission association path; among them, the content corresponding to the parameter item "role" in these two sub-paths (sub-path C and sub-path D) is the same.

[0117] Next, the data information corresponding to the parameter item "data" is obtained from sub-path D, and the data information is compared with the verification data. If the two are consistent, it is determined that the data permission verification has passed; otherwise, it is determined that the data permission verification has failed.

[0118] It can be understood that if during the data permission verification process, the data bound to the corresponding role of the logged-in user does not include the data required to be requested or accessed in the user's operation request, that is, the corresponding permission association path is not found or the data information corresponding to the "data" parameter item in the target permission association path is inconsistent with the data required to be requested or accessed by the user, then it means that the user does not have the permission to access or request the data; otherwise, it means that the user has the corresponding permission.

[0119] As an optional implementation, the application end 200 can pre-store part of the association relationship in the permission association path, and obtain the other part from the management end 100 when verification is needed. The specific storage method and storage logic are consistent with the corresponding parts in the above-mentioned interface permission verification process, so they will not be repeated here.

[0120] In some examples, when the application end 200 performs data permission verification on a user operation request initiated by a logged-in user, it can simultaneously request the user data corresponding to the logged-in user from the management end 100; wherein, the application end 200 can store the user data locally during the user's login period, so as to perform data verification on multiple user operation requests subsequently initiated by the user during the login period, thereby eliminating the need to obtain user data from the management end 100 multiple times.

[0121] It can be understood that the application end 200 can reduce the local memory usage of the permission data by acquiring the user data after the user logs in and initiates a user operation request; and during the same login of the user, the user data can also be stored or deleted based on the local memory requirements of the application end 200. That is, the application end 200 can set the storage method of the user data based on its own memory usage requirements, such as acquiring it as soon as it is used or pre-storing it locally for multiple calls, etc., and this embodiment does not limit this.

[0122] In some examples, if verification data cannot be obtained from the user operation request, the user operation request is forwarded to the logic controller, so that the logic controller obtains corresponding user data from the management end 100 and performs permission verification on the user operation request according to the corresponding user data.

[0123] It can be understood that if the user operation request does not contain data for performing data permission verification, the corresponding interface will forward the user operation request directly to the logic controller, so that the logic controller will perform the corresponding permission verification operation according to internal needs, wherein the logic controller can obtain the user data of the user from the management end 100 to verify the user operation request based on the user data.

[0124] In one embodiment, the permission association path related to data permission verification, the application end 200 and the management end 100 can also respectively store part of the permission association path, that is, the application end 200 can pre-store part of the association relationship in the permission association path, and the other part can be obtained from the management end 100 when data verification is required; wherein, the corresponding processing process is consistent with the corresponding part in the interface permission verification process, so it will not be repeated here.

[0125] It can be understood that, before executing the user operation request, the present embodiment first performs interface permission verification and / or data permission verification on the interface side, so that the verification of the user operation request can be completed before the user operation request is actually processed, and it is determined whether the user has the corresponding permission, thereby ensuring the security of system access. In addition, the present embodiment can implement the corresponding permission verification based on the permission control logic in the software development kit, without modifying the underlying code of the application end 200, and without re-publishing and launching; wherein, if it is necessary to perform data permission verification, it is only necessary to add the corresponding permission annotation information on the logic controller side; and if it is necessary to perform interface permission verification, the permission information of the interface can be directly configured and bound on the management end 100; and then, whether it is configuring data permission verification or interface permission verification, the permission setting can be adjusted without modifying the code, and the present embodiment can also dynamically adjust the permission setting according to different needs, making the permission control more efficient and flexible, and also reducing the burden on developers; at the same time, relying on the permission control logic, the entire permission verification process is more automated, reducing the need for manual intervention, and also improving the flexibility and reliability of permission verification.

[0126] The embodiment of the present application also provides a computer device, which can be, but is not limited to, a desktop computer, a notebook, a smart phone, a tablet, etc., and its existence form is not limited, mainly depending on whether it needs to support the interface display function of a browser web page, etc.; wherein, the computer device can be used as the management end 100 or the application end 200 in the above-mentioned data processing system. Exemplarily, the computer device includes a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program to enable the computer device to execute the permission data processing method of the present application.

[0127] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or at least one of other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., which can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application.

[0128] The memory may be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), etc. The memory is used to store a computer program, and the processor may execute the computer program accordingly after receiving an execution instruction.

[0129] In addition, the present application also provides a computer storage medium for storing the computer program used in the above-mentioned computer device, wherein when the computer program is executed on a processor, the permission data processing method of the above-mentioned embodiment is implemented.

[0130] It can be understood that the options in the permission data processing method of the above embodiment are also applicable to this embodiment, so they will not be described repeatedly here.

[0131] The computer storage medium may be a non-volatile storage medium or a volatile storage medium. For example, the computer storage medium may include, but is not limited to, a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0132] In several embodiments provided in the present application, it should be understood that the disclosed system and method can also be implemented in other ways. The system embodiments described above are merely schematic. For example, the flowcharts and structure diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to 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 part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the box can also occur in a different order from the order 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 structure diagram and / or the flow diagram, and the combination of boxes in the structure diagram and / or the flow diagram, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0133] In addition, in each embodiment of the present application, each step performed by the management end 100 and the application end 200 can be implemented through one or more functional modules or units, that is, a number of functional modules or units can be respectively set inside the management end 100 and the application end 200 to execute each step in the above embodiments, thereby realizing the corresponding functions; and, the functional modules or units inside the management end 100 and the application end 200 can be integrated together to form an independent part, or each module can exist separately, or two or more modules can be integrated to form an independent part.

[0134] 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, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0135] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A method for processing authority data, characterized in that: Applied to the management side, including: Release a software development kit so that the application end integrates the software development kit to communicate with the management end, and runs the permission control logic in the software development kit to intercept user operation requests through corresponding interfaces and perform permission verification on the user operation requests; Maintaining the interface information and user data of each interface in real time, generating and configuring corresponding permission association paths and permission control logic according to the interface information and user data, so that the application end performs interface permission verification on the user operation request according to the permission association path; and, sending the user data to the application end, so that the application end performs data permission verification on the user operation request according to the user data through a corresponding interface; The interface is an internal interface of the application end or an interface supported by the application end; the permission association path containing interface information represents the association relationship related to each interface and used for interface permission verification; the permission association path containing user data indicates the association relationship related to each user and used for data permission verification; If the interface information or user data used for permission verification needs to be changed, a sub-path in the maintained relevant permission association path is updated.

2. A method for processing authority data, characterized in that: Applied to an application end, the application end includes a plurality of interfaces and a logic controller, each of the interfaces is connected to the logic controller, and the method includes: Integrate the software development kit released by the management end to communicate with the management end; wherein the software development kit includes the permission control logic configured by the management end; Run the permission control logic, intercept the user operation request at the corresponding interface, and perform permission verification on the user operation request; the permission verification includes one or both of interface permission verification and data permission verification; wherein, based on the permission association path generated and configured by the management end according to the interface information and user data, perform interface permission verification and / or data permission verification on the user operation request; the permission association path containing the interface information represents the association relationship related to each interface and used for interface permission verification; the permission association path containing the user data indicates the association relationship related to each user and used for data permission verification; and, when the interface information or the user data is changed, performing permission verification on the permission association path after the management terminal updates a sub-path in the maintained relevant permission association path; The user operation request is used to allow access to the logic controller after it is determined that the permission check has passed.

3. The permission data processing method according to claim 2, characterized in that: If the permission check is an interface permission check, performing permission check on the user operation request includes: The permission association path of the current interface and the user information used to initiate the user operation request are obtained, and the user information is subjected to permission verification according to the permission association path.

4. The method for processing authority data according to claim 3, characterized in that: The performing permission verification on the user information according to the permission association path includes: Determine whether there is a first authority path including the user information in the authority association path, and whether there is a second authority path including the current interface information; If the first permission path and the second permission path exist, determining whether the first permission path and the second permission path can be spliced ​​into a complete permission association path; If yes, then determine that the interface permission check passes; If not, it is determined that the interface permission check fails.

5. The method for processing authority data according to claim 3, characterized in that: The path for obtaining the permission association of the current interface includes: Requesting the management end for first local associated path data, and obtaining internally stored second local associated path data; wherein the first local associated path data and the second local associated path data do not overlap; A complete permission association path of the current interface is obtained according to the first local association path data and the second local association path data.

6. The method for processing authority data according to any one of claims 2 to 5, characterized in that: If the permission check is a data permission check, performing permission check on the user operation request includes: Obtaining permission annotation information and user data on the logic controller corresponding to the user operation request; According to the permission annotation information, verification data for performing data permission verification is obtained from the user operation request; wherein the permission annotation information is used to indicate the data type and field information for which data permission verification needs to be performed; Determining whether the user data is consistent with the verification data; If they are consistent, it is determined that the data permission check has passed; If they are inconsistent, it is determined that the data permission check fails.

7. The method for processing authority data according to claim 6, characterized in that: Also includes: If the verification data cannot be obtained from the user operation request, the user operation request is forwarded to the logic controller, so that the logic controller obtains the target user data from the management end and performs permission verification on the user operation request according to the target user data.

8. A rights data processing system, characterized in that: include: A management terminal, used to execute the permission data processing method according to claim 1; The application end is used to execute the permission data processing method described in any one of claims 2-7.

9. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor is used to execute the computer program to implement the authority data processing method according to any one of claims 1 to 7.

10. A computer storage medium, characterized in that: The computer program stores a computer program, which, when executed on a processor, implements the method for processing rights data according to any one of claims 1 to 7.

Images