Request processing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a request processing method and device, electronic equipment and a storage medium. The method comprises the following steps: receiving a target query request sent by a request end, wherein the target query request carries a user identifier and a destination address; analyzing the target query request to obtain fields corresponding to the target query request and a nesting relationship between the fields; obtaining an interface list corresponding to the target query request according to the fields and the nesting relationship between the fields; and if it is determined that the user to which the user identifier belongs has the access authority to the resource corresponding to each interface in the interface list, sending the target query request to a response end corresponding to the destination address. According to the method, more accurate authorization management can be performed on the target query request, so that the security of data access is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a request processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Currently, query methods such as graphical query requests and natural language queries are widely used due to their flexible query capabilities. However, when using these query methods, although the static binding of roles and field access permissions in the data structure definition is simple and secure, it lacks support for dynamic strategies and cannot meet the fine-grained permission control needs (such as page-level authorization) commonly found in enterprises. Therefore, providing a method for more accurate authorization management of query requests is an urgent technical problem to be solved. Summary of the Invention

[0003] In view of this, embodiments of this application propose a request processing method, apparatus, electronic device, and storage medium, which can achieve more accurate authorization management of target query requests, thereby improving the security of data access.

[0004] In a first aspect, embodiments of this application provide a request processing method applied to a gateway device. The method includes: receiving a target query request sent by a requesting end, the target query request carrying a user identifier and a destination address; parsing the target query request to obtain fields corresponding to the target query request and the nesting relationships between the fields; obtaining an interface list corresponding to the target query request based on the fields and the nesting relationships between the fields; and if it is determined that the user to which the user identifier belongs has access rights to the resources corresponding to each interface in the interface list, sending the target query request to a responding end corresponding to the destination address.

[0005] Secondly, embodiments of this application provide a request processing apparatus applied to a gateway device. The apparatus includes: a request receiving module, configured to receive a target query request sent by a requesting end, the target query request carrying a user identifier and a destination address; a request parsing module, configured to parse the target query request to obtain fields corresponding to the target query request and the nesting relationships between the fields; an interface obtaining module, configured to obtain a list of interfaces corresponding to the target query request based on the fields and the nesting relationships between the fields; and a request forwarding module, configured to send the target query request to a responding end corresponding to the destination address when it is determined that the user to whom the user identifier belongs has access rights to the resources corresponding to each interface in the interface list.

[0006] In one possible implementation, the interface list is a list of interface calls; the request parsing module is further configured to parse the target query request into an abstract syntax tree, wherein the abstract syntax tree carries the fields corresponding to the target query request and the nesting relationships between the fields.

[0007] In one possible implementation, the interface list is a list of interface calls. The interface acquisition module is further configured to obtain the interface corresponding to the field from the correspondence between preset fields and interfaces; and to construct a list of interface calls corresponding to the target query request based on the nesting relationship between the fields and the interface corresponding to the field.

[0008] In one possible implementation, the interface acquisition module is also used to verify the abstract syntax tree; if the abstract syntax tree is verified, the interface corresponding to the field in the syntax tree is obtained from the correspondence between preset fields and interfaces.

[0009] In one possible implementation, the request processing device further includes: a prompt sending module, used to send a request error prompt to the requesting end when the validation of the abstract syntax tree fails.

[0010] In one possible implementation, the request processing device further includes: an authentication request sending module and an authentication result acquisition module. The authentication request sending module is used to send an authentication request including the user identifier and the interface list to the authentication server. The authentication result acquisition module is used to acquire the authentication result obtained by the authentication server in response to the authentication request based on the user identifier and the interface list. The authentication result is used to indicate whether the user has access rights to the resources corresponding to each interface in the interface list.

[0011] In one possible implementation, the request processing device further includes an authentication result sending module, configured to send an authentication failure result to the requesting end when it is determined that the user to which the user identifier belongs does not have access rights to the resource corresponding to at least one interface in the interface list, wherein the authentication failure result carries interface information of the interface to which the user does not have access rights.

[0012] In one possible implementation, the request processing device further includes a query result receiving module and a query result forwarding module; the query result receiving module is used to receive the query result fed back by the responding end in response to the target query request; the query result forwarding module is used to forward the query result to the requesting end.

