Data permission management method, gateway, back end and related equipment

Abstract

The invention discloses a data permission management method, a gateway, a back end and related equipment, and belongs to the technical field of servers, and the method comprises the steps: when a target request of a front end is received, determining a data permission identifier corresponding to the target request, and obtaining a target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users; adding the target permission identifier to a request header of the target request; and sending the target request to the back end, so that the back end feeds back the target data to the front end according to the target permission identifier in the request header. According to the method, relatively high development cost and maintenance cost are not needed, and when the back end responds to the target request, the role information corresponding to the target request does not need to be searched from the gateway, and the target request can be directly responded according to the data permission identifier in the target request header, so that the user experience is improved. Therefore, the data processing performance of the rear end can be obviously improved.

Description

Technical Field

[0001] The present invention relates to the technical field of servers, and in particular to a data authority management method, a gateway, a back end, a data communication system, a program product and a medium. Background Art

[0002] With the advent of the information age, data has become one of the most important assets of enterprises. In the existing technology, there are mainly two methods to manage data permissions: one is to bind data permissions with users, and the other is to bind data permissions with user roles.

[0003] When data permissions are bound to users, users can only access the data they are bound to. Although this method can provide users with very detailed permission control and reduce the risk of data leakage, as the number of users and data increases, the binding relationship between users and data permissions will become extremely complex, which will not only increase the development and maintenance costs of the system, but also affect the performance of the system.

[0004] When data permissions are bound to user roles, it is not necessary to set corresponding data permissions for each user. Instead, you only need to set corresponding data permissions based on the user's role, which simplifies data permission management. However, as the system organization expands, many roles will appear in the system, and a user may be assigned multiple roles. This will not only make role definition and maintenance very difficult, but also increase the complexity of data management and even cause serious security risks. In addition, in the architecture of front-end and back-end separation, the user's role is not managed by the back-end, but by the gateway. This means that when the back-end processes the request corresponding to the user, it has to query the gateway for the role information corresponding to the user, which will seriously affect the data processing performance of the back-end.

[0005] It can be seen that how to better manage data permissions while taking into account development costs, maintenance costs and back-end data processing performance is a technical problem that needs to be urgently solved by technical personnel in this field. Summary of the invention

[0006] In view of this, the purpose of the present invention is to provide a data permission management method, gateway, backend and related equipment to solve the technical problems of high development cost, high maintenance cost and poor backend processing performance in the prior art when managing data permissions. The specific scheme is as follows:

[0007] In order to solve the above technical problems, the present invention provides a data authority management method, which is applied to a gateway and includes:

[0008] When receiving a target request from the front end, the data permission identifier corresponding to the target request is determined to obtain a target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users;

[0009] Adding the target permission identifier to the request header of the target request;

[0010] The target request is sent to the backend, so that the backend feeds back target data to the frontend according to the target authority identifier in the request header.

[0011] Preferably, adding the target permission identifier to the request header of the target request includes:

[0012] The target permission identifier is added to the request header of the target request using Enum.

[0013] Preferably, adding the target permission identifier to the request header of the target request includes:

[0014] The target authority identifier is added to the request header of the target request using SQL.

[0015] Preferably, a placeholder is provided in the target permission identifier.

[0016] Preferably, the format of the placeholder is JSON.

[0017] In order to solve the above technical problems, the present invention also provides a data permission management method, which is applied to the back end and includes:

[0018] When receiving a target request sent by the front end through the gateway, the data permission identifier is obtained from the request header of the target request to obtain the target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users;

[0019] The target data is fed back to the front end through the gateway according to the target authority identifier.

[0020] Preferably, feeding back target data to the front end through the gateway according to the target authority identifier includes:

[0021] If the target permission identifier is written by SQL, then determining the business SQL corresponding to the target request to obtain the target business SQL;

[0022] The target business SQL and the target authority identifier are spliced ​​to obtain a target splicing identifier, and the target data is fed back to the front end through the gateway according to the target splicing identifier.

[0023] In order to solve the above technical problems, the present invention further provides a gateway, comprising:

