A permission query method and device for chart access, equipment and medium

Abstract

The application discloses a kind of permissions query methods, devices and equipment for chart access and medium, it is related to computer technology field, for solving the shortcoming that current fine-grained permission control cannot meet the needs of, comprising: receiving the permission query request generated when user accesses chart by query engine sends;Query number is generated based on the permission query request is obtained, and target query information is obtained based on the query number;According to the target query information, it is verified whether the permission query request has access permission, to obtain verification result;The verification result is returned to the query engine, so as to determine corresponding query information based on the verification result and send the query information to the user.The application generates query number by permission query request, and the permission verification of permission query request is carried out using the obtained query information, simplifies permission verification model, provides more fine-grained permission control, meets the needs of customized permission control.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for querying permissions for accessing charts. Background Technology

[0002] Metabase (an open-source business intelligence platform) has its own permission system that supports assigning permissions to user groups based on data source and the collection to which the chart belongs. While this system can provide a coarse level of control over Metabase chart permissions, it has the following drawbacks: 1. The granularity of permission control is at the data source, collection, and user group level, which is relatively coarse and difficult to meet the needs of fine-grained permission control, such as direct control at the user and chart levels. 2. As an independent permission system, it cannot be integrated with other internal security systems; it is not conducive to centralized authorization of permissions and cannot achieve one-time authorization for multiple parties (multiple data platforms). 3. As an internal permission system of Metabase, it is difficult to perform real-time monitoring and post-event auditing of data queries. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for querying permissions for chart access, which simplifies the permission verification model, provides more granular permission control, and meets customized permission management needs. The specific solution is as follows:

[0004] In a first aspect, the present invention discloses a permission query method for chart access, applied to a permission system, comprising:

[0005] Receive permission query requests generated when the query engine sends user access charts;

[0006] Obtain the query number generated based on the permission query request, and obtain the target query information based on the query number;

[0007] Verify whether the permission query request has the required access rights based on the target query information, and obtain the verification result;

[0008] The verification result is returned to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

[0009] Optionally, before receiving the permission query request generated when the query engine sends the user access graph, the method further includes:

[0010] Determine whether the user has accessed the dashboard of the chart;

[0011] If the user accesses the dashboard of the chart, a dashboard query request is generated, and the dashboard query request is split into corresponding first permission query requests based on each chart card in the dashboard, and a corresponding hash value is generated based on the first permission query request.

[0012] If the user has not accessed the dashboard of the chart, it is determined that the user has accessed the chart card, and a second permission query request and the hash value are directly generated based on the chart card.

[0013] Optionally, before receiving the permission query request generated when the query engine sends the user access graph, the method further includes:

[0014] The target information received by the query engine is stored in a preset storage area through a preset event handling plugin; the target information includes the permission query request, the query number, the hash value, and user information corresponding to the user.

[0015] Optionally, obtaining the query number generated based on the permission query request and obtaining the target query information based on the query number includes:

[0016] Obtain the query number generated based on the permission query request, and perform a query from the preset storage area based on the query number to obtain the target hash value and target user information.

[0017] Optionally, the step of verifying whether the permission query request has access rights based on the target query information to obtain a verification result includes:

[0018] When the permission query request is the first permission query request, each first permission query request is sequentially verified to have the access permission according to the target query information;

[0019] If all of the first permission query requests have the access permission, then the verification result is determined to be that the dashboard query request passes;

[0020] If none of the first permission query requests have the required access rights, then the verification result is determined to be that the dashboard query request fails.

[0021] If a preset number of the first permission query requests have the access permission, then the verification result is determined to be that the dashboard query request is partially passed; wherein the preset number is greater than 0 and less than the total number of the first permission query requests.

[0022] Optionally, returning the verification result to the query engine, so as to determine the corresponding query information based on the verification result and sending the query information to the user, includes:

[0023] The verification result is returned to the query engine;

[0024] If the verification result is successful, the target chart information corresponding to the permission query request will be sent to the user.