[0013] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor to implement the above-described method.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, wherein the above-described method is executed when the program code is run by a processor.

[0015] Fifthly, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device retrieves the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described above.

[0016] This application provides a request processing method, apparatus, electronic device, and storage medium. Upon receiving a target query request (such as a GraphQL graphical query request), the gateway performs syntactic and semantic parsing to extract the fields and their nesting relationships. Then, based on the fields and their nesting relationships, it obtains a list of interfaces corresponding to the target query request, converting these field structures into an equivalent list of interfaces. Since each interface represents a specific resource node, it accurately locates the resource actually accessed by the target query request. Furthermore, since each interface can undergo independent permission verification, by verifying the permissions of each interface in the interface list, and determining that the user to whom the user identifier belongs has access rights to the resources corresponding to each interface in the interface list, the target query request is sent to the response end corresponding to the destination address. This achieves fine-grained authorization at the page level, operation level, and even context-dependent levels, enabling more accurate authorization management of target query requests and thus improving data access security. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a request processing method provided in an embodiment of this application is shown;

[0019] Figure 2 This paper illustrates another flowchart of a request processing method provided in an embodiment of this application.

[0020] Figure 3 This illustration shows another flowchart of a request processing method provided in an embodiment of this application;

[0021] Figure 4 A timing flowchart of a request processing method provided in an embodiment of this application is shown;

[0022] Figure 5 This illustration shows another timing flow diagram of a request processing method provided in an embodiment of this application;

[0023] Figure 6 This paper shows a connection block diagram of a request processing apparatus according to an embodiment of this application;

[0024] Figure 7 A structural block diagram of an electronic device for performing the methods of embodiments of this application is shown. Detailed Implementation

[0025] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0026] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0027] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0028] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0029] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0030] Figure 1 This application provides a request processing method that can be applied to an electronic device, which can be a gateway device or any device with gateway functionality or data forwarding processing functionality. The method includes:

[0031] Step S110: Receive a target query request sent by the requesting end, wherein the target query request carries a user identifier and a destination address.

[0032] The requesting end can be a terminal (such as a mobile phone, computer, tablet computer, vehicle terminal, etc.) or any device capable of sending a target query request, such as a server.

[0033] A target query request refers to a request submitted by a user to a database, search engine, API, or other information retrieval system, with the purpose of obtaining (or accessing) specific data or information. In this embodiment, the main target query request refers to sending a target query request to a response terminal that has deployed a database, search engine, or information retrieval system.

[0034] The query request sent by the requesting end can be of a preset syntax / language or a query request for a preset interface, such as, but not limited to, one or more of the following: graphical query requests (e.g., GraphQL query requests), natural language query requests, specified syntax query requests, and server resource retrieval requests (e.g., RESTful query requests). GraphQL query requests (Graph Query Language) efficiently query related data through a graph data model (the relationship between nodes and edges), and the returned fields are defined by the requesting end. RESTful query requests (Representational State Transfer) can manipulate resources through a unified interface, allowing resources to transfer state between the requesting and responding ends in a certain representation form (e.g., JSON, XML).

[0035] In one possible implementation of this application, the target query request may include a graphical query request, and may also include a query request with specified syntax.

[0036] Specifically, after receiving a query request, the gateway device can determine whether it is a target query request based on the query request's syntax structure (for example, if the query request's syntax structure is a nested declarative query structure, then the query request is a target query request; if the query request's syntax structure is a Uniform Resource Locator (URL) path + query parameters query structure (e.g., a RESTful query request), then the query request is not a target query request). Alternatively, it can determine whether the query request is a target query request based on the request method (for example, if the request method is POST (i.e., submit or send), the query request is a target query request; if the request method is an HTTP method, the query request is not a target query request (e.g., a RESTful request)). The above methods for determining whether a query request is a target query request are merely illustrative; there can be many other methods, which are not specifically limited here. For example, the query request can carry identifiers corresponding to graphical query requests or server resource read requests; these identifiers can be used to determine whether the query request is a target query request.