[0024] The identification acquisition module is used to determine the data permission identification corresponding to the target request when receiving the target request from the front end, and obtain the target permission identification; wherein different data permission identifications correspond to data access rights requested by different users;

[0025] An identification adding module, used for adding the target permission identification to the request header of the target request;

[0026] The request sending module is used to send the target request to the back end, so that the back end can feed back the target data to the front end according to the target authority identifier in the request header.

[0027] In order to solve the above technical problems, the present invention further provides a backend, comprising:

[0028] The request receiving module is used to obtain the data permission identifier from the request header of the target request when receiving the target request sent by the front end through the gateway, and obtain the target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users;

[0029] A data feedback module is used to feed back target data to the front end through the gateway according to the target authority identifier.

[0030] In order to solve the above technical problem, the present invention further provides a data communication system, including a gateway as disclosed above and a backend as disclosed above.

[0031] Beneficial effects: Because developers can pre-bind data permission identifiers with data access permissions requested by users, different data permission identifiers can correspond to data access permissions requested by different users. In this case, when the gateway receives the target request from the front end, it can determine the data permission identifier corresponding to the target request and obtain the target permission identifier; then, add the target permission identifier to the request header of the target request and send the target request to the back end. When the back end receives the target request, because the request header of the target request contains the target permission identifier, the back end can directly find the data with the corresponding access permissions through the target permission identifier. When the back end finds the data with the access permissions corresponding to the target permission identifier, it can directly feed back the data to the front end through the gateway.

[0032] Compared with the existing technology, developers can achieve effective management of data permissions by binding the data permission identifier with the data access permission requested by the user, and adding the data permission identifier of the user request to the request header of the user request through the gateway. The design logic of the data permission management method is simple and easy to implement, and does not require high development and maintenance costs. Moreover, when the backend responds to the target request, it does not need to find the role information corresponding to the target request from the gateway, but directly responds to the target request according to the data permission identifier in the target request header, thereby significantly improving the data processing performance of the backend.

[0033] Correspondingly, another data permission management method, a gateway, a backend, a data communication system, a program product and a medium provided by the present invention also have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0035] Figure 1 A flowchart of a data authority management method provided by an embodiment of the present invention;

[0036] Figure 2 A schematic diagram showing the principle of data interaction between the front-end and back-end separation architecture and the gateway;

[0037] Figure 3 This is a schematic diagram of the principle of the gateway verifying the request sent by the front end;

[0038] Figure 4 A schematic diagram of the principle of a data authority management method provided by an embodiment of the present invention;

[0039] Figure 5 A flowchart of another data authority management method provided by an embodiment of the present invention;

[0040] Figure 6 A structural diagram of a gateway provided by an embodiment of the present invention;

[0041] Figure 7 A structural diagram of a backend provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0043] See also Figure 1 , Figure 1 A flowchart of a data authority management method provided by an embodiment of the present invention, the method comprising:

[0044] Step S11: when receiving the target request from the front end, determining the data permission identifier corresponding to the target request, and obtaining the target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users;

[0045] Step S12: Add the target permission identifier to the request header of the target request;

[0046] Step S13: Send the target request to the backend, so that the backend feeds back the target data to the frontend according to the target authority identifier in the request header.

[0047] In this embodiment, a data authority management method is provided, which can solve the technical problems of high development cost, high maintenance cost and poor backend processing performance in the prior art when managing data authority. The method is specifically described with the gateway as the execution subject.

[0048] In order to enable those skilled in the art to better understand the implementation principle of the present application, the front-end and back-end separation architecture is first briefly described. In the traditional website development architecture, the front-end (user interface) and the back-end (server-side logic and database) are set as an integrated structure. Under this setting architecture, the front-end and the back-end are closely integrated, and the rendering of the front-end page and the processing logic of the back-end are intertwined. In small projects, setting the front-end and the back-end as one can not only simplify the development process, but also make it easier for people to better understand the context code. However, in large projects, if the front-end and the back-end are set as one, it may make the code difficult to maintain and expand. In order to avoid this problem, it is now common to set the website development architecture to an architecture with a separation of the front-end and the back-end.