[0025] If the verification result is a verification failure, a notification message indicating that the user does not have permission is sent to the user.

[0026] Optionally, the step of verifying whether the permission query request has access rights based on the target query information to obtain a verification result includes:

[0027] Determine whether the preset permission database contains permission information corresponding to the target query information;

[0028] If the permission information corresponding to the target query information exists in the permission database, then the permission query request is determined to have the access permission, and the verification result is determined to be verified successfully.

[0029] Secondly, the present invention discloses a permission query device for chart access, applied to a permission system, comprising:

[0030] The permission query request receiving module is used to receive permission query requests generated when the query engine sends user access graphs.

[0031] The query information acquisition module is used to acquire the query number generated based on the permission query request, and to acquire the target query information based on the query number;

[0032] The verification module is used to verify whether the permission query request has the required access rights based on the target query information, so as to obtain the verification result;

[0033] The query information return module is used to return the verification result to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

[0034] Thirdly, the present invention discloses an electronic device, comprising:

[0035] Memory, used to store computer programs;

[0036] A processor is configured to execute the computer program to implement the steps of the permission query method for chart access as disclosed above.

[0037] Fourthly, the present invention discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the permission query method for chart access as disclosed above.

[0038] As can be seen, this invention provides a method for querying permissions for chart access, comprising: receiving a permission query request generated when a user accesses a chart, sent by a query engine; obtaining a query number generated based on the permission query request, and obtaining target query information based on the query number; verifying whether the permission query request has access permissions according to the target query information, to obtain a verification result; and returning the verification result to the query engine so as to determine the corresponding query information based on the verification result and send the query information to the user. Therefore, this invention generates a query number through the permission query request, verifies the permission query request using the obtained query information, and uses a self-built permission system for permission verification, avoiding secondary development of Metabase, simplifying the permission verification model, providing more granular permission control, and meeting customized permission management needs. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0040] Figure 1 This is a flowchart of a permission query method for chart access disclosed in this invention;

[0041] Figure 2 This is a schematic diagram of the system interaction disclosed in this invention;

[0042] Figure 3 This is a schematic diagram of a permission query method for chart access disclosed in this invention;

[0043] Figure 4 This is a flowchart of a specific permission query method for chart access disclosed in this invention;

[0044] Figure 5 This is a schematic diagram of the logic for converting dashboard authentication into card authentication as disclosed in this invention;

[0045] Figure 6 This is a schematic diagram of the permission query device for chart access provided by the present invention.

[0046] Figure 7This invention provides a structural diagram of an electronic device. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] Currently, Metabase's own permission system supports assigning permissions to user groups based on data source and the collection to which the chart belongs. While this system can achieve a coarse control over Metabase chart permissions, it has the following drawbacks: The granularity of permission control is at the data source, collection, and user group level, which is relatively coarse and difficult to meet the needs of fine-grained permission control, such as direct control at the user and chart levels. As an independent permission system, it cannot be integrated with other internal security systems; it is not conducive to centralized authorization, and cannot achieve one-time authorization for multiple parties (multiple data platforms). Furthermore, as an internal Metabase permission system, it is difficult to perform real-time monitoring and post-event auditing of data queries. Therefore, this invention provides a permission query method for chart access, which simplifies the permission verification model, provides more granular permission control, and meets customized permission management needs.

[0049] This invention discloses a method for querying permissions for chart access, see [link to relevant documentation]. Figure 1 As shown, applied to a permission system, the method includes:

[0050] Step S11: Receive the permission query request generated when the user accesses the graph sent by the query engine.

[0051] In this embodiment, a permission query request is generated when a user access chart is sent by the query engine. It is understood that before receiving the permission query request generated when the user access chart is sent by the query engine, the target information received by the query engine is stored in a preset storage area through a preset event handling plugin; the target information includes the permission query request, the query number, the hash value, and user information corresponding to the user.