[0037] Step S120: Parse the target query request to obtain the fields corresponding to the target query request and the nesting relationships between the fields.

[0038] The target query request can be a string. Parsing the target query request specifically involves converting it into an abstract syntax tree (Abstract Syntax Tree). This Abstract Syntax Tree carries the fields corresponding to the target query request and the nesting relationships between these fields. Specifically, when parsing the target query request into an Abstract Syntax Tree, since the syntax tree contains the fields corresponding to the target query request, the fields and their nesting relationships can be extracted by traversing the syntax tree. The nesting relationships between fields can be used to represent the dependencies between them.

[0039] Step S130: Obtain the list of interfaces corresponding to the target query request based on the fields and the nesting relationships between the fields.

[0040] In one possible implementation, the interface list is a list of interface calls; the gateway device may store a pre-defined mapping between fields and interfaces. (See [link to relevant documentation]). Figure 2 The above step S130 includes:

[0041] Step S132: Obtain the interface corresponding to the field from the preset correspondence between fields and interfaces.

[0042] The mapping relationship can store fields from multiple target query requests and the corresponding interface (e.g., a RESTful interface) for each field. After obtaining the fields from the graphical target query request sent by the requesting party, the interface corresponding to that field can be found from the mapping relationship.

[0043] Step S134: Based on the nesting relationship between the fields and the interfaces corresponding to the fields, construct a call list of the interfaces corresponding to the target query request.

[0044] Among them, the nesting relationship between fields refers to the parent-child dependency relationship between fields. The nesting relationship determines the order of interface calls and data dependencies. Therefore, an ordered list of RESTful interface calls can be generated according to the nesting level of the fields.

[0045] By employing the steps S132-S134 described above, it is possible to find the corresponding interface by each field when query requirements are varied and field combinations are complex. Subsequently, the calling order of each interface can be obtained through the nesting relationship between fields, and the list of interfaces corresponding to the target query request can also be obtained.

[0046] In another possible implementation, the gateway device pre-stores multiple interface lists corresponding to preset query information. Each preset query information includes a set of preset fields and the nesting relationships between these fields. The target preset query information corresponding to the fields and their nesting relationships is obtained from the multiple preset query information (the preset fields included in the target preset query information are the fields parsed above, and the nesting relationships between the preset fields included in the target preset query information are the nesting relationships between the fields obtained above). The interface list corresponding to the target preset query information is then converted into the interface list corresponding to the target query request. This interface list can be a list of interface calls, which determines the calling order of each interface in the interface list based on the nesting relationships between the fields after obtaining the interface list corresponding to the target preset query information. This allows for a fast and accurate retrieval of the interface list corresponding to the target query request through direct table lookup.

[0047] In both of the above implementations, the interface call list may include one or more interfaces and the order in which the interfaces are called.

[0048] The above method for obtaining the list of interfaces corresponding to the target query request is only illustrative. There are many other ways to obtain it, which are not specifically limited here.

[0049] It is worth mentioning that when the fields corresponding to the target query request and the nesting relationship between the fields are obtained from the abstract syntax tree, the above-mentioned step of obtaining the list of interfaces corresponding to the target query request based on the fields and the nesting relationship between the fields can be: verifying the abstract syntax tree; if the abstract syntax tree is verified, obtaining the interface corresponding to the field in the syntax tree from the preset correspondence between fields and interfaces.

[0050] If the validation of the abstract syntax tree fails, a request error message is sent to the requesting end. Upon receiving the request error message, the requesting end can display it, allowing the user to re-initiate the target query request based on the error message.

[0051] Verification of the abstract syntax tree includes one or more of the following: syntactic structure verification, semantic verification, and logical verification. Syntactic structure verification refers to calling the parser to check whether the node composition and hierarchical relationship of the abstract syntax tree conform to the syntactic rules. Semantic verification refers to calling the type checker or semantic analyzer to check whether the semantics expressed by the abstract syntax tree are reasonable (e.g., checking whether the referenced variables or functions have been declared, confirming whether the scope of variables / functions is legal, etc.). Logical verification refers to calling static analysis tools to check whether there are logical contradictions or potential errors in the abstract syntax tree.