[0049] Front-end and back-end separation is to develop and deploy the front-end and back-end separately. The front-end is usually built using technologies such as HTML (HyperText Markup Language), CSS (Cascading Style Sheets), and JavaScript (a high-level, interpreted programming language), while the back-end usually uses technologies such as Node.js (an open source, cross-platform JavaScript runtime environment), Java (a programming language), Golang (The Go Programming Language), and Python (a programming language) to process data and business logic. The front-end and back-end generally communicate through an API (Application Programming Interface). The architecture with front-end and back-end separation has the following advantages:

[0050] First, independent development of the front-end and back-end can improve the development efficiency of developers and reduce the time that front-end developers and back-end developers rely on each other and wait. Front-end developers can focus more on optimizing the interface and user experience, and back-end developers can focus more on the implementation of business logic and data processing. In addition, front-end developers and back-end developers can work in parallel, reducing the coordination and communication costs of front-end developers and back-end developers, thereby further improving the work efficiency of developers.

[0051] Second, the technology selection is flexible, and different technology stacks can be used for the front-end and back-end. For example, the front-end can choose modern front-end frameworks such as React (a JavaScript library for building user interfaces), Vue.js (a progressive JavaScript framework for building user interfaces), Anguar (an open source Web application framework), etc., while the back-end can use frameworks such as Node.js, Django (a Python Web framework), Spring (Spring Framework, an open source Java platform), etc. This flexible selection allows the front-end and back-end development teams to choose the tools and technologies that are most suitable for development tasks.

[0052] Third, improve code reusability. After the front-end code and the back-end code are separated, it will not only make the system easier to maintain, but also facilitate code reuse. For example, the front-end can develop a component library and use it for multiple projects, and the back-end can provide a general API service for the front-end to call.

[0053] Fourth, the separation of the front-end and the back-end makes the deployment and release of the front-end and the back-end more convenient. Moreover, under this setting, it can reduce the situation where the entire system needs to be redeployed due to changes in one party's code, which can improve the stability and maintainability of the system.

[0054] Fifth, the front end can handle user interaction and interface update issues more flexibly, so that users can have a smoother and faster web browsing speed. At the same time, when using AJAX (Asynchronous JavaScript and XML) and SPA (Single Page Application) technology, users can also update web page content without refreshing the entire page, which can not only reduce the server load and save bandwidth, but also further improve the user experience.

[0055] In the architecture with separation of front-end and back-end, the back-end logic can be divided into different microservices according to business and functions. However, for the sake of ease of use, it is impossible for the front-end to call each microservice one by one. Therefore, gateway applications are born.

[0056] See also Figure 2 , Figure 2 This is a schematic diagram of the principle of data interaction between the front-end and back-end separation architecture and the gateway. The gateway is the unified entrance for all microservices on the back end. Through the gateway, you can also uniformly record the request logs sent by the front end and perform unified permission management on data requests. The gateway can implement functions such as menu permission management, function permission management, data permission management, routing service management, monitoring alarm management, and log collection management. In this architecture, the gateway is equivalent to an independent reverse proxy service. Through the API path, Header (the header area of ​​the web page or document), Cookie (data fragment), weight and other information, the front-end request can be routed to different microservices on the back end. The front end only needs to connect to the gateway service. After the back end has developed the microservice, it only needs to register the microservice to the gateway.

[0057] Among them, menu permissions refer to the user's access rights to the system menu, and menu permissions can control which menu items the user sees. Menu permissions are usually set in the front-end interface. Menu permissions can determine which function entrances the user can access in the system. For example, user A can only see the "Report" menu but not the "Settings" menu. Functional permissions refer to the user's access rights to system functions. Functional permissions can control which function modules the user uses or operates. For example, user A has the permission to use the "Add User" function, but does not have the permission to use the "Delete User" function. Functional permissions are usually associated with the user's role and responsibilities. Data permissions refer to the user's access and operation rights to data. Data permissions can control which data the user can view, edit, and delete. Data permissions are usually subdivided based on the user's role, department, or other attributes. For example, user A can only view the data of his own department, but cannot access the data of other departments.