[0052] like Figure 2As shown, this invention comprises three applications / systems: the Metabase application, the Trino query engine, and a self-built permission system. Metabase uses Trino as the query engine to actually perform data query operations. Trino provides pluggable permission verification capabilities, allowing for the development of customized permission verification plugins. The self-built permission system is an independently deployed system that provides centralized authorization functionality, enabling simultaneous access authorization for users to dashboards or cards. Both Metabase and Trino involved in this invention are open-source versions. Metabase is an open-source BI (Business Intelligence) platform, typically used for data analysis and data visualization. Data teams can use Metabase to create analytical charts, while business teams can use Metabase to view the created charts. In this paper, Metabase charts are referred to collectively as Metabase dashboards and Metabase cards. Metabase cards are the basic module of charts in Metabase, supporting chart types such as bar charts, pie charts, and line charts; hereinafter referred to as cards. The Metabase dashboard is a Metabase dashboard that doesn't contain data itself. It can be viewed as a container for cards; one or more cards are added to the dashboard, and these cards are combined to display chart information as a whole. Hereinafter referred to as the dashboard, it's simply called the dashboard. A self-built permission system is a data permission control system built internally by the company to manage data security and centrally control data permissions across different data platforms within the company. Trino is a commonly used distributed query engine in big data platforms, supporting queries from multiple data sources. In this article, it's used as the Metabase query engine (data source). Trino provides a comprehensive plugin system, such as event plugins and permission control plugins, allowing users to embed their own processing logic into Trino's execution process. This method involves custom-developing Trino's permission control and event handling plugins. SQL is a database query language used to query data.

[0053] Furthermore, such as Figure 3The detailed processing flow of permission verification in the three systems is as follows: When a user accesses the dashboard or directly accesses a card in Metabase, Metabase sends an SQL query execution request to Trino using the SQL (Structured Query Language) statement corresponding to the card and the query_hash value generated for the current query. After receiving the request from Metabase, Trino first saves the relevant information of this SQL query to its self-built permission system through a custom event handling plugin for subsequent authentication. The information obtainable by the self-built permission system includes: the unique query ID (query_id) of the current query by Trino, the query_hash value (hash value) generated by Metabase during the current query, and Metabase user information. It's worth noting that requests for the same card may generate the same hash value at different storage times, and each time a query is performed, the permission query request generates a new query ID.

[0054] Step S12: Obtain the query number generated based on the permission query request, and obtain the target query information based on the query number.

[0055] In this embodiment, after receiving the permission query request generated when the query engine sends a user access chart, a query number generated based on the permission query request is obtained, and target query information is obtained based on the query number. Specifically, the query number generated based on the permission query request is obtained, and a query is performed from the preset storage area based on the query number to obtain the target hash value and target user information.

[0056] Understandably, as mentioned above Figure 3 As shown, Trino calls the authentication interface of the self-built permission system through a custom permission control plugin. At this time, the only valuable information that Trino can pass is query_id. Other information, such as Metabasequery_hash value and Metabase user information, will not be passed. At this time, the Metabase query_hash value and Metabase user information for the current query are obtained from the information pre-stored in step S11 through query_id.

[0057] It should be noted that, in addition to pushing relevant information to the self-built permission system through the Trino event plugin, the self-built system can also actively pull the relevant information from Trino.

[0058] Step S13: Verify whether the permission query request has access rights based on the target query information to obtain the verification result.

[0059] In this embodiment, after obtaining the query number generated based on the permission query request and obtaining the target query information based on the query number, the permission query request is verified to determine whether it has the required access permissions based on the target query information, thereby obtaining a verification result. Specifically, it is determined whether there is permission information corresponding to the target query information in a preset permission database; if the permission information corresponding to the target query information exists in the permission database, the permission query request is determined to have the required access permissions, and the verification result is determined to be a successful verification.

[0060] Step S14: Return the verification result to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

[0061] In this embodiment, after verifying whether the permission query request has the required access permissions based on the target query information and obtaining the verification result, the verification result is returned to the query engine so that the corresponding query information can be determined based on the verification result and sent to the user. Specifically, the verification result is returned to the query engine; if the verification result is successful, the target chart information corresponding to the permission query request is sent to the user; if the verification result is unsuccessful, a notification message indicating that the user lacks permissions is sent to the user.

[0062] Metabase and a self-built permission system are each deployed independently. When a user queries a chart in Metabase, the self-built permission system needs to authenticate the queried chart during the data query process in Metabase. This invention provides a non-intrusive authentication method for Metabase. In addition to Metabase's built-in permission system, this invention provides a method for verifying permissions to Metabase charts using a Trino engine plugin combined with a self-built permission system. It transforms dashboard permission verification into card permission verification, simplifying and unifying the permission verification model.

[0063] As can be seen, this invention provides a method for querying permissions for chart access, comprising: receiving a permission query request generated when a user accesses a chart, sent by a query engine; obtaining a query number generated based on the permission query request, and obtaining target query information based on the query number; verifying whether the permission query request has access permissions according to the target query information, to obtain a verification result; and returning the verification result to the query engine so as to determine the corresponding query information based on the verification result and send the query information to the user. Therefore, this invention generates a query number through the permission query request, verifies the permission query request using the obtained query information, and uses a self-built permission system for permission verification, avoiding secondary development of Metabase, simplifying the permission verification model, providing more granular permission control, and meeting customized permission management needs.

[0064] See Figure 4 As shown, this embodiment of the invention discloses a method for querying permissions for chart access. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution.

[0065] Step S21: Determine whether the user has accessed the dashboard of the chart.

[0066] In this embodiment, it is determined whether the user has accessed the dashboard of the chart. Specifically, if the user has accessed the dashboard of the chart, a dashboard query request is generated, and the dashboard query request is split into corresponding first permission query requests based on each chart card in the dashboard, and a corresponding hash value is generated based on the first permission query request; if the user has not accessed the dashboard of the chart, it is determined that the user has accessed the chart card, and a second permission query request and the hash value are directly generated based on the chart card.

[0067] Understandably, as mentioned above Figure 2 As shown, the Metabase application creates dashboards and cards. Cards can be accessed individually or added to one or more dashboards. For example, dashboard1 contains card1 and card2, and card2 can also be accessed individually. The specific steps are as follows: [The above...] Figure 2The specific meaning of (1) is that after a user accesses a chart through Metabase, Metabase calls Trino to perform a query. Regardless of whether the user accesses a dashboard or a card, the granularity of the query when Metabase calls Trino is card. That is, the card is the basic unit for displaying the chart, while the dashboard is just a combination of cards. Therefore, a query for a dashboard will be broken down into a query for each card in the dashboard. Figure 2 The specific meaning of (2) is that when Trino receives a query request, it will call the permission verification plugin to perform permission verification, and the permission verification plugin will call its self-built permission system interface to perform permission verification. Figure 2 In this context, (3) and (4) specifically mean that after the self-built permission system receives a request from the Trino plugin, it retrieves the relevant query information based on the Trino query number, including the corresponding card information for this query. The above... Figure 2 The specific meaning of (5) is as follows: Fourth, the self-built permission system performs permission verification on the card and returns the result of the Trino permission verification plugin. Figure 2 The specific meaning of (6) is that Trino returns the Metabase query result based on the result of the permission verification plugin.

[0068] Step S22: Receive the permission query request generated when the user accesses the graph sent by the query engine.

[0069] In this embodiment, a first permission query request and / or a second permission query request generated when the user accesses the graph sent by the query engine are received.

[0070] Step S23: Obtain the query number generated based on the permission query request, and obtain the target query information based on the query number.

[0071] Step S24: Verify whether the permission query request has access rights based on the target query information to obtain the verification result.

[0072] In this embodiment, after obtaining the query number generated based on the permission query request and obtaining the target query information based on the query number, the permission query request is verified to determine whether it has the required access permissions based on the target query information, thereby obtaining a verification result. It can be understood that when the permission query request is the first permission query request, each first permission query request is sequentially verified to determine whether it has the required access permissions based on the target query information; if all first permission query requests have the required access permissions, the verification result is determined to be that the dashboard query request passes; if none of the first permission query requests have the required access permissions, the verification result is determined to be that the dashboard query request fails; if a preset number of first permission query requests have the required access permissions, the verification result is determined to be that the dashboard query request partially passes; wherein the value of the preset number is greater than 0 and less than the value of the total number of first permission query requests.

[0073] Understandably, when querying the card ID corresponding to the query_hash using the Metabase query_hash, if the query originated from the dashboard, the dashboard ID can also be retrieved. Since the same card can be accessed either by being added to a dashboard or as a standalone card, the corresponding query_hash remains the same regardless of the access method. Therefore, it's impossible to determine whether the access occurred via the dashboard or directly through the card using the query_hash. This currently presents an issue of not being able to determine whether the user's dashboard permissions or card permissions are being verified.

[0074] This invention provides a method for transforming dashboard authentication into card authentication, unifying the verification of card permissions. Since a card can be accessed directly or through its associated dashboard, the information obtained during authentication is insufficient to determine whether the access originated directly from the card or from the dashboard, and therefore, whether authentication is performed on the card or the dashboard. Therefore, the invention transforms dashboard authentication into card authentication. Figure 5 As shown, Figure 5The middle model diagram represents user A granting access permissions to dashboard_2 and card_4 in a self-built permission system. The model diagram on the left describes the existing relationship between dashboards and cards in the Metabase system. Dashboard_2 already contains card_1 and card_3, so a user with access to dashboard_2 can be considered to have access permissions to card_1 and card_3. The model diagram on the right shows that, after conversion, user A has access permissions to card_1, card_3, and card_4. When user A accesses dashboard_2, Trino actually performs queries on card_1 and card_3, so permission verification is required for user A's access to card_1 and card_3. During the permission verification process, user A's authorization to dashboard_2 is converted to authorization to card_1 and card_3, thus the permission verification passes. When user A accesses dashboard_1, permission verification is actually required for user A to access card_1 and card_2. However, the user only has authorization for dashboard_2, and after conversion, only card_1 and card_3 are authorized, but not card_2. Therefore, card_1 will pass the verification, while card_2 will fail the permission verification.

[0075] This invention requires no secondary development of Metabase, provides more granular permission control than Metabase's built-in permission system, seamlessly integrates with a company's unified data permission control system, and conveniently meets customized permission management needs. Furthermore, to address the issue of determining whether to perform permission verification on the dashboard or the card, this invention offers a simple approach, transforming dashboard permission verification into card permission verification, thus simplifying and unifying the permission verification model.

[0076] Step S25: Return the verification result to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

[0077] For details regarding steps S23 and S25, please refer to the corresponding content disclosed in the foregoing embodiments, which will not be repeated here.

[0078] As can be seen, this embodiment of the application simplifies the permission verification model and provides more granular permission control by determining whether the user has accessed the dashboard of the chart; receiving a permission query request generated when the user accesses the chart from the query engine; obtaining a query number generated based on the permission query request and obtaining target query information based on the query number; verifying whether the permission query request has the required access permissions according to the target query information to obtain a verification result; and returning the verification result to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user. This provides more refined permission control and meets customized permission management needs.

[0079] See Figure 6 As shown, this embodiment of the invention also discloses a permission query device for chart access, applied to a permission system, comprising:

[0080] The permission query request receiving module 11 is used to receive permission query requests generated when the query engine sends a user access graph.

[0081] The query information acquisition module 12 is used to acquire the query number generated based on the permission query request, and to acquire the target query information based on the query number;

[0082] Verification module 13 is used to verify whether the permission query request has access rights based on the target query information, so as to obtain a verification result;

[0083] The query information return module 14 is used to return the verification result to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

[0084] As can be seen, the present invention includes: receiving a permission query request generated when a user accesses a graph sent by a query engine; obtaining a query number generated based on the permission query request, and obtaining target query information based on the query number; verifying whether the permission query request has access permissions according to the target query information to obtain a verification result; and returning the verification result to the query engine so as to determine the corresponding query information based on the verification result and send the query information to the user. Therefore, the present invention generates a query number through the permission query request, verifies the permission query request using the obtained query information, and uses a self-built permission system for permission verification, avoiding secondary development of Metabase, simplifying the permission verification model, providing more granular permission control, and meeting customized permission management needs.

[0085] In some specific embodiments, the permission query request receiving module 11 specifically includes:

[0086] A dashboard access determination unit is used to determine whether the user accesses the dashboard of the chart;

[0087] A dashboard query request generation unit is used to generate a dashboard query request if the user accesses the dashboard of the chart.

[0088] The dashboard query request splitting unit is used to split the dashboard query request into a corresponding first permission query request based on each chart card in the dashboard.

[0089] The first hash value generation unit is used to generate a corresponding hash value based on the first permission query request;

[0090] The chart card access determination unit is used to determine that the user has accessed the chart card if the user has not accessed the dashboard of the chart.

[0091] The second hash value generation unit is used to directly generate a second permission query request and the hash value based on the chart card;

[0092] The target information storage unit is used to store the target information received by the query engine into a preset storage area through a preset event handling plugin; the target information includes the permission query request, the query number, the hash value, and user information corresponding to the user;

[0093] The permission query request receiving unit is used to receive permission query requests generated when the query engine sends user access graphs.

[0094] In some specific embodiments, the query information acquisition module 12 specifically includes:

[0095] The query number acquisition unit is used to acquire the query number generated based on the permission query request.

[0096] The target user information acquisition unit is used to query from the preset storage area based on the query number to obtain the target hash value and the target user information.

[0097] In some specific embodiments, the verification module 13 specifically includes:

[0098] The first permission query request permission verification unit is used to verify, in turn, whether each first permission query request has the access permission according to the target query information when the permission query request is the first permission query request.

[0099] The dashboard query request passing determination unit is used to determine that the verification result is that the dashboard query request passes if all the first permission query requests have the access permission.

[0100] The dashboard query request failure determination unit is used to determine that the verification result is that the dashboard query request fails if none of the first permission query requests have the access permission.

[0101] The dashboard query request section passes the determination unit, which determines that if a preset number of the first permission query requests have the access permission, the verification result is that the dashboard query request section passes; wherein the preset number is greater than 0 and less than the total number of the first permission query requests.

[0102] In some specific embodiments, the verification module 13 specifically includes:

[0103] The permission information existence determination unit is used to determine whether there is permission information corresponding to the target query information in the preset permission library;

[0104] The verification pass determination unit is used to determine that the permission query request has the access permission if the permission information corresponding to the target query information exists in the permission library, and to determine the verification result as verification pass.

[0105] In some specific embodiments, the query information return module 14 specifically includes:

[0106] The verification result return unit is used to return the verification result to the query engine;

[0107] The target chart information sending unit is used to send the target chart information corresponding to the permission query request to the user if the verification result is successful.

[0108] The notification information sending unit is used to send a notification information to the user indicating that the user does not have permission if the verification result is a verification failure.

[0109] Furthermore, embodiments of the present invention also provide an electronic device. Figure 7 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of the invention.

[0110] Figure 7This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present invention. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the permission query method for graph access disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0111] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this invention, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0112] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0113] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the permission query method for graph access executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0114] Furthermore, this embodiment of the invention also discloses a storage medium storing a computer program. When the computer program is loaded and executed by a processor, it implements the permission query method steps for chart access disclosed in any of the foregoing embodiments.

[0115] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0116] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0117] The foregoing has provided a detailed description of a method, apparatus, device, and medium for querying permissions for chart access provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for querying access permissions for charts, characterized in that, Applied to permission systems, including: Receive permission query requests generated when a user accesses a chart, sent by the query engine; wherein, the permission query request is a query request generated when the user accesses the chart through Metabase, and Metabase uses Trino as the query engine that actually performs the data query operation, and Metabase and the permission system are deployed independently. Obtain the query number generated based on the permission query request, and obtain the target query information based on the query number; Verify whether the permission query request has the required access rights based on the target query information, and obtain the verification result; The verification result is returned to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

2. The permission query method for chart access according to claim 1, characterized in that, Before receiving the permission query request generated when the query engine sends the user access graph, the process also includes: Determine whether the user has accessed the dashboard of the chart; If the user accesses the dashboard of the chart, a dashboard query request is generated, and the dashboard query request is split into corresponding first permission query requests based on each chart card in the dashboard, and a corresponding hash value is generated based on the first permission query request. If the user has not accessed the dashboard of the chart, it is determined that the user has accessed the chart card, and a second permission query request and the hash value are directly generated based on the chart card.

3. The permission query method for chart access according to claim 2, characterized in that, Before receiving the permission query request generated when the user access graph is sent by the query engine, the following is also included: The target information received by the query engine is stored in a preset storage area through a preset event handling plugin; the target information includes the permission query request, the query number, the hash value, and user information corresponding to the user.

4. The permission query method for chart access according to claim 3, characterized in that, The step of obtaining the query number generated based on the permission query request and obtaining the target query information based on the query number includes: Obtain the query number generated based on the permission query request, and perform a query from the preset storage area based on the query number to obtain the target hash value and target user information.

5. The permission query method for chart access according to claim 2, characterized in that, The step of verifying whether the permission query request has the required access rights based on the target query information, in order to obtain a verification result, includes: When the permission query request is the first permission query request, each first permission query request is sequentially verified to have the access permission according to the target query information; If all of the first permission query requests have the access permission, then the verification result is determined to be that the dashboard query request passes; If none of the first permission query requests have the required access permission, then the verification result is determined to be that the dashboard query request fails. If a preset number of the first permission query requests have the access permission, then the verification result is determined to be that the dashboard query request is partially passed; wherein the preset number is greater than 0 and less than the total number of the first permission query requests.

6. The permission query method for chart access according to claim 1, characterized in that, The step of returning the verification result to the query engine, so as to determine the corresponding query information based on the verification result and send the query information to the user, includes: The verification result is returned to the query engine; If the verification result is successful, the target chart information corresponding to the permission query request will be sent to the user. If the verification result is a verification failure, a notification message indicating that the user does not have permission is sent to the user.

7. The permission query method for chart access according to any one of claims 1 to 6, characterized in that, The step of verifying whether the permission query request has the required access rights based on the target query information, in order to obtain a verification result, includes: Determine whether the preset permission database contains permission information corresponding to the target query information; If the permission information corresponding to the target query information exists in the permission database, then the permission query request is determined to have the access permission, and the verification result is determined to be verified successfully.

8. A permission query device for chart access, characterized in that, Applied to permission systems, including: The permission query request receiving module is used to receive permission query requests generated when a user accesses a chart, sent by the query engine; wherein, the permission query request is a query request generated when the user accesses the chart through Metabase, and Metabase uses Trino as the query engine that actually performs the data query operation, and Metabase and the permission system are deployed independently. The query information acquisition module is used to acquire the query number generated based on the permission query request, and to acquire the target query information based on the query number; The verification module is used to verify whether the permission query request has the required access rights based on the target query information, so as to obtain the verification result; The query information return module is used to return the verification result to the query engine so that the corresponding query information can be determined based on the verification result and the query information can be sent to the user.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the permission query method for chart access as described in any one of claims 1 to 7.

10. A computer-readable medium, characterized in that, Used to store computer programs; wherein, when executed by a processor, the computer programs implement the permission query method for chart access as described in any one of claims 1 to 7.

Images