A rights management apparatus, system and method

Abstract

The application discloses a kind of authority management device, system and method, main purpose is to realize the decoupling of authority management and the business logic of front end and back end;Authority management device includes: configuration module, for the front end configuration authority management information, authority management information includes the user information of user involved in front end and the authority information corresponding to each user information, and authority information is used to associate the accessible authority data of corresponding user in back end;Processing module is used to obtain the request of access target authority data sent by front end, and based on the authority management information, determine that the user who initiates the request has the authority of access target authority data, under the condition, request is sent to the back end;When receiving the target authority data of request feedback by back end, target authority data is processed based on the data type of target authority data, and the target authority data after processing is provided to front end, for front end to show.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a rights management device, system, and method. Background Art

[0002] In the interaction between the front-end and the back-end, it is necessary to manage the permissions of the front-end users so that users can access and only access the data in the back-end that they are authorized to access through the front-end.

[0003] Currently, existing permission management approaches typically fall into two categories: one is to deploy a customized permission management system on the backend, which then manages permissions for the frontend through this system. This permission management approach is highly coupled to the backend's business logic, resulting in delayed response times for permission management, allowing the frontend to directly access the backend's underlying protection mechanisms. The other approach is to deploy a customized permission management system on the frontend, which then accesses backend data through this system. While this approach decouples permission management from the backend's business logic, it requires the frontend to add some permission storage and permission determination logic unrelated to its business operations, making permission management highly coupled to the frontend's business logic. Therefore, existing permission management approaches are highly coupled to both the frontend and backend businesses. Summary of the Invention

[0004] In view of this, the present application proposes a rights management device, system and method, the main purpose of which is to achieve the decoupling of rights management from the business logic of the front-end and back-end.

[0005] In order to achieve the above objectives, this application mainly provides the following technical solutions:

[0006] In a first aspect, the present application provides a rights management device, the rights management device comprising:

[0007] A configuration module, configured to configure permission management information for the front-end, wherein the permission management information includes user information of users involved in the front-end and permission information corresponding to each user information, and the permission information is used to associate the permission data that the corresponding user can access in the back-end;

[0008] a processing module for, upon obtaining a request for accessing target permission data sent by the front end and determining, based on the permission management information, that the user initiating the request has the permission to access the target permission data, sending the request to the back end; upon receiving the target permission data for the request fed back by the back end, processing the target permission data based on the data type of the target permission data, and providing the processed target permission data to the front end for display by the front end.

[0009] In some embodiments, the processing module includes: a first processing unit, used to convert the target permission data when it is determined that the data type of the target permission data is menu data, wherein the converted target permission data meets the menu data display requirements of the front end.

[0010] In some embodiments, the first processing unit is further used to call the target data processing logic corresponding to the menu data display requirements through the first target interface to process the target permission data when the preset data processing logic cannot convert the target permission data into permission data that meets the menu data display requirements, or to provide a second target interface for the user to write custom data processing logic corresponding to the menu data display requirements.

[0011] In some embodiments, the processing module includes: a second processing unit, which is used to store and process the target permission data when it is determined that the data type of the target permission data is button permission data or user data, so that when the front end retrieves the target permission data, the stored target permission data is provided to the front end for display; wherein, the button permission data only includes button information corresponding to the user-executable operation, and the user data only includes user information that the user can view.

[0012] In some embodiments, the processing module also includes: a storage unit, which is used to store the target permission data in a first storage method or a second storage method when receiving the target permission data for the request fed back by the back end; wherein, the target permission data stored in the first storage method is cleared when the page corresponding to the request in the front end is closed; the target permission data stored in the second storage method is cleared under a deletion instruction.

[0013] In some embodiments, the processing module also includes: a first judgment unit, which is used to determine whether the target permission data corresponding to the request is stored in the storage unit when a request for access to the target permission data sent by the front end is obtained; if so, the target permission data is provided to the front end for display by the front end; if not, based on the permission management information, determine whether the user who initiated the request has the authority to access the target permission data.

[0014] In some embodiments, the processing module also includes: a second judgment unit, which is used to determine whether the permission information corresponding to the target permission data is included in the whitelist set by the configuration module when obtaining the request for access to the target permission data sent by the front end; if included, send the request to the back end; if not, determine whether the user who initiated the request has the permission to access the target permission data based on the permission management information.

[0015] In some embodiments, the configuration module is also used to configure the front end and the back end that has an access relationship with the front end to form configuration information before configuring permission management information for the front end; and establish an interactive relationship between the front end and the back end based on the configuration information.

[0016] In some embodiments, the configuration module is further configured to set an expiration time point for the rights management information, and perform expiration processing on the rights management information at the expiration time point.