[0058] In actual applications, the gateway generally implements menu permission management, function permission management, and data permission management through role assignment. For example, the gateway will assign menu permissions, function permissions, and data permissions to administrators and ordinary users respectively, and then assign different roles to different users. After that, the gateway will determine whether the user has access to a certain menu / function / data based on the request sent by the front-end user. If the request passes the gateway's verification, the gateway will feed back the corresponding data to the front-end. If the request fails the gateway's verification, the gateway will feed back an error message to the front-end. See Figure 3 , Figure 3 This is a schematic diagram of the principle of the gateway verifying the request sent by the front end.

[0059] In this embodiment, developers can pre-bind data permission identifiers with data access permissions requested by users, so that different data permission identifiers can correspond to data access permissions requested by different users. In the front-end and back-end separation architecture, because all user requests sent from the front-end to the back-end will pass through the gateway, the gateway can also know the permission information corresponding to the request sent by the user, such as: user role, request type, access data, etc.

[0060] When the gateway receives the target request from the front end, it first determines the data permission identifier corresponding to the target request, obtains the target permission identifier, and adds the target permission identifier to the request header of the target request; then, the gateway sends the target request to the back end. When the back end receives the target request sent by the gateway, it directly extracts the target permission identifier from the request header of the target request. Because the target permission identifier corresponds to the data access permission requested by a specific user, the back end can directly feedback the desired data, that is, the target data, to the front end through the gateway based on the target permission identifier.

[0061] It should be noted that in actual applications, for user requests with configured data permissions, the gateway will add the data permission identifier of the request to the request header and send it to the backend so that the backend can make corresponding business processing for the user request. If a user request is not assigned any data permissions, the gateway will not process the request even if it receives it.

[0062] Compared with the existing technology, developers can achieve effective management of data permissions by binding the data permission identifier with the data access permission requested by the user, and adding the data permission identifier of the user request to the request header of the request through the gateway. The design logic of the data permission management method is simple and easy to implement, and does not require high development and maintenance costs. Moreover, when the backend responds to the target request, it does not need to search the gateway for the role information corresponding to the target request, but directly responds to the target request according to the data permission identifier in the target request header, thereby significantly improving the data processing performance of the backend.

[0063] Based on the above embodiment, this embodiment further illustrates and optimizes the technical solution. As a preferred implementation method, the above step of adding the target permission identifier to the request header of the target request includes:

[0064] Use Enum to add the target permission identifier to the request header of the target request.

[0065] In this embodiment, developers can use Enum to bind data permission identifiers with data access permissions requested by users in advance. If the publicly defined Enum does not meet user requirements, developers can also add custom Enums for data resources. See Table 1, which is an example of using Enum to bind data permission identifiers with data access permissions requested by users.

[0066] Data permission identification Description of data access permissions ALL All data PROJECT You can only view the projects you belong to USER You can only see data related to yourself NONE Can't see any data …… Customized data

[0067] Here is an example to explain in detail. If the user wants to query the controller list interface in the system: / getMgcList, the developer can add the three Enum data permission identifiers ALL, PROJECT, and USER to this data resource in advance. These three data permission identifiers respectively indicate that the user can view all controller lists, view the controller list of the project he is in, and view the controller list he is responsible for; then, the developer can set the data permission identifiers ALL, PROJECT, and USER for user A, user B, and user C respectively.

[0068] Correspondingly, when the gateway receives a request from a front-end user to call / getMgcList, if the request is sent by user A, the gateway will add the data permission identifier: ALL to the request header data_auth_enum when proxying the request; if the request is sent by user B, the gateway will add the data permission identifier: PROJECT to the request header data_auth_enum when proxying the request; if the request is sent by user C, the gateway will add the data permission identifier: USER to the request header data_auth_enum when proxying the request. After that, the gateway will forward the request with the data permission identifier added to the request header to the backend, so that the backend can make a corresponding business response to the request sent by the frontend.

[0069] Since Enum provides a clear way to express variables, the code is easier to understand and maintain, and Enum type data permission identifiers are easier to identify in computers than names such as numbers and strings. Therefore, the technical solution provided in this embodiment can further improve the usability of the data permission management method provided in this application in practical applications.

[0070] Based on the above embodiment, this embodiment further illustrates and optimizes the technical solution. As a preferred implementation method, the above step of adding the target permission identifier to the request header of the target request includes:

[0071] Use SQL to add the target permission identifier to the request header of the target request.

[0072] Because SQL (Structured Query Language) is a standardized programming language used to manage and operate relational databases, it not only has the advantages of simple and intuitive syntax, but also allows users to customize the compilation content. Therefore, developers can also use SQL to bind data permission identifiers with data access permissions requested by users in advance. Correspondingly, the gateway can use SQL to add the target permission identifier to the request header of the target request.

[0073] Specifically, when the gateway receives the target request from the front end, it needs to determine the target authority identifier corresponding to the target request and add the target authority identifier to the request header data_auth_sql of the target request. Then, the gateway forwards the target request with the target authority identifier added in the request header data_auth_sql to the back end, so that the back end responds to the target request.

[0074] In addition, since SQL is a standard database language, the basic SQL syntax is the same in many database systems, so when developers use SQL to bind data permission identifiers with data access permissions requested by users, it can reduce the difficulty of developers' work. Moreover, compared with Enum, SQL can handle larger and more complex system environments.

[0075] In addition, it should be noted that in actual applications, developers can use Enum to bind data permission identifiers and data access permissions requested by users, use SQL to bind data permission identifiers and data access permissions requested by users, or use Enum and SQL at the same time to bind data permission identifiers and data access permissions requested by users.

[0076] As a preferred implementation, a placeholder is provided in the target permission identifier.

[0077] Specifically, you can set a placeholder in the target permission identifier. Because in database queries, placeholders can be used to replace actual parameter values, and these parameter values ​​will only be bound to the query when it is executed, which helps prevent SQL injection attacks. In addition, placeholders also allow developers to write reusable code templates, which can further reduce the difficulty of developers' work.

[0078] In actual applications, the placeholder can be set to any format, or the format of the placeholder can be set according to the actual needs of the gateway. As a preferred implementation, the format of the placeholder can be set to JSON (JavaScript Object Notation, a lightweight data exchange format). Because JSON is a plain text data exchange format, it can not only be used across platforms, but also the text in this format is easy to store and transmit, which can relatively improve the data exchange speed between the front end, gateway and back end.

[0079] See also Figure 4 , Figure 4 A schematic diagram of the principle of a data rights management method provided by an embodiment of the present invention. Figure 4In , developers can use Enum or SQL to bind data permission identifiers to data resources in advance, so that different data access identifiers can correspond to data access permissions requested by different users. After that, users can send requests to the backend through the gateway to access the data in the backend. In this process, when the gateway receives the request sent by the user, it will determine the data permission identifier corresponding to the request and add the data permission identifier to the request header of the request. When the gateway has added the data permission identifier to the request header, it will send the request to the backend so that the backend can respond to the user's request.

[0080] See also Figure 5 , Figure 5 A flowchart of a data authority management method provided by an embodiment of the present invention, the method comprising:

[0081] Step S21: when receiving a target request sent by the front end through the gateway, obtaining a data permission identifier from the request header of the target request to obtain a target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users;

[0082] Step S22: Feedback target data to the front end through the gateway according to the target authority identifier.

[0083] In this embodiment, a data permission management method is provided, which is specifically described with the backend as the execution subject. The relevant description of the method can refer to the technical content disclosed in the aforementioned data permission management method, and will not be described in detail here.

[0084] Based on the above embodiment, this embodiment further illustrates and optimizes the technical solution. As a preferred implementation mode, the above step of feeding back target data to the front end through the gateway according to the target authority identifier includes:

[0085] If the target permission identifier is written by SQL, then the business SQL corresponding to the target request is determined to obtain the target business SQL;

[0086] The target business SQL and the target permission identifier are spliced ​​to obtain the target splicing identifier, and the target data is fed back to the front end through the gateway according to the target splicing identifier.

[0087] Since data permission SQL is a developer-defined SQL language, you can combine your own business SQL and data permission SQL to splice the final SQL, and thus get the target splicing identifier. Here is a specific example to illustrate. See Table 2, which is an example of using SQL to bind the data permission identifier with the data access permission requested by the user.

[0088] Data permission identification Description of data access permissions 1=1 All data projectId in (${projectIds}) You can only view projects you belong to userId=${userId} You can only see data related to yourself 1=2 Can't see any data …… Customized data

[0089] It should be noted that projectId in (${projectIds}) and userId=${userId} in SQL are placeholders defined by the gateway. During the data interaction between the front-end and back-end, projectId in (${projectIds}) and userId=${userId} will be replaced with actual values. For example: projectIds=1, 2, 3, or userId=5. In actual applications, which placeholders need to be used and what format the placeholders need to be set to can be set according to the actual needs of the gateway.

[0090] Here is an example to explain in detail. If the user wants to query the controller list interface in the system: / getMgcList, the developer can pre-add three types of SQL data permission identifiers for this data resource: 1=1, projectIds=1, 2, 3, and userId=5. These three data permission identifiers respectively indicate that the user can view all controller lists, view the controller list of the project to which he belongs, and view the controller list for which he is responsible; after that, the developer can set the data permission identifiers 1=1, projectIds=1, 2, 3, and userId=5 for user A, user B, and user C respectively.

[0091] Assuming that the business SQL corresponding to the target request is: select * from t_mgc, when the backend receives the target request sent by the gateway, it will obtain the data permission identifier from the request header data_auth_sql of the target request, obtain the target permission identifier, and concatenate select * from t_mgc with the target permission identifier to obtain the final SQL.

[0092] If the target request is sent by user A, the final SQL is: select * from t_mgc where 1=1; if the target request is sent by user B, the final SQL is: select * from t_mgc where projectId in (1,2,3); if the target request is sent by user C, the final SQL is: select * from t_mgc where userId=5. When the gateway completes the splicing of the data permission identifiers, it can search for the data with the access rights corresponding to the permission identifier based on the spliced ​​data permission identifiers, thereby obtaining the target data, and feeding the target data back to the front end through the gateway to respond to the target request.

[0093] When using SQL for database operations, you can not only use digital indexes to perform fast data search operations, but also make error handling and data maintenance easier, which can further improve the data processing performance of the backend.

[0094] See also Figure 6 , Figure 6 A structural diagram of a gateway provided by an embodiment of the present invention, the gateway includes:

[0095] The identification acquisition module 11 is used to determine the data permission identification corresponding to the target request when receiving the target request from the front end, and obtain the target permission identification; wherein different data permission identifications correspond to data access rights requested by different users;

[0096] An identification adding module 12, used for adding a target permission identification to a request header of a target request;

[0097] The request sending module 13 is used to send the target request to the back end, so that the back end feeds back the target data to the front end according to the target authority identifier in the request header.

[0098] Preferably, the identification adding module 12 includes:

[0099] The first adding unit is used to add the target permission identifier to the request header of the target request by using Enum.

[0100] Preferably, the identification adding module 12 includes:

[0101] The second adding unit is used to add the target authority identifier to the request header of the target request by using SQL.

[0102] A gateway provided by an embodiment of the present invention has the beneficial effects of the aforementioned data authority management method disclosed above.

[0103] See also Figure 7 , Figure 7 A structural diagram of a backend provided by an embodiment of the present invention, the backend includes:

[0104] The request receiving module 21 is used to obtain the data permission identifier from the request header of the target request when receiving the target request sent by the front end through the gateway, and obtain the target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users;

[0105] The data feedback module 22 is used to feed back target data to the front end through the gateway according to the target authority identifier.

[0106] Preferably, the data feedback module 22 includes:

[0107] An identification determination unit, configured to determine the business SQL corresponding to the target request if the target permission identification is written in SQL, and obtain the target business SQL;

[0108] The identification splicing unit is used to splice the target business SQL and the target authority identification to obtain a target splicing identification, and feed back the target data to the front end through the gateway according to the target splicing identification.

[0109] A backend provided by an embodiment of the present invention has the beneficial effects of the aforementioned data authority management method disclosed above.

[0110] Correspondingly, an embodiment of the present invention further provides a data communication system, comprising a gateway as disclosed above and a backend as disclosed above.

[0111] A data communication system provided by an embodiment of the present invention has the beneficial effects of the aforementioned gateway and the aforementioned backend.

[0112] Correspondingly, an embodiment of the present invention further provides a computer program product, which, when executed by a processor, implements the steps of a data permission management method as disclosed above.

[0113] It should be noted that, in this embodiment, a data permission management method implemented by a computer program product can be a data permission management method executed by a gateway or a data permission management method executed by a backend.

[0114] A computer program product provided by an embodiment of the present invention has the beneficial effects of the aforementioned data permission management method disclosed above.

[0115] Correspondingly, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of a data permission management method disclosed above are implemented.

[0116] It should be noted that, in this embodiment, a data permission management method implemented by a computer-readable storage medium can be a data permission management method executed by a gateway or a data permission management method executed by a backend.

[0117] A computer-readable storage medium provided by an embodiment of the present invention has the beneficial effects of the aforementioned data permission management method disclosed above.

[0118] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

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

[0120] The above is a detailed introduction to a data permission management method, gateway, backend, data communication system, program product and medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A data authority management method, characterized in that: Applied to gateways, including: When receiving a target request from the front end, the data permission identifier corresponding to the target request is determined to obtain a target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users; Adding the target permission identifier to the request header of the target request; The target request is sent to the backend, so that the backend feeds back target data to the frontend according to the target authority identifier in the request header.

2. A data authority management method according to claim 1, characterized in that: Adding the target permission identifier to the request header of the target request includes: The target permission identifier is added to the request header of the target request using Enum.

3. A data authority management method according to claim 1, characterized in that: Adding the target permission identifier to the request header of the target request includes: The target authority identifier is added to the request header of the target request using SQL.

4. A data authority management method according to claim 3, characterized in that: A placeholder is set in the target permission identifier.

5. A data authority management method according to claim 4, characterized in that: The format of the placeholder is JSON.

6. A data authority management method, characterized in that: Applied to the backend, including: When receiving a target request sent by the front end through the gateway, the data permission identifier is obtained from the request header of the target request to obtain the target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users; The target data is fed back to the front end through the gateway according to the target authority identifier.

7. A data authority management method according to claim 6, characterized in that: Feeding back target data to the front end through the gateway according to the target authority identifier includes: If the target permission identifier is written by SQL, then determining the business SQL corresponding to the target request to obtain the target business SQL; The target business SQL and the target authority identifier are spliced ​​to obtain a target splicing identifier, and the target data is fed back to the front end through the gateway according to the target splicing identifier.

8. A gateway, characterized in that: include: The identification acquisition module is used to determine the data permission identification corresponding to the target request when receiving the target request from the front end, and obtain the target permission identification; wherein different data permission identifications correspond to data access rights requested by different users; An identification adding module, used for adding the target permission identification to the request header of the target request; The request sending module is used to send the target request to the back end, so that the back end can feed back the target data to the front end according to the target authority identifier in the request header.

9. A back end, characterized in that: include: The request receiving module is used to obtain the data permission identifier from the request header of the target request when receiving the target request sent by the front end through the gateway, and obtain the target permission identifier; wherein different data permission identifiers correspond to data access permissions requested by different users; A data feedback module is used to feed back target data to the front end through the gateway according to the target authority identifier.

10. A data communication system, characterized in that: It comprises a gateway as claimed in claim 8 and a backend as claimed in claim 9.

Images