[0052] Step S140: If it is determined that the user to which the user identifier belongs has access rights to the resources corresponding to each interface in the interface list, send the target query request to the response end corresponding to the destination address.

[0053] One interface can correspond to one or more resources. When an interface corresponds to multiple resources, access permissions can be managed for each resource, i.e., user access permissions can be configured independently on a resource-by-resource basis, or access permissions can be managed for each interface, i.e., user access permissions can be configured uniformly on an interface-by-interface basis. Based on this, step S140 can be: determining whether the user to which the user identifier belongs has access permissions for each of the multiple resources corresponding to each interface in the interface list. If the user has access permissions for each of the multiple resources corresponding to each interface in the interface list, then the target query request can be sent to the response end corresponding to the destination address. Step S140 can also be: determining whether the user to which the user identifier belongs has access permissions for calling each interface in the interface list. If the user has access permissions for calling each interface in the interface list, then the target query request can be sent to the response end corresponding to the destination address.

[0054] The process of determining whether the user to whom the user identifier belongs has access rights to the resources corresponding to each interface in the interface list can be performed by the gateway device or by a professional authentication service (such as a remote authentication server), depending on the requirements.

[0055] One method for determining whether a user to which a user identifier belongs has access rights to the resources corresponding to each interface in the interface list is as follows: The authentication device (such as a gateway device or a remote authentication server) can store multiple preset identifiers and accessible presentation layer state interfaces corresponding to each preset identifier. The authentication device can determine whether the user identifier is included among the multiple identifiers. If it is, it can determine whether each interface in the interface list belongs to the accessible presentation layer state interface corresponding to the user identifier. If all interfaces belong to the user identifier, it can determine that the user to which the user identifier belongs has access rights to the resources corresponding to each interface in the interface list. Alternatively, the authentication device can store multiple preset identifiers, each corresponding to a user type, and accessible presentation layer state interfaces corresponding to each user type. The authentication device can determine whether the user identifier is included among the multiple identifiers. If it is, it can determine whether each interface in the interface list belongs to the accessible interface corresponding to the user type to which the user identifier belongs. If all interfaces belong to the user identifier, it can determine that the user to which the user identifier belongs has access rights to the resources corresponding to each interface in the interface list.

[0056] The above method of determining whether a user has access to the resources corresponding to each interface in the interface list is merely illustrative. There may be other methods of determination, which are not specifically limited here.

[0057] Specifically, by sending a target query request to the responding end, the responding end can parse the target query request, generate an ordered list of interfaces, and query data based on the list of interfaces to obtain the query results.

[0058] In one possible implementation, the gateway sends a target query request carrying a list of interfaces to the responding end, so that the responding end responds to the target query request by querying data according to the list of interfaces carried in the target query request and obtains the query results.

[0059] By employing the method described in this application, upon receiving a target query request (such as GraphQL), the gateway performs syntactic and semantic parsing on the target query request, extracting the fields of the target query request and their nesting relationships. Then, based on the fields and their nesting relationships, it obtains a list of interfaces corresponding to the target query request, thus converting these field structures into a set of equivalent interface lists. Since each interface represents a specific resource node, it accurately locates the resource actually accessed by the target query request. Furthermore, since each interface can undergo independent permission verification, by verifying the permissions of each interface in the interface list, and determining that the user to whom the user identifier belongs has access rights to the resources corresponding to each interface in the interface list, the target query request is sent to the response end corresponding to the destination address. This achieves fine-grained authorization at the page level, operation level, and even context-dependent levels, enabling more accurate authorization management of target query requests and thereby improving data access security.

[0060] In one possible implementation, if it is determined that the user to whom the user identifier belongs does not have access rights to the resource corresponding to at least one interface in the interface list, an authentication failure result is sent to the requesting end, and the authentication failure result carries the interface information of the interface to which the user does not have access rights.

[0061] By adopting the above settings, users can clearly see which interfaces they are not authorized to access, rather than simply receiving a vague "insufficient permissions" message. This allows the requesting end to make adjustments upon receiving authentication failure results, or to quickly locate permission issues when a permission problem is identified, without having to troubleshoot interface by interface.

[0062] In one implementation, after performing step S140, the method further includes: receiving the query result returned by the responding end in response to the target query request; and forwarding the query result to the requesting end.

[0063] The response from the responding end to the target query request can return query results in formats such as JSON, XML, or Protobuf. Since the target query request is a graphical query request, the gateway can also adjust the query results to the expected structure after receiving the query results. The expected structure can be nested JSON.

[0064] In one possible implementation, please refer to Figure 3 Before performing step S140, the method further includes:

[0065] Step S160: Send an authentication request to the authentication server, including the user identifier and the list of interfaces.

[0066] The authentication server can be an IAM server (Identity and Access Management), which provides basic services for access control to securely control access permissions to cloud services and resources.

[0067] Step S170: Obtain the authentication result obtained by the authentication server in response to the authentication request based on the user identifier and the interface list. The authentication result is used to indicate whether the user has access rights to the resources corresponding to each interface in the interface list.

[0068] The authentication server responds to the authentication request by performing authentication based on the user identifier and interface list. For details on the authentication process in step S140 in the foregoing embodiments, please refer to the specific description of the authentication process. It will not be repeated here.

[0069] By adopting the above method, after obtaining the list of interfaces corresponding to the target query request, the permission management capabilities of the existing authentication server can be directly used for permission verification, thereby achieving more accurate and efficient authorization management of the target query request and improving the security of data access.

[0070] Specifically, taking an authentication server as an IAM server, a target query request as a GraphQL request, and an interface list using a RESTful API as an example, the technical solution and its effects are illustrated below: Since IAM servers typically possess mature models such as roles, policies, and user groups, these widely validated management capabilities can directly determine permissions for GraphQL query requests without requiring the development of complex separate permission logic. Furthermore, IAM systems inherently support fine-grained permission models based on resources, operations, and conditions. Once the RESTful interface corresponding to the GraphQL query request is obtained, each RESTful interface can be mapped to a specific IAM policy rule, thereby achieving fine-grained authorization based on user identity, resource attributes, time range, and other conditions. This fine-grained control is difficult to achieve through traditional GraphQL middleware or simple role checks. Moreover, since GraphQL requests can be converted to RESTful interfaces and IAM can be used to verify whether the user identifier has access permissions to the resources corresponding to the RESTful interface, this not only reduces development costs but also improves the security and consistency of the entire system. In other words, GraphQL services can be seamlessly integrated into the authentication and authorization processes of IAM servers without requiring significant modifications to the IAM server itself. Furthermore, by listing the interfaces corresponding to the target query requests, it becomes easier to adapt to different environments or scenarios. For example, RESTful interfaces offer advantages in terms of universality and standardization across IAM systems from different cloud vendors. This flexibility helps GraphQL services implement unified permission management policies in multi-cloud or hybrid cloud scenarios. Moreover, since IAM systems typically possess comprehensive auditing, logging, and compliance support capabilities, by adopting the above methods, all graphical query requests ultimately become IAM authorization check records. This allows administrators to understand who accessed which data and when, and what operations were performed, through IAM logs and auditing tools, thereby improving the overall security and auditability of the system.

[0071] like Figure 4 The diagram illustrates an application scenario of a request processing method provided in this application. The gateway device has an output interface and can be equipped with plugins or software modules for parsing graphical query requests (GraphQL query requests) (e.g., iam-bff plugin, (IAM Backend for Frontend, a dedicated backend for identity and access management)) and plugins or software modules for authenticating RESTful query requests (e.g., iam-policy plugin, (IAM Policy, identity and access management policy / permission policy)).

[0072] The specific request processing procedure is as follows:

[0073] Before executing the above request processing method, the XaaS service (X as a Service, where X is a variable representing any resource or function that can be provided as a service; the diagram shows the case where the XaaS service is the responding end (e.g., a GraphQL server)) can pre-register the mapping rules between the preset query information and the list of RESTful interfaces (i.e., the correspondence between query information and RESTful interfaces) in the gateway. The query information includes fields or fields and nested relationships between fields.

[0074] Users can initiate query requests through the requesting end, such as requesting information on cloud hosts or SKE clusters (Serverless Kubernetes Engine).

[0075] When the gateway device detects that the query request is a GraphQL query request (target query request), it forwards it to the built-in iam-bff plugin.

[0076] The iam-bff plugin converts GraphQL query requests into a list of RESTful APIs in bulk.

[0077] Specifically, the iam-bff plugin parses GraphQL query requests to extract fields and their nested relationships. Based on pre-registered mapping rules, it converts the fields and their nested relationships into a corresponding list of RESTful API calls.

[0078] The iam-bff plugin sends the user identifier carried in the batch and query requests for the list of RESTful interfaces to the remote authentication server (IAM server).

[0079] The authentication server checks whether the user to which the user identifier belongs has the permission to access the resources corresponding to each RESTful interface (based on the permission policy of the cloud platform SCC (Security Compliance Center) / SCP (Security Compliance Platform)) and returns the authentication result (where, if all interfaces pass authentication → return "success"; if any interface fails authentication → return "failure" and a list of specific interfaces that do not have permission).

[0080] When the authentication result is successful (i.e., the user to whom the user identifier belongs has access rights to the resources corresponding to each interface in the presentation layer state transition interface list), the gateway device forwards the query request to the response end (e.g., the GraphQL service) corresponding to the destination address in the query request. The GraphQL service executes the query, aggregates the data, and returns the query results to the requesting end through the gateway device so that the user can view the query results.

[0081] When the authentication result fails, the gateway device intercepts the GraphQL query request and returns the authentication failure result to the user. The authentication failure result carries the interface information of the interface that the user does not have access to.

[0082] When the gateway detects that the query request is a RESTful query request, it forwards it to the built-in iam-policy plugin for authentication. After successful authentication, it forwards the request to the response end corresponding to the destination address in the RESTful query request. This allows the response end to execute the query, obtain the query results, and return them to the requesting end through the gateway device so that the user can view the query results.

[0083] like Figure 5 The diagram illustrates the process of converting a GraphQL query request into a list of RESTful APIs and performing IAM authentication. The gateway device contains software modules such as a compilation module, a checking module, and a transformation module. It is also associated with a configuration center for storing mapping rules and an authentication server with associated software modules including an authentication module and an aggregation module. Notably, the aggregation module can also be included within the gateway device. Figure 5 The example shown only illustrates the case where the aggregation module is located within the authentication server.

[0084] Specifically, when the gateway device determines that the query request is a GraphQL query request, it sends the GraphQL query request to the compilation module.

[0085] The compiler module parses GraphQL queries into an Abstract Syntax Tree (AST). An AST is a structured representation used to describe the syntax and logical relationships of a query (e.g., field nesting, parameter passing). For example, if the query request is `query{books{title author{name}}}`, the AST will parse out the hierarchical relationships between fields such as `books`, `title`, `author`, and `name`.

[0086] The compilation module is also used to send the abstract syntax tree to the inspection module.

[0087] The inspection module is used to validate the abstract syntax tree. This includes performing one or more validations such as syntax compliance, semantic validity, and nesting legality.

[0088] If the verification is successful, the abstract syntax tree is sent to the conversion module.

[0089] The configuration center stores mapping rules, which are preset mapping rules between query information and the list of RESTful interfaces.

[0090] The transformation module retrieves the list of presentation layer state transition interfaces corresponding to the GraphQL request from the configuration center based on the query information in GraphQL. Then, it sends the list of presentation layer state transition interfaces and the user identifier to the authentication server.

[0091] The authentication server sequentially performs permission policy authentication on each RESTful interface in the presentation layer state transition interface list based on the user identifier, and submits the authentication results (pass / fail) of all interfaces to the aggregation module for unified processing. The aggregation module aggregates all authentication results and generates a final authentication conclusion; if all interfaces pass authentication: the query request is allowed to continue to be passed to the backend service (response end). If any interface fails authentication: the query request is intercepted and a permission failure message is returned.

[0092] By adopting the above methods, GraphQL saves significant development time on web application programming interfaces (APIs) during front-end page integration testing. When implementing the solution, there's no need to develop a separate permission module for GraphQL; instead, existing RESTful IAM interfaces can be reused, shortening the development cycle by over 40%. Furthermore, complex GraphQL queries are dynamically compiled into standardized RESTful interfaces for batch authentication, avoiding the serial latency of traditional layer-by-layer verification. 95% of the GraphQL API responses on the front-end pages are within 1 second, especially noticeable on complex multi-field nested pages such as cluster overviews. In addition, all authentication records can be stored on the authentication server, allowing administrators to locate user actions and quickly pinpoint abnormal behavior through these logs. The authentication server also enables centralized GraphQL authentication, eliminating code redundancy caused by traditional distributed verification and reducing the probability of system failures due to inconsistent permission logic.

[0093] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0094] Please see Figure 6 Another embodiment of this application provides a request processing device 200, applied to a gateway device. The request processing device 200 includes: a request receiving module 210, used to receive a target query request sent by a requesting end, the target query request carrying a user identifier and a destination address; a request parsing module 220, used to parse the target query request to obtain the fields corresponding to the target query request and the nesting relationships between the fields; an interface obtaining module 230, used to obtain a list of interfaces corresponding to the target query request based on the fields and the nesting relationships between the fields; and a request forwarding module 240, used to send the target query request to the responding end corresponding to the destination address when it is determined that the user to which the user identifier belongs has access rights to the resources corresponding to each interface in the interface list.

[0095] In one possible implementation, the interface list is a list of interface calls; the request parsing module 220 is further configured to parse the target query request into an abstract syntax tree, wherein the abstract syntax tree carries the fields corresponding to the target query request and the nesting relationships between the fields.

[0096] In one possible implementation, the interface list is a call list of interfaces. The interface acquisition module 230 is further configured to obtain the interface corresponding to the field from the correspondence between preset fields and interfaces; and construct the call list of the interface corresponding to the target query request based on the nesting relationship between the fields and the presentation layer transfer interface corresponding to the field.

[0097] In one possible implementation, the interface acquisition module 230 is also used to verify the abstract syntax tree; if the abstract syntax tree is verified, the interface corresponding to the field in the syntax tree is obtained from the correspondence between preset fields and interfaces.

[0098] In one possible implementation, the request processing device 200 further includes: a prompt sending module, used to send a request error prompt to the requesting end when the validation of the abstract syntax tree fails.

[0099] In one possible implementation, the request processing device 200 further includes: an authentication request sending module and an authentication result acquisition module. The authentication request sending module is used to send an authentication request including the user identifier and the interface list to the authentication server. The authentication result acquisition module is used to acquire the authentication result obtained by the authentication server in response to the authentication request based on the user identifier and the interface list. The authentication result is used to indicate whether the user has access rights to the resources corresponding to each interface in the interface list.

[0100] In one possible implementation, the request processing device 200 further includes an authentication result sending module, which is used to send an authentication failure result to the requesting end when it is determined that the user to which the user identifier belongs does not have access rights to the resource corresponding to at least one interface in the interface list. The authentication failure result carries the interface information of the interface to which the user does not have access rights.

[0101] In one possible implementation, the request processing device 200 further includes a query result receiving module and a query result forwarding module; the query result receiving module is used to receive the query result fed back by the responding end in response to the target query request; the query result forwarding module is used to forward the query result to the requesting end.

[0102] Each module in the above-described device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module. It should be noted that the device embodiments in this application correspond to the foregoing method embodiments. The specific principles of the device embodiments can be found in the foregoing method embodiments, and will not be repeated here.

[0103] The following will combine Figure 7 This application provides a description of an electronic device 100.

[0104] Please see Figure 7 Based on the methods provided in the above embodiments, this application also provides another electronic device 100 including a processor 102 capable of executing the aforementioned methods. The electronic device 100 can be a server or a requesting end.

[0105] The electronic device 100 also includes a memory 104. The memory 104 stores a program that can execute the contents of the foregoing embodiments, and the processor 102 can execute the program stored in the memory 104.

[0106] The processor 102 may include one or more cores for data processing and message matrix units. The processor 102 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 102 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 102 and may be implemented separately using a communication chip.

[0107] The memory 104 may include random access memory (RAM) or read-only memory (ROM). The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data acquired by the electronic device 100 during use (e.g., parking location, environmental information, and images).

[0108] The electronic device 100 may also include a network module and a screen. The network module is used to receive and transmit electromagnetic waves, converting electromagnetic waves into electrical signals, thereby enabling communication with communication networks or other devices, such as audio playback devices. The network module may include various existing circuit elements used to perform these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, SIM cards, memory, etc. The network module can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks, or metropolitan area networks. The screen can display interface content and perform data interaction, such as displaying the aforementioned interface and triggering operations through the screen.

[0109] This application also provides a structural block diagram of a computer-readable storage medium. The computer-readable medium stores program code, which can be called by a processor to execute the methods described in the above method embodiments.

[0110] Computer-readable storage media can be electronic storage devices such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, computer-readable storage media includes non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in a suitable form.

[0111] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described in the various optional implementations above.

[0112] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A request processing method, characterized in that, Applied to a gateway device, the method includes: The receiving end sends a target query request, which carries a user identifier and a destination address; Parse the target query request to obtain the fields corresponding to the target query request and the nesting relationships between the fields; Based on the fields and the nesting relationships between the fields, obtain a list of interfaces corresponding to the target query request; If it is determined that the user to whom the user identifier belongs has access rights to the resources corresponding to each interface in the interface list, the target query request is sent to the response end corresponding to the destination address.

2. The method according to claim 1, characterized in that, The process of parsing the target query request to obtain the fields corresponding to the target query request and the nested relationships between the fields includes: The target query request is parsed into an abstract syntax tree, which carries the fields corresponding to the target query request and the nesting relationships between the fields.

3. The method according to claim 2, characterized in that, The interface list is a list of interface calls; The step of obtaining the list of interfaces corresponding to the target query request based on the fields and the nesting relationships between the fields includes: Obtain the interface corresponding to the field from the preset correspondence between fields and interfaces; Based on the nesting relationships between the fields and the interfaces corresponding to the fields, construct a call list for the interfaces corresponding to the target query request.

4. The method according to claim 3, characterized in that, The step of obtaining the interface corresponding to the field in the syntax tree from the correspondence between preset fields and interfaces includes: The abstract syntax tree is validated; If the abstract syntax tree is validated, the interface corresponding to the field in the syntax tree is obtained from the preset correspondence between fields and interfaces.

5. The method according to claim 4, characterized in that, The method further includes: If the validation of the abstract syntax tree fails, a request error message is sent to the requesting client.

6. The method according to claim 1, characterized in that, Before sending the target query request to the response end corresponding to the destination address, the method further includes: Send an authentication request, including the user identifier and the list of interfaces, to the authentication server; The authentication server responds to the authentication request with an authentication result obtained based on the user identifier and the interface list. The authentication result is used to indicate whether the user has access rights to the resources corresponding to each interface in the interface list.

7. The method according to claim 1, characterized in that, The method further includes: If it is determined that the user to whom the user identifier belongs does not have access rights to the resource corresponding to at least one interface in the interface list, an authentication failure result is sent to the requesting end, and the authentication failure result carries the interface information of the interface to which the user does not have access rights.

8. The method according to claim 1, characterized in that, After sending the target query request to the response end corresponding to the destination address, the method further includes: Receive the query results returned by the response end in response to the target query request; The query result is forwarded to the requesting end.

9. A request processing apparatus, characterized in that, Applied to a gateway device, the device includes: The request receiving module is used to receive a target query request sent by the requesting end, wherein the target query request carries a user identifier and a destination address; The request parsing module is used to parse the target query request and obtain the fields corresponding to the target query request and the nesting relationships between the fields. An interface acquisition module is used to obtain a list of interfaces corresponding to the target query request based on the fields and the nesting relationships between the fields. The request forwarding module is used to send the target query request to the response end corresponding to the destination address when it is determined that the user to which the user identifier belongs has access rights to the resources corresponding to each interface in the interface list.

10. An electronic device, characterized in that, include: One or more processors; Memory; One or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs being configured to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code that can be invoked by a processor to execute the method as described in any one of claims 1-8.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-8.

Images