[0017] In some embodiments, the processing module is also used to provide a prompt to the front end that the target permission data request failed when the front end obtains a request for accessing the target permission data sent by the front end and determines based on the permission management information that the user who initiated the request does not have the permission to access the target permission data.

[0018] In a second aspect, the present application provides a rights management system, which includes: a front end, a back end, and the rights management device of the first aspect.

[0019] In a third aspect, the present application provides a permission management method, which includes:

[0020] Configure permission management information for the front-end, wherein the permission management information includes user information of users involved in the front-end and permission information corresponding to each user information, and the permission information is used to associate the permission data that the corresponding user can access in the back-end;

[0021] Upon obtaining the request for accessing the target permission data sent by the front end and determining based on the permission management information that the user initiating the request has the permission to access the target permission data, sending the request to the back end;

[0022] When receiving the target permission data for the request fed back by the backend, the target permission data is processed based on the data type of the target permission data, and the processed target permission data is provided to the frontend for display by the frontend.

[0023] In a fourth aspect, the present application provides a computer-readable storage medium, which includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the permission management method of the third aspect.

[0024] By utilizing the above technical solutions, the rights management device, system, and method provided by this application deploy rights management devices for both the front-end and back-end when rights management is required. A request from the front-end to access target rights data in the back-end is first transmitted to the rights management device. The rights management device then sends the request to the back-end only when it determines, based on rights management information configured for the front-end, that the user initiating the request has access to the target rights data. The rights management device then receives the target rights data from the back-end in response to the request, processes the target rights data based on its data type, and provides the processed target rights data to the front-end for display. As can be seen, the rights management device provided by this application exists independently of the front-end and back-end, decoupling rights management from the business logic of the front-end and back-end. Thus, when rights management is required for a front-end and back-end with an access relationship, there is no need to develop a custom rights management system for either the front-end or back-end. Rights management can be performed for both the front-end and back-end with an access relationship through the rights management device, allowing users, through the front-end, to access and only access the data in the back-end that they are authorized to access.

[0025] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0027] Figure 1 A schematic diagram of the structure of a rights management device provided by an embodiment of the present application is shown;

[0028] Figure 2 A schematic structural diagram of a rights management device provided in another embodiment of the present application is shown;

[0029] Figure 3 A schematic diagram of the structure of a rights management system provided by one embodiment of the present application is shown;

[0030] Figure 4 A flowchart of a rights management method provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

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

[0032] Currently, permission management can only be completed by custom-developing a corresponding permission management system for the back-end or front-end. Therefore, the existing permission management method is not only highly coupled with the business logic in the back-end and front-end, but also has a high development cost for customized development.

[0033] After research, the inventors discovered that in order to decouple permission management from the business logic of the front-end and back-end, a permission management device can be designed. This permission management device exists independently of the front-end and back-end, effectively decoupling permission management from the business logic of the front-end and back-end. In this way, when permission management is required for the front-end and back-end that have an access relationship, there is no need to develop a customized permission management system for either front-end or back-end. Permission management can be completed by deploying the permission management device between the front-end and back-end.

[0034] Based on the above considerations, embodiments of the present application provide a rights management device, system, and method. A rights management device is deployed between a front-end and a back-end that have an access relationship, and rights management operations involving the front-end and back-end are performed by the rights management device. Specifically, a front-end requests access to target rights data in the back-end, which is first transmitted to the rights management device. The rights management device sends the request to the back-end only when it determines, based on rights management information configured for the front-end, that the user initiating the request has the right to access the target rights data. The rights management device receives the target rights data in response to the request from the back-end, processes the target rights data based on its data type, and provides the processed target rights data to the front-end for display. As can be seen, due to the high versatility of the rights management device, both the front-end and the back-end that have an access relationship can complete rights management through the rights management device. Therefore, there is no need to develop a customized rights management system for either the front-end or the back-end. Rights management can be completed for both the front-end and the back-end that have an access relationship through the rights management device, allowing users to access, and only access, the data in the back-end that they are authorized to access through the front-end.

[0035] In actual application, the rights management device provided in the embodiment of the present application can be set as a toolkit. When the user needs to perform rights management on the front-end and back-end with an access relationship, the toolkit can be downloaded and the rights management device can be deployed through the toolkit. The rights management for the front-end and back-end can be completed through the deployed rights management device. In principle, any front-end and back-end with an access relationship can complete rights management through the rights management device provided in the embodiment of the present application, thereby reducing the development investment related to rights management in the front-end and back-end, and improving the development efficiency of the projects where the front-end and back-end are located.

[0036] The following is a detailed description of the rights management device, system and method provided in the embodiments of the present application.

[0037] like Figure 1 As shown, an embodiment of the present application provides a rights management device, which mainly includes a configuration module 11 and a processing module 12.

[0038] The configuration module 11 is used to configure permission management information for the front end, wherein the permission management information includes user information of users involved in the front end and permission information corresponding to each user information, and the permission information is used to associate the permission data that the corresponding user can access in the back end.

[0039] The processing module 12 is used to send the request to the back end when it obtains the request for accessing the target permission data sent by the front end and determines based on the permission management information that the user who initiates the request has the permission to access the target permission data; when receiving the target permission data for the request fed back by the back end, the target permission data is processed based on the data type of the target permission data, and the processed target permission data is provided to the front end for display by the front end.

[0040] The following is a detailed description of the specific structure and interaction relationship of each module involved in the rights management device:

[0041] Configuration module 11;

[0042] The rights management device provided in the embodiment of the present application exists independently of the front end and the back end, and any front end and back end with an access relationship can complete the rights management through the rights management device provided in the embodiment of the present application. Therefore, when applying the rights management device, it is first necessary to determine the front end and back end with an access relationship, wherein the user can access the data in the back end through the front end. It should be noted that a front end can have an access relationship with one back end or multiple back ends. The embodiment of the present application does not limit the specific types of the front end and the back end. For example, the front end is a WEB front end, and the back end is a background management system of the WEB front end.

[0043] In order to ensure that users can access and only access the data they are authorized to access in the backend through the frontend, after determining the frontend and the backend, the configuration module 11 of the rights management device needs to configure rights management information for the frontend.

[0044] Permission management information is primarily used to define which data on the backend a user can access. Specifically, permission information includes the user information of the frontend user and the corresponding permission information for each user. This permission information is used to associate the data that the corresponding user can access on the backend.

[0045] User information can be in the following two forms: First, user information uses the user ID corresponding to the user, and the user ID is unique. That is, corresponding permission information is set for each user on the front end to accurately control each user's access to the back-end data. Second, user information uses the role ID corresponding to the user. Users with the same role have the same role ID. This method can reduce the amount of data in the permission management information because users with the same role have the same permission information. For example, user information uses the role ID, and the role ID includes ordinary staff and manager. Then the permission management information includes the permission information corresponding to ordinary staff and the permission information corresponding to managers.

[0046] Permission information is used to associate the permission data that the corresponding user can access in the backend. In other words, it is used to identify the associated permission data. For example, if user A can access permission data "Data A" in the backend, the permission information associated with "Data A" is the identifier "A" of Data A.

[0047] After the configuration module 11 configures the rights management information for the front end, the rights management device has the function of performing rights management on the front end and the back end. It should be noted that a front end can interact with multiple back ends, so the rights management information configured for a front end can involve one or more back ends.

[0048] Furthermore, in order to make the process of configuring permission management information more intuitive and easier for business personnel to configure, the configuration module 11 can display a configuration page when configuring permission management information, so that business personnel can enter user information used to configure permission management information and permission information corresponding to the user information through the configuration page.

[0049] Processing module 12:

[0050] The authority management involved in both the front-end and back-end is completed by the authority management device, and the front-end and back-end no longer perform authority management. Therefore, when the front-end needs to access the data in the back-end, it directly sends the request to access the target authority data to the authority management device, and the authority management device determines whether the user who initiated the request has the authority to access the target authority data. The target authority data here is the authority that the user expects.

[0051] The permission data in the backend that you want to access.

[0052] The processing module 12 in the permission management device is responsible for obtaining the request sent by the front end, and judging whether the user who initiates the request has the permission to access the target permission data based on the permission management information. The specific judgment process of the permission can be: obtaining the user information of the user who initiates the request; when the obtained user information is included in the permission management information, judging whether the permission information corresponding to the obtained user information in the permission management information is the permission information of the associated target permission data; if so, judging that the user who initiates the request has the permission to access the target permission data; if not, judging that the user who initiates the request does not have the permission to access the target permission data.

[0053] If it is determined that the user initiating the request has the permission to access the target permission data, it means that the user can access the target permission data, so the request is forwarded to the backend, so that the backend provides the target permission data based on the request.

[0054] Since the permission management device has performed a permission determination, when the back-end receives a request forwarded by the permission management device, it no longer performs permission-related operations, but directly feeds back the target permission data corresponding to the request to the permission management device, so that the permission management device provides the target permission data to the front-end for display.

[0055] The processing module 12 in the rights management device is responsible for receiving the target rights data for the request from the backend. Considering that the target rights data returned by the backend may not meet the display requirements of the frontend, the processing module 12 needs to process the received target rights data. Because different types of rights data require different processing operations, the processing operation corresponding to the type of the target rights data is selected to process the target rights data.

[0056] The following describes a specific technical solution for processing the target authority data by the processing module 12 based on the data type of the target authority data:

[0057] First, if Figure 2As shown, the processing module 12 includes a first processing unit 121. The first processing unit 121 is configured to convert the target permission data when determining that the data type of the target permission data is menu data, wherein the converted target permission data meets the menu data display requirements of the front end.

[0058] Menu data consists of items and their corresponding content data, making it easy for users to locate and quickly find the data they need. Menu data can be received from the backend via a designated interface in the rights management device. Menu data can be displayed in a variety of formats. To meet user needs, the frontend typically issues menu data display requirements to the rights management device based on user viewing requirements. These menu data display requirements define the menu data display format. Therefore, the target rights data must be converted so that the converted target rights data meets the frontend's menu data display requirements.

[0059] The specific process for converting the target permission data is to extract the data processing logic corresponding to the menu data display requirements from the preset data processing logic, and then use the extracted data processing logic to convert the menu data into a format that meets the menu data display requirements. For example, if the menu data is tiled data, and the front-end menu data display requirement is to "view the menu data in a tree format," the data processing logic that converts tiled data into tree data will be used to process the tiled data into tree data for front-end display.

[0060] Furthermore, in order to improve the business applicability of the permission management device, the first processing unit 121 is also used to call the target data processing logic corresponding to the menu data display requirements through the first target interface to process the target permission data when the preset data processing logic cannot convert the target permission data into a form that meets the menu data display requirements, or provide a second target interface for the user to write custom data processing logic corresponding to the menu data display requirements.

[0061] If none of the preset data processing logics can convert the target permission data into permission data that meets the menu data display requirements, it indicates that none of the preset data processing logics can convert the menu data into a data format that meets the user's display requirements. Therefore, to meet the user's display requirements, any of the following methods can be used: First, the target data processing logic corresponding to the menu data display requirements can be called through a first target interface to process the target permission data. The storage space in the permission management device is limited, and the preset data processing logic provided therein is not comprehensive. Therefore, if it is determined that none of the preset data processing logics can convert the menu data into a data format that meets the user's display requirements, the target data processing logic that meets the menu data display requirements can be called from an external database or network platform through the first target interface to process the target permission data into a format that meets the data display requirements. Second, a second target interface is provided for users to write custom data processing logic corresponding to the menu data display requirements. Considering that users have personalized requirements for menu data display, the data processing logic for processing the target permission data may not be universal. Therefore, a second target interface is provided for users to write custom data processing logic customized to their own menu display requirements. When the first processing unit 121 detects the custom data processing logic, it converts the target permission data using the custom data processing logic so that the converted target permission data meets the menu data display requirement.

[0062] Second, if Figure 2 As shown, the processing module 12 includes a second processing unit 122. The second processing unit 122 is configured to store and process the target permission data when determining that the data type of the target permission data is button permission data or user data, so as to provide the stored target permission data to the front end for display when the front end retrieves the target permission data; wherein, the button permission data only includes button information corresponding to user-executable operations, and the user data only includes user information that the user can view.

[0063] Existing permission management is powerless for permission control at the button level, because the front end generally displays buttons for various operations through the front end. Only after the user triggers the corresponding button will the back end determine whether the user has the permission to perform the operation corresponding to the button. This method adds extra workload to permission management. The permission management device provided in the embodiment of the present application optimizes the management of button-level permissions, and the optimization management is implemented through button permission data. The button permission data carries button information corresponding to user-executable operations, and button information corresponding to non-executable operations is not carried by the button permission data. Based on the button information carried by the button permission data, the front end only displays buttons corresponding to user-executable operations, while buttons corresponding to non-executable operations are not displayed.

[0064] User data describes the user initiating the request. The data it carries is related to the specific business scenario of the front-end. For example, in a financial application, user data may include the following: name, account number, account balance, etc.

[0065] Taking into account that users may use buttons to perform operations or query user information multiple times in the front end, and the timing of operations and queries changes with user needs, in order to facilitate user operations and queries, the target permission data with data types of button permission data and user data are stored and processed, so that when the front end is retrieved, the stored target permission data can be provided to the front end for display.

[0066] The methods for storing and processing target permission data described herein include the following two methods: one is to store the target permission data in a first storage method. The target permission data stored in the first storage method is cleared when the page corresponding to the request in the front end is closed. The first storage method can be session storage. The other is to store the target permission data in a second storage method. The target permission data stored in the second storage method is cleared upon a delete instruction. The second storage method can be local storage.

[0067] After processing the target authority data using the above two methods, the processing module 12 provides the processed target authority data to the front end for display by the front end.

[0068] The rights management device provided in the embodiment of the present application is deployed for the front-end and back-end when rights management is required for the front-end and back-end. The request from the front-end to access the target rights data in the back-end is first transmitted to the rights management device. The rights management device sends the request to the back-end only when it determines, based on the rights management information configured for the front-end, that the user initiating the request has the right to access the target rights data. The rights management device receives the target rights data for the request fed back by the back-end, processes the target rights data based on the data type of the target rights data, and provides the processed target rights data to the front-end for display by the front-end. It can be seen that the rights management device provided in the embodiment of the present application exists independently of the front-end and back-end, and it can achieve the decoupling of rights management from the business logic of the front-end and back-end. In this way, when rights management is required for the front-end and back-end with an access relationship, there is no need to customize and develop a corresponding rights management system for the front-end or back-end. The rights management device can complete the rights management for the front-end and back-end with an access relationship, so that the user can access and only access the data in the back-end that he is authorized to access through the front-end.

[0069] In some embodiments of the present application, the rights management device is a device with rights management function deployed for the front-end and back-end with access relationship, so it is necessary to clarify which front-end and back-end the rights management device is deployed for. Figure 2 As shown, the configuration module 11 is also used to configure the front end and the back end having an access relationship with the front end before configuring the authority management information for the front end to form configuration information; and establish an interactive relationship between the front end and the back end based on the configuration information.

[0070] Configuration information is used to define the access relationship between the front-end and back-end. It includes the following: front-end identification code, front-end domain name, front-end version information, back-end identification code, and back-end domain name. Through this configuration information, the rights management device can establish an interactive relationship with the front-end and back-end. Based on this interactive relationship, it can interact with the front-end and back-end to complete the rights management process.

[0071] Furthermore, in addition to the above-mentioned contents, the configuration information may also include the following contents: storage form, whitelist and expiration time. Among them, the storage form is used to limit the storage form in which the configuration information and the permission management information are stored, and the storage form includes but is not limited to the session Storage form or the local Storage form. The whitelist records the permission information of the target permission data that does not require permission determination, that is, as long as the permission information corresponding to the requested target permission data is included in the whitelist, the request will be directly forwarded to the backend. The expiration time is used to limit the expiration time of at least one of the following contents: configuration information, permission management information and target permission data fed back by the backend. For example, if the expiration time is 24 hours, the configuration information and permission management information will be invalidated 24 hours after configuration. If the configuration information and permission management information need to continue to be used, the configuration process needs to be re-performed.

[0072] Furthermore, in order to make the configuration process of the configuration information more intuitive and more convenient for business personnel to configure, the configuration module 11 can display a configuration page for business personnel to input data for setting the configuration information through the configuration page.

[0073] In some embodiments of the present application, Figure 2 As shown, the configuration module 11 is further used to set an expiration time point for the rights management information and perform expiration processing on the rights management information at the expiration time point.

[0074] The expiration time is determined based on the setting time and expiration duration of the rights management information. The primary purpose of setting the expiration time is to ensure the security of rights management. There are two ways to invalidate rights management information at the expiration time: first, deletion; second, marking the information as invalid so that the marked invalid information can be quickly reactivated when the user decides to enable the information.

[0075] Similarly, for the above configuration information, the configuration module 11 can also set an expiration time point for the configuration information and perform expiration processing on the configuration information at the expiration time point.

[0076] In some embodiments of the present application, Figure 2 As shown, the processing module 12 further includes a storage unit 123. The storage unit 123 is configured to, upon receiving target permission data for a request fed back by the backend, store the target permission data in a first storage mode or a second storage mode; wherein the target permission data stored in the first storage mode is cleared when the page corresponding to the request in the frontend is closed; and the target permission data stored in the second storage mode is cleared upon a delete instruction.

[0077] Considering that the front-end user may need the front-end to display the target permission data multiple times within a period of time, in order to avoid requesting the target permission data from the back-end for each display, the target permission data for the request fed back by the back-end is stored through the storage unit 123.

[0078] The methods for storing and processing target permission data described herein include the following two methods: one is to store the target permission data in a first storage method. The target permission data stored in the first storage method is cleared when the page corresponding to the request in the front end is closed. The first storage method can be session storage. The other is to store the target permission data in a second storage method. The target permission data stored in the second storage method is cleared upon a delete instruction. The second storage method can be local storage.

[0079] In some embodiments of the present application, in order to reduce the workload of the rights management device, the processing module 12 in the rights management device may have the following two structures:

[0080] The first one, such as Figure 2 As shown, the processing module 12 further includes a first determination unit 124. The first determination unit 124 is configured to, upon receiving a request from the front end to access target permission data, determine whether the storage unit 123 stores the target permission data corresponding to the request; if so, provide the target permission data to the front end for display; if not, determine, based on the permission management information, whether the user initiating the request has the permission to access the target permission data.

[0081] Considering that a front-end user may need to display the target permission data multiple times within a period of time, in order to avoid requesting the target permission data from the back-end for each display, the target permission data fed back by the back-end in response to the request is stored in the storage unit 123. It should be noted that when the storage unit 123 stores the data, it needs to store it based on the corresponding relationship between the user, the request, and the target permission data to prevent one user from accessing the target permission data of another user.

[0082] In order to reduce the amount of data processing in the authority management device, when a request for accessing target authority data sent by the front end is obtained, it is necessary to first determine whether the storage unit 123 stores the target authority data corresponding to the request.

[0083] When it is determined that the target permission data corresponding to the request is stored in the storage unit 123, it means that the user has the authority to access the requested target permission data and has accessed the target permission data before. At this time, in order to reduce the processing amount of the permission management device, the target permission data stored in the storage unit 123 is directly provided to the front-end display.

[0084] When it is determined that the target permission data corresponding to the request is not stored in the storage unit 123, it cannot be determined whether the user has the permission to access the target permission data requested. Therefore, the user may not have accessed the target permission data before. At this time, based on the permission management information, it is determined whether the user who initiated the request has the permission to access the target permission data, and corresponding processing is performed according to the judgment result.

[0085] The first one, such as Figure 2 As shown, the processing module 12 further includes a second judgment unit 125. The second judgment unit 125 is configured to, upon receiving a request from the front end to access target permission data, determine whether the permission information corresponding to the target permission data is included in the whitelist set by the configuration module 11; if so, send the request to the back end; if not, determine whether the user initiating the request has permission to access the target permission data based on the permission management information.

[0086] The whitelist records the permission information of target permission data that does not require permission determination. The target permission data associated with the recorded permission information is usually common data, so no permission determination is required and it can be directly provided to the front-end for display.

[0087] In order to reduce the data processing amount of the authority management device, when obtaining the request for accessing the target authority data sent by the front end, it is necessary to first determine whether the authority information corresponding to the target authority data is included in the whitelist set by the configuration module 11.

[0088] When it is determined that the request is included in the whitelist, it means that the user has the authority to access the requested target authority data. At this time, in order to reduce the processing load of the authority management device, the request is directly forwarded to the backend.

[0089] When it is determined that the user is not included in the whitelist, it cannot be determined whether the user has the permission to access the target permission data requested. Therefore, based on the permission management information, it is determined whether the user who initiated the request has the permission to access the target permission data, and corresponding processing is performed according to the judgment result.

[0090] In some embodiments of the present application, Figure 2 As shown, the processing module 12 is also used to provide a prompt to the front end that the target permission data request has failed when the front end obtains the request for accessing the target permission data and determines based on the permission management information that the user who initiated the request does not have the permission to access the target permission data.

[0091] When the processing module 12 determines, based on the rights management information, that the user initiating the request does not have the right to access the target rights data, it indicates that the user has requested rights data that exceeds their access rights. In this case, the processing module 12 intercepts the request and does not send the request to the backend. In addition, in order to let the frontend user know that they do not have the right to access the requested target rights data, a prompt indicating that the target rights data request failed is fed back to the frontend. The prompt can be issued by the frontend through a pop-up window or highlighted text.

[0092] In some embodiments of the present application, the rights management device can be integrated into a rights management toolkit, which can be in the form of an open source package to facilitate customized download and development by business personnel. When it is necessary to perform rights management on the front end and the back end through the rights management device, the toolkit can be downloaded and installed to complete the deployment of the rights management device. After the rights management device is deployed, the rights management information is configured to perform rights management based on the rights management information. The request for access to the target rights data sent by the front end is obtained at the routing of the front end, and it is determined based on the rights management information whether the user who initiated the request has the right to access the target rights data. If it is determined based on the rights management information that the user who initiated the request has the right to access the target rights data, the request is sent to the back end; when the target rights data for the request is received from the back end, the target rights data is processed based on the data type of the target rights data, and the processed target rights data is provided to the front end for display by the front end.

[0093] Furthermore, another embodiment of the present application also provides a rights management system, such as Figure 3 As shown, the rights management system includes: a front end 21, a back end 22 and the above-mentioned rights management device 23.

[0094] The beneficial effects of the rights management system provided in the embodiment of the present application are substantially the same as those of the above-mentioned rights management device, and therefore will not be described in detail here.

[0095] Furthermore, another embodiment of the present application also provides a rights management method, such as Figure 4 As shown, the rights management method includes the following steps:

[0096] 301. Configure permission management information for the front-end, wherein the permission management information includes user information of users involved in the front-end and permission information corresponding to each user information, and the permission information is used to associate the permission data accessible to the corresponding user in the back-end.

[0097] 302. When the request for accessing the target permission data sent by the front end is obtained and it is determined based on the permission management information that the user initiating the request has the permission to access the target permission data, the request is sent to the back end.

[0098] 303. Upon receiving the target permission data for the request fed back by the backend, process the target permission data based on the data type of the target permission data, and provide the processed target permission data to the frontend for display by the frontend.

[0099] The rights management method provided in the embodiments of the present application can decouple rights management from the business logic of the front-end and back-end. In this way, when rights management is required for the front-end and back-end that have an access relationship, there is no need to customize and develop a corresponding rights management system for the front-end or back-end. Rights management can be completed for the front-end and back-end that have an access relationship through the rights management device, so that users can access and only access the data in the back-end that they are authorized to access through the front-end.

[0100] In some embodiments, the specific process of processing the target permission data based on the data type of the target permission data involved in the above step 303 includes: when it is determined that the data type of the target permission data is menu data, converting the target permission data, wherein the converted target permission data meets the menu data display requirements of the front end.

[0101] In some embodiments, the permission management method also includes the following steps: when the preset data processing logic cannot convert the target permission data into permission data that meets the menu data display requirements, the target permission data is processed by calling the target data processing logic corresponding to the menu data display requirements through the first target interface, or a second target interface is provided for the user to write custom data processing logic corresponding to the menu data display requirements.

[0102] In some embodiments, the specific process of processing the target permission data based on the data type of the target permission data involved in the above step 303 includes: when it is determined that the data type of the target permission data is button permission data or user data, the target permission data is stored and processed so that when the front end retrieves the target permission data, the stored target permission data is provided to the front end for display; wherein, the button permission data only includes button information corresponding to the user-executable operation, and the user data only includes user information that the user can view.

[0103] In some embodiments, the permission management method also includes the following steps: when receiving the target permission data for the request fed back by the back-end, storing the target permission data in a first storage method or a second storage method; wherein, the target permission data stored in the first storage method is cleared when the page corresponding to the request in the front-end is closed; the target permission data stored in the second storage method is cleared under a deletion instruction.

[0104] In some embodiments, after obtaining the request for access to target permission data sent by the front end, and before processing the target permission data based on the data type of the target permission data, the permission management method also includes the following steps: determining whether the target permission data corresponding to the request is stored; if so, providing the target permission data to the front end for display by the front end; if not, determining whether the user who initiated the request has the permission to access the target permission data based on the permission management information.

[0105] In some embodiments, after obtaining the request for access to the target permission data sent by the front end, before processing the target permission data based on the data type of the target permission data, the permission management method also includes the following steps: determining whether the permission information corresponding to the target permission data is included in the whitelist; if included, sending the request to the back end; if not, determining whether the user who initiated the request has the permission to access the target permission data based on the permission management information.

[0106] In some embodiments, the permission management method also includes the following steps: before configuring permission management information for the front end, configuring the front end and the back end that has an access relationship with the front end to form configuration information; establishing an interactive relationship between the front end and the back end based on the configuration information.

[0107] In some embodiments, the rights management method further includes the following steps: setting an expiration time point for the rights management information, and performing expiration processing on the rights management information at the expiration time point.

[0108] In some embodiments, the permission management method also includes the following steps: when a request for access to target permission data sent by the front end is obtained, and based on the permission management information, it is determined that the user who initiated the request does not have the permission to access the target permission data, a prompt indicating that the target permission data request failed is fed back to the front end.

[0109] In the rights management method provided in the embodiment of the present application, the detailed explanation of each step can be found in the corresponding detailed explanation of the above-mentioned rights management device embodiment, and will not be repeated here.

[0110] Furthermore, based on the above embodiment, another embodiment of the present application also provides a computer-readable storage medium, which includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the above-mentioned permission management method.

[0111] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0112] It is understood that the relevant features of the above methods and devices can be referenced to each other. In addition, the terms "first" and "second" in the above embodiments are used to distinguish between the embodiments, and do not represent the advantages and disadvantages of the embodiments.

[0113] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0114] The algorithm and display provided herein are not inherently related to any particular computer, virtual system or other device. Various general-purpose systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing such systems. In addition, the application is not directed to any specific programming language. It should be understood that various programming languages ​​can be utilized to implement the content of the application described herein, and the above description of specific languages ​​is for the purpose of disclosing the preferred embodiment of the application.

[0115] In addition, the memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0116] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

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

[0118] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data switching device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0119] These computer program instructions can also be loaded onto a computer or other programmable data switching device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0120] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0121] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0122] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0123] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

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

[0125] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A rights management device, characterized in that: The rights management device is deployed between the front-end and the back-end to achieve decoupling of rights management from the business logic of the front-end and the back-end. The rights management device includes: A configuration module, configured to configure permission management information for the front-end, wherein the permission management information includes user information of users involved in the front-end and permission information corresponding to each user information, and the permission information is used to associate the permission data that the corresponding user can access in the back-end; a processing module configured to, upon receiving a request for accessing target permission data sent by the front end and determining, based on the permission management information, that the user initiating the request has permission to access the target permission data, send the request to the back end, so that the back end does not perform any permission-related operations upon receiving the request sent by the processing module; upon receiving target permission data in response to the request fed back by the back end, process the target permission data based on its data type, and provide the processed target permission data to the front end for display by the front end; The processing module includes: a first processing unit for, when determining that the data type of the target permission data is menu data, performing conversion processing on the target permission data, wherein the converted target permission data meets the menu data display requirement of the front end, the menu data display requirement being issued by the front end to the permission management device based on a user query requirement and being used to limit the display form of the menu data; The processing module includes: a second processing unit, which is used to store and process the target permission data when it is determined that the data type of the target permission data is button permission data or user data, so as to provide the stored target permission data to the front end for display when the front end retrieves the target permission data; wherein, the button permission data only includes button information corresponding to the user-executable operations, and does not include button information corresponding to the user-unexecutable operations, and the user data only includes user information that the user can view.

2. The rights management device according to claim 1, characterized in that: The first processing unit is also used to call the target data processing logic corresponding to the menu data display requirements through the first target interface to process the target permission data when the preset data processing logic cannot convert the target permission data into permission data that meets the menu data display requirements, or provide a second target interface for the user to write custom data processing logic corresponding to the menu data display requirements.

3. The rights management device according to claim 1, wherein: The processing module further includes: A storage unit is used to store the target permission data in a first storage mode or a second storage mode when receiving the target permission data for the request fed back by the back end; wherein the target permission data stored in the first storage mode is cleared when the page corresponding to the request in the front end is closed; and the target permission data stored in the second storage mode is cleared under a deletion instruction.

4. The rights management device according to claim 3, characterized in that: The processing module further includes: The first judgment unit is used to determine whether the target permission data corresponding to the request is stored in the storage unit when a request for accessing the target permission data sent by the front end is obtained; if so, the target permission data is provided to the front end for display by the front end; if not, whether the user who initiates the request has the permission to access the target permission data based on the permission management information.

5. The rights management device according to any one of claims 1 to 4, characterized in that: The processing module further includes: a second judgment unit configured to, upon receiving a request for accessing target permission data sent by the front end, determine whether the permission information corresponding to the target permission data is included in the whitelist set by the configuration module; if so, send the request to the back end; if not, determine whether the user initiating the request has permission to access the target permission data based on the permission management information; and / or, The configuration module is further configured to configure the front end and a back end having an access relationship with the front end to form configuration information before configuring the authority management information for the front end; and to establish an interactive relationship between the front end and the back end based on the configuration information; and / or, The configuration module is further configured to set an expiration time point for the rights management information and perform expiration processing on the rights management information at the expiration time point; and / or, The processing module is also used to provide a prompt to the front end that the target permission data request has failed when the front end obtains the request for accessing the target permission data and determines based on the permission management information that the user who initiated the request does not have the permission to access the target permission data.

6. A rights management system, characterized in that: The rights management system includes: a front end, a back end, and the rights management device according to any one of claims 1 to 5.

7. A rights management method, characterized in that: Applied to a rights management device, the rights management device is deployed between the front-end and back-end to achieve decoupling of rights management from the business logic of the front-end and back-end, the method includes: Configure permission management information for the front-end, wherein the permission management information includes user information of users involved in the front-end and permission information corresponding to each user information, and the permission information is used to associate the permission data that the corresponding user can access in the back-end; Upon receiving a request for accessing target permission data sent by the front end and determining based on the permission management information that the user initiating the request has permission to access the target permission data, the back end is sent the request to the back end, so that the back end does not perform any permission-related operations when receiving the request sent by the processing module; Upon receiving the target permission data for the request fed back by the backend, processing the target permission data based on the data type of the target permission data, and providing the processed target permission data to the frontend for display by the frontend; Processing the target permission data based on the data type of the target permission data includes: When it is determined that the data type of the target permission data is menu data, converting the target permission data, wherein the converted target permission data meets the menu data display requirement of the front end, the menu data display requirement being issued by the front end to the permission management device based on a user query requirement and being used to limit the display form of the menu data; When it is determined that the data type of the target permission data is button permission data or user data, the target permission data is stored and processed so that when the front end retrieves the target permission data, the stored target permission data is provided to the front end for display; wherein, the button permission data only includes button information corresponding to the user-executable operations, and does not include button information corresponding to the user-unexecutable operations, and the user data only includes user information that the user can view.

8. A computer-readable storage medium, characterized in that The storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the rights management method according to claim 7.

Images