Data processing method and device, computer equipment, storage medium and program product

Abstract

The invention relates to a data processing method and device, computer equipment, a storage medium and a computer program product. The method comprises the steps that a data query request is received, request information corresponding to the data query request is obtained, and the request information comprises at least one authorization verification object and a request query parameter; obtaining interface authorization information of the authorization verification object under a request interface corresponding to the data query request; and if the interface authorization information represents that the authorization verification object has the data query permission, obtaining target data based on the request query parameter. By adopting the method, the management and control requirements of massive user data access authorities can be met.

Description

Technical Field

[0001] This application relates to the field of big data processing technology, and in particular to a data processing method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] In traditional technologies, data access control is usually based on roles. That is, multiple roles are set for a type of data, and each role has its own data permissions. After a user binds to a role, he or she will have the corresponding data permissions.

[0003] However, in open platforms, each user needs to maintain their own data, and this data is isolated from each other. For example, when a user is a merchant, the data that needs to be maintained differs for different merchants. If traditional role-based access control methods are still used, different roles need to be defined for each user. Therefore, with the ever-increasing scale of interactions on open platforms, traditional access control methods will be unable to adapt to the access management of massive numbers of users on open platforms. Summary of the Invention

[0004] Therefore, it is necessary to provide a data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can meet the requirements of access control for massive amounts of user data, addressing the aforementioned technical problems.

[0005] Firstly, this application provides a data processing method. The method includes:

[0006] Upon receiving a data query request, obtain the request information corresponding to the data query request, wherein the request information includes at least one authorization verification object and request query parameters;

[0007] Obtain the interface authorization information of the authorization verification object under the request interface corresponding to the data query request;

[0008] If the interface authorization information indicates that the authorized verification object has data query permissions, then the target data is obtained based on the request query parameters.

[0009] Secondly, this application also provides a data processing apparatus. The apparatus includes:

[0010] The request receiving module is used to receive a data query request and obtain the request information corresponding to the data query request, wherein the request information includes at least one authorization verification object and request query parameters;

[0011] The interface authorization information acquisition module is used to acquire the interface authorization information of the authorization verification object under the request interface corresponding to the data query request;

[0012] The data query module is used to obtain target data based on the request query parameters if the interface authorization information indicates that the authorized verification object has data query permissions.

[0013] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described method.

[0014] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0015] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0016] The aforementioned data processing method, apparatus, computer equipment, storage medium, and computer program product determine the authorization verification object from the request information corresponding to the data query request, obtain the interface authorization information corresponding to the authorization verification object under the request interface, and determine the interface authorization information based on the authorization verification object and the request interface. The authorization verification object can be used to clarify the restricted or constrained data query object when querying data for a data query request, and can also clarify the restricted or constrained data query scope when accessing the request interface based on the data query request. Thus, when the interface authorization information clarifies the data query permission, it achieves the purpose of restricted access to the data maintained by each user. Finally, when the interface authorization information indicates that the user has data query permission, the target data is obtained based on the request query parameters, completing the restricted access to the data. In addition, by using the request interface and the authorization verification object in the request information as the dimensions for data query permission control, it is not necessary to define different roles for each user for permission control, thus achieving the purpose of restricted access to the data maintained by each user and meeting the permission control requirements for access to massive user data. Attached Figure Description

[0017] Figure 1 This is a diagram illustrating the application environment of a data processing method in one embodiment.

[0018] Figure 2 This is a flowchart illustrating a data processing method in one embodiment;

[0019] Figure 3 This is a flowchart illustrating the process of receiving a data query request and obtaining the request information corresponding to the data query request in one embodiment.

[0020] Figure 4 This is a schematic diagram of the interaction of a data processing system in one embodiment;

[0021] Figure 5 This is an interaction sequence diagram of the internal interaction flow of the data processing system in one embodiment;

[0022] Figure 6 This is a flowchart illustrating the data processing method in another embodiment;

[0023] Figure 7 This is a structural block diagram of a data processing device in one embodiment;

[0024] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] The data processing method provided in this application embodiment can be applied to a first terminal, an open platform, or a first terminal configured with an open platform, and is not limited thereto.

[0027] The first terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, such as smartwatches, smart bracelets, and head-mounted devices.

[0028] Optionally, the data processing method provided in the embodiments of this application can also be applied to, for example, Figure 1 In the application environment shown, a first terminal 102, configured with an open platform, communicates with a second terminal 104 and a data server 106 via a network. A data storage system can store the data that the first terminal 102 needs to process. The data storage system can be integrated onto the first terminal 102 or placed on a cloud or other network server. When the first terminal 102 receives a data query request triggered by the second terminal 104, it can obtain the request information corresponding to the data query request, including the authorization verification object and the request query parameters. Subsequently, it obtains the interface authorization information of the authorization verification object under the request interface corresponding to the data query request. If the interface authorization information indicates that the authorization verification object has data query permissions, it retrieves the target data from the data server 106 based on the request query parameters.

[0029] The second terminal 104 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, such as smartwatches, smart bracelets, and head-mounted devices. Optionally, both the first terminal 102, configured with an open platform, and the data server 106 can be implemented using independent servers or a server cluster consisting of multiple servers.

[0030] An open platform encapsulates the platform's functionalities through standardized interfaces and provides them to external users. Its core logic lies in enabling the system's capabilities to be open without modifying the source code. External developers can use the open platform's publicly available application programming interfaces (APIs) to perform secondary development, build applications or services, thereby extending the original system functionality of the open platform. By providing standardized programming interfaces—open interfaces—the open platform acts as a bridge between internal platform functions and external applications. Understandably, the open interfaces of an open platform can be developed and provided by the corresponding operator of the open platform.

[0031] Optionally, the second terminal 104 may integrate various applications or application services, and can interact with the first terminal 102 based on the applications or application services integrated in the second terminal 104. The applications or application servers can implement corresponding functions, such as data query functions, by calling the interfaces provided by the first terminal 102. It is understood that the core functions of the second terminal 104 include, but are not limited to, providing users with an interactive interface, encapsulating and sending requests, calling open interfaces, and displaying results.

[0032] Optionally, the data server 106 is a service system for securely storing, managing, and providing data. When it is necessary to query relevant data in the data server 106, data can be forwarded through the open platform.

[0033] In one embodiment, such as Figure 2 As shown, a data processing method is provided, which can be applied to... Figure 1 Taking the first terminal 102 as an example, the explanation includes the following steps:

[0034] S202, Receive a data query request and obtain the request information corresponding to the data query request, wherein the request information includes at least one authorized verification object and request query parameters.

[0035] Among them, a data query request is an instruction signal used to instruct the retrieval of specific data from a data server, which can be initiated by a second terminal through an application or application service.

[0036] The request information is a component of the data query request. This information may include an authorization verification object and query parameters, effectively conveying these elements to the data query request. The authorization verification object refers to the entity whose data query permissions need to be verified during the query process. It explicitly restricts or constrains the data query object. Optionally, the authorization verification object may include at least one of the following: external developer, data provider, application or application service, interface query type, interface identifier, and request interface path. For example, the data provider may be a merchant. The application or application service may be considered an external application or a request initiation platform.

[0037] The request query parameters are parameters that describe and limit the specific target and scope of the data query. They can include parameters such as the data type and range of the target data to be queried. Request query parameters can be used to clearly define the target data to be retrieved.

[0038] Optionally, when the open platform receives a data query request, it can parse the data query request to obtain the request information carried by the data query request, which includes the authorization verification object and the request query parameters.

[0039] Optionally, receiving a data query request can be triggered based on a received data query instruction. The data query instruction can be triggered by clicking a data query button or by a corresponding action, such as a touch operation or a voice control command.

[0040] S204, obtain the interface authorization information of the authorization verification object under the request interface corresponding to the data query request.

[0041] The interface authorization information of the authorization verification object under the request interface refers to the permission rule information stored regarding the binding relationship between the authorization verification object and the request interface. Interface authorization information is based on a data query request carrying the authorization verification object, and specifies the data query permission information confirmed for the authorization verification object under the request interface. Since the acquisition of interface authorization information is jointly determined by the authorization verification object and the request interface, the authorization verification object can be used to clarify the restricted or constrained data query objects when performing data queries for a data query request. Based on the request interface, the restricted or constrained data query scope when accessing the request interface based on a data query request can be clarified. Therefore, when performing data queries through a data query request, the interface authorization information can be used to restrict the purpose of data access.

[0042] It is understood that the corresponding authorization verification object may include at least one of the following verification objects: external developer, data provider, application or application service, interface query type, interface identifier, and request interface path. This indicates that when performing a data query for a data query request carrying an authorization verification object, the restricted or constrained data query object includes at least one of the following: external developer, data provider, application or application service, interface query type, interface identifier, and request interface path.

[0043] The data query permission information includes at least one of authorization type and authorization scope. Authorization types include full authorization and partial authorization. The authorization scope determines the range of data that can be queried; optionally, the data query scope can be represented by a dataset.

[0044] For example, suppose the data query request is a request to query the member information of the store with storeIds [1001, 1002, 1004]. Based on the interface authorization information of the authorization verification object under the request interface, the corresponding authorized scope is determined to be {1001, 1002, 1003}, which means that the data query scope authorized by the data is: the member information of stores with store Ids 1001, 1002, and 1003 can be queried.

[0045] Understandably, when performing data queries, it is necessary to verify the data query permissions by checking the interface authorization information of the authorized verification object under the requested interface, so as to determine whether the authorized verification object has the data query permissions under the requested interface.

[0046] In one embodiment, authorization record information can be obtained, and interface authorization information matching the authorization verification object can be queried from the authorization record information. The authorization record information is data used to record the correspondence between each authorization verification object and each interface authorization information.

[0047] As an optional implementation, obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request can be directly determined based on the relationship between the authorization verification object, the request interface information, and the interface authorization information. When the authorization verification object and the request interface are determined through the data query request, the corresponding interface authorization information is obtained based on the relationship.

[0048] Optionally, the relationship between the authorization verification object, the request interface, and the interface authorization information can be stored or set in advance.

[0049] Optionally, there can be at least one authorization verification object. When there are at least two authorization verification objects, the open platform can query the interface authorization information that matches each authorization verification object from the authorization record information, and use it as the interface authorization information under the corresponding request interface of the data query request. In this embodiment, in scenarios requiring multiple authorizations, the traditional approach requires defining a complete set of permissions for each user or role separately. For scenarios requiring multiple permission combinations, new roles must be created, which will lead to a surge in the number of roles. In this embodiment, the basic permissions of each object are recorded through the authorization record information. When multiple authorizations are required, the platform can automatically calculate the combination result. For example, in an enterprise management scenario, there are 10 regional directors and 5 functional directors. The traditional approach may require defining 50 combined roles to achieve permission combination management. However, this embodiment does not require repeatedly defining fine-grained permissions for each authorization verification object. It only needs to maintain 15 basic authorization records through the authorization record information to quickly determine the interface authorization information that satisfies multiple authorization verification objects, realizing fine-grained allocation and flexible superposition of permissions, and effectively reducing the operation and maintenance cost of permission management.

[0050] Optionally, the authorization verification object may include at least one of the following: external developer, data provider, application or application service, interface query type, interface identifier, and request interface path. Different authorization verification objects may determine different or the same interface authorization information under the request interface.

[0051] Optionally, when the authorization verification object in the request information includes at least two items, step S04 includes:

[0052] Retrieve the interface authorization information of each authorized verification object under the corresponding request interface of the data query request.

[0053] It should be noted that the authorized verification object may include at least one of the following: external developer, data provider, application or application service, interface query type, interface identifier, and request interface path. When the authorized verification object includes at least two items, the interface authorization information under the request interface corresponding to the data query request refers to the unique data query permission information jointly determined by each authorized verification object.

[0054] For illustrative purposes, this example uses an open platform. In practical applications, the request interface corresponding to a data query request is a standardized business function access point predefined and provided externally by the open platform. It is also the basic unit for access control by the open platform, providing a standardized channel for data communication between the application or service integrated into the second terminal and the open platform. Each request interface exposed by the open platform encapsulates a specific business operation or interface query type, such as interfaces for retrieving a store member list, querying a store order list, or querying a product list. When a data query is performed through an application or application service, the application or application service will send the encapsulated data query request to the open platform by calling the corresponding request interface.

[0055] Assume that the open platform stores the relationship between authorization verification objects, request interfaces, and interface authorization information. The authorization verification objects include at least one of external developers, merchants, and the request initiating platform. The request interface information includes, for example, the request interface path and / or interface query type. The authorization scope determined by the interface authorization information is represented by the data query authorization scope, where the numbers in the data query authorization scope are store identifiers. The relationship can be shown in Table 1 below:

[0056]

[0057]

[0058] Table 1

[0059] It should be noted that the data query request is initiated through the request initiation platform. For example, if the data query request is to query the store member information with storeIds of [1001,1002,1004], the open platform receives the data query request and determines that the authorization verification object in the corresponding request information includes the developer information Openkey of developer 1 and the request query parameter storeIds of [1001,1002,1004].

[0060] In a specific example, the authorization information of the authorized verification object under the requested interface is obtained. Assuming that the data query request is initiated based on platform 1 and the request interface information is the request interface path, then the interface authorization information of developer 1 under the request interface path (such as path 1) is 1001, 1002, and 1003, indicating that the developer has the permission to query the member list of stores 1001, 1002, and 1003 under path 1.

[0061] In a specific example, the authorization information of the authorized verification object under the requested interface is obtained. Assuming that the data query request is initiated by platform 1 and the request interface information is interface query type, then the interface authorization information of developer 1 under the interface query type of querying store members is 1001, 1002, 1003, 2001, 2002, 2003, indicating that the developer has the permission to query the member list of stores 1001, 1002, 1003, 2001, 2002, 2003.

[0062] In a specific example, the authorization information of the authorized verification object under the requested interface is obtained. Assuming that the data query request is initiated by platform 1 and the request interface information is interface query type, then the interface authorization information of platform 1 under the interface query type of querying store members is 1001, 1002, 1003, 2001, 2002, 2003, indicating that platform 1 has the permission to query the member list of stores 1001, 1002, 1003, 2001, 2002, 2003.

[0063] It should be noted that, in this implementation, the interface authorization information of the authorization verification object under the request interface is determined. Different authorization verification objects may have different or the same interface authorization information determined under the request interface. In practical applications, the interface authorization information under the request interface can be set according to the specific application scenario requirements, based on different authorization verification objects, to meet the data access permission control requirements of different application scenarios. This embodiment does not limit this.

[0064] As an optional implementation, step S204 includes: obtaining request interface information and / or data rules corresponding to the request query parameters; and determining the interface authorization information of the authorization verification object under the request interface based on the data rules. The specific implementation process of this implementation will be described in detail in subsequent embodiments, and therefore will not be described in detail in this embodiment.

[0065] S206. If the interface authorization information indicates that the authorized verification object has data query permissions, then the target data is obtained based on the request query parameters.

[0066] The type of the authorization verification object can be at least one of the following: external developer, data provider, application or application service, interface query type, interface identifier, and request interface path. Combining the authorization verification object carried in the data query request with the corresponding request interface as the verification or validation dimension for data query permission control, in this embodiment, the interface authorization information indicates that the authorization verification object possesses data query permissions. This can be understood as the authorization verification object carried in the data query request passing the data query permission verification or validation under the request interface. Based on the data query request carrying the authorization verification object, the target data can be obtained by accessing the request interface and using the request query parameters.

[0067] Optionally, determining whether an authorized verification object has data query permissions can be achieved by performing an authorization request operation on the request interface for the authorized verification object. For example, the authorized verification object can apply in advance to the data provider storing the data in the data server for data query permissions for the authorized verification object. Only after obtaining the data query permissions granted by the data provider can it pass the permission verification and obtain the required target data based on the request query parameters.

[0068] In a specific example, if the authorized verification object has data query permissions, it can be considered that the authorized verification object has obtained the authorization from the data provider corresponding to the target data in advance for the query operation on the target data. It is compliant to obtain the target data based on the request query parameters and return the target data to the user.

[0069] In one embodiment, the request information corresponding to the data query request also includes data output requirement information. This data output requirement information refers to the limiting information used to constrain data output to meet the data output requirements in the data query request. Optionally, the data output requirement information includes, but is not limited to, limitations on data output format and data output form. Data output formats include various output forms such as text, numbers, images, and sound, and data output formats include various output formats such as JSON, XML, CSV, TXT, and Excel. After obtaining the corresponding target data from the data server, the target data can be assembled and processed according to the data output requirement information and returned to the second terminal for display, thus meeting the data output requirements.

[0070] For example, if it is determined from the interface authorization information that the authorized verification object has data query permissions, the target data can be obtained based on the request query parameters.

[0071] In one embodiment, the interface authorization information indicates that the authorized verification object has data query permissions by satisfying at least one of the following conditions:

[0072] The request query parameters match the authorization query parameters, where the authorization query parameters are determined based on the authorization scope corresponding to the interface authorization information; and,

[0073] The authorization type of the authorization verification object under the requested interface is full authorization. The interface authorization information includes the authorization type of the authorization verification object under the requested interface.

[0074] The authorization scope is the data access boundary defined in the interface authorization information. It explicitly specifies the set of data that the authorized verification object is allowed to query under this interface. The authorization scope is usually represented by a set of parameters, namely the authorization query parameters. For example, for a request interface to query the list of store members, the authorization scope may specify that only member data of stores with store identifiers 1001, 1002, and 1003 can be queried. In this case, the authorization query parameters are store identifiers 1001, 1002, and 1003. The authorization query parameters are the specific expression of the authorization scope. They are parameter values ​​pre-set in the interface authorization information to limit the data access scope, defining the subset of data that the authorized verification object is allowed to access when passing the data query permission verification.

[0075] The authorization type refers to the type parameter that classifies the scope of data query access when accessing the request interface through the authorization verification object. It can be mainly divided into full authorization and partial authorization.

[0076] When determining whether an authorized object has data query permissions, this can be done by checking whether the request query parameters match the authorized query parameters. For example, after obtaining the interface authorization information, the interface authorization information can be parsed to determine the authorization scope corresponding to the interface authorization information. Then, the request query parameters carried in the data query request can be matched with the authorized query parameters in the authorization scope. If the match is successful, it is determined that the authorized object has data query permissions.

[0077] In one embodiment, if the requested query parameters are all identical to the authorized query parameters, or if the authorized query parameters contain the requested query parameters, then the match is determined to be successful, based on the authorization verification object having data query permissions.

[0078] In one embodiment, the interface authorization information may include an authorization verification object, data rule code, authorization type, data items, etc. The range of data items corresponding to the data items is the authorization range corresponding to the interface authorization information. Each data item is an authorization query parameter, and the data rule code corresponds to a business object. For example, if the data item range is [1001, 1002, 1003] and the data rule code is STORE-ID, then the authorization query parameters are store identifiers 1001, 1002, and 1003. If the requested query parameters are store identifiers "1001", "1002", "1003", "1001, 1002", "1002, 1003", or "1001, 1003", that is, the authorized query parameters contain the requested query parameters, or if the requested query parameters are store identifiers "1001, 1002, 1003", that is, the requested query parameters are all the same as or identical to the authorized query parameters, then it can be considered that the requested query parameters and the authorized query parameters match successfully, and the authorization verification object has data query permissions.

[0079] In another embodiment, if the request query parameters do not match the authorized query parameters, it indicates that the query scope specified by this data query request exceeds the data boundary that the authorized verification object is allowed to access, that is, unauthorized access has occurred. The subsequent processing flow of the current data query request can be terminated immediately, and a reminder message can be returned to the request initiator. For example, the reminder message can be an unauthorized access reminder to clarify that the request initiator has engaged in unauthorized access behavior and cannot access the data.

[0080] In addition to parameter matching for permission verification, it can also be determined by judging the authorization type of the authorized object under the requested interface. For example, after obtaining the interface authorization information, the authorization type of the authorized verification object under the requested interface can be determined from the interface authorization information. If the authorization type of the authorized verification object under the requested interface is full authorization, it means that the authorized verification object has complete and unrestricted access permissions to the requested interface. Under this type, it can be determined that the authorized verification object has data query permissions, and there is no need to further verify the specific authorization scope. That is, by default, the authorized verification object can access all accessible data under this interface.

[0081] In the above embodiments, the permission verification mechanism introduces a dual-path condition, including a fine-grained permission management mode, such as determining whether the authorized verification object has data query permissions by matching request query parameters with authorization query parameters, and a coarse-grained, efficient permission management mode, such as indicating that the authorized verification object has data query permissions when the authorization type of the authorized verification object under the request interface is full authorization. For most external objects, the fine-grained permission management mode can be used to achieve fine-grained and dynamic permission configuration, improving the granularity of permission management while achieving dynamic data isolation, effectively enhancing the security of data queries. For a few special cases, such as internal platform administrators and fully trusted partners, the coarse-grained, efficient permission management mode can simplify the management process and significantly reduce the computational overhead and response latency of permission verification.

[0082] In another embodiment, if the interface authorization information indicates that the authorized verification object does not have data query permissions, the subsequent processing flow of the current data query request can be terminated immediately, that is, the data query request is rejected, and a reminder message is returned to the request initiator. For example, the reminder message can be an access denial reminder to clarify that the request initiator cannot access the data due to insufficient permissions.

[0083] In the above data processing method, the authorization verification object is determined from the request information corresponding to the data query request. The interface authorization information corresponding to the authorization verification object under the request interface is obtained. The acquisition of the interface authorization information is jointly determined by the authorization verification object and the request interface. The authorization verification object can be used to clarify the restricted or constrained data query objects when querying data for a data query request. At the same time, it can clarify the restricted or constrained data query scope when accessing the request interface based on the data query request. Then, when the data query permission is clarified through the interface authorization information, the purpose of restricted access to the data maintained by each user is achieved. Finally, when the interface authorization information indicates that the user has data query permission, the target data is obtained based on the request query parameters, and the restricted access to the data is completed. In addition, by using the request interface and the authorization verification object in the request information as the dimensions for data query permission control, it is not necessary to define different roles for each user for permission control. This achieves the purpose of restricted access to the data maintained by each user, satisfying the permission control for access to massive user data.

[0084] In one embodiment, S204, obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request includes: obtaining the data rules determined by the request query information corresponding to the request interface; determining the interface authorization information of the authorization verification object under the request interface based on the data rules; wherein, the request query information includes request interface information and / or request query parameters.

[0085] Optionally, the request information includes the request query information.

[0086] The request interface information refers to the interface configuration information of the request interface corresponding to the data query request, which can be used to uniquely identify the request interface. The request interface information can include the interface identifier and interface parameters of the request interface. The interface identifier can be the interface code, interface name, and request interface path, etc., and the interface parameters can represent the business object to be queried by the request interface, that is, the interface query type. For example, interface A is used to query the list of store members, and interface B is used to query the list of store orders, etc.

[0087] For the purpose of understanding this embodiment, it is illustrated by taking an application to an open platform as an example.

[0088] It should be noted that, in combination Figure 4 As shown, initially, external developers "connect" external applications, the open platform, and the data server by configuring interface information on the open platform. These external developers are service personnel who configure interface information on the open platform to "connect" these connections. Later, external applications initiate data query requests, calling the interfaces configured by the external developers to invoke the open platform's routing interfaces. Upon receiving the data query request, the open platform obtains the corresponding request information, including at least one authorized verification object and request query parameters. It then obtains the data rules determined by the request query information corresponding to the request interface; based on the data rules, it determines the interface authorization information of the authorized verification object under the request interface. If the interface authorization information indicates that the authorized verification object has data query permissions, the target data is retrieved from the data server based on the request query parameters.

[0089] Optionally, the request information corresponding to the data query request also carries developer information. The developer information includes a developer information field and a developer information field. For example, a developer information field can be added to the request information corresponding to the data query request, so as to determine the developer identification information by obtaining the field content corresponding to the developer information field, in order to uniquely identify the developer.

[0090] Optionally, when configuring interface information on the open platform, developers can directly set the default content of the developer information field to developer identification information. For example, when developer 1 configures interface information on the open platform, such as configuring a request interface X for querying store product information, and initiates a data query request for querying store product information by calling request interface X, the data query request carries the developer information field OpenKey, with the default set content being OpenKey1, which is the developer identification information.

[0091] The data server may include at least one application, such as product A, product B, product C, etc. Each application is used to provide various data query request interfaces, such as store member query interface, regional member query interface, product information query interface, etc.

[0092] Optionally, the application can be software or a system platform that provides management services, such as: point-of-sale, inventory management, supply chain management, membership marketing, data analytics, mobile store operations, procurement and distribution, and other digital platform services covering the entire retail scenario and supply chain. Correspondingly, it can be understood that the application can provide data storage services, storing data such as merchant stores, product information within stores, and member information.

[0093] It should be noted that data rules are dynamic data mapping rules pre-configured for the request interface. For example, the request query information, data rules, authorization verification objects, and interface authorization information corresponding to the request interface can be pre-set.

[0094] Data rules reflect the business objects that a request interface is allowed to query at the interface level, as well as the range of data contained within those business objects. In the open platform, data rules can be used to unify data semantics to achieve parameter standardization. The open platform can assign a unique code within the platform to a core business object. For example, assigning a unique code STORE-ID to the store business object. Regardless of the object identifier used by different interface development objects within their internal interfaces, at the open platform level, all will be uniformly mapped to the STORE-ID rule. For instance, for the store business object, if the object identifier is storeIds in interface A and mdIds in interface B, then at the open platform level, the store business object will be uniformly mapped to the STORE-ID rule. When both interface A and interface B require store verification, operations personnel will configure data rule mappings for interface parameters for both interfaces simultaneously; that is, storeIds in interface A corresponds to STORE-ID, and mdIds in interface B corresponds to STORE-ID.

[0095] Optionally, a data rule may include a rule identifier, a data acquisition method, and a data item set. The rule identifier is a unique code used to identify the data rule within the open platform. The data acquisition method specifies the method for acquiring the corresponding data set under the data rule; for example, it may explicitly state that data is acquired in real-time by accessing a specific Hypertext Transfer Security Protocol (HTTPS) interface or a Uniform Resource Locator (URL). The data item set is a collection of data with the same attributes. Each independent unit in this set is called a data item. Taking a store as an example, the data item set under the data rule is a list of all stores of a specified merchant. Each specific store is a data item under this data rule. These data items provide the accurate contextual data range required for permission judgment and are directly used to determine the specific data range covered by the business object.

[0096] Optionally, when obtaining interface authorization information, the data rules corresponding to the request query information can be obtained based on the request query information corresponding to the data query request, and then the interface authorization information of the authorization verification object under the request interface can be determined based on the data rules.

[0097] For example, when obtaining interface authorization information, data rules can be determined by the request interface information and / or request query parameters corresponding to the request interface, and then the interface authorization information of the authorization verification object under the request interface can be determined based on the data rules.

[0098] In one embodiment, the open platform can directly obtain the data rule corresponding to the requested interface information based on the interface request information. For example, based on the storeIds of interface A, the data rule can be determined as STORE-ID. This approach is suitable for scenarios where the meaning of interface parameters is fixed and clear. The open platform can directly map the interface identity to the data rule, and the entire process is fast and accurate.

[0099] In one embodiment, the open platform can also directly obtain the corresponding data rules based on the request query parameters. For example, if the request query parameters are storeIds: [1001,1002,1004], then the data rule can be clearly defined as STORE-ID.

[0100] In one embodiment, if the queried data is more granular, the open platform needs to determine the corresponding data rules based on the request interface information and the request query parameters. For example, if a user requests to call interface C to obtain sales data through an application on a second terminal, and interface C can query by store or by region, the open platform also needs to determine whether the data to be queried is store sales data or region sales data based on the actual request query parameters passed in the data query request. This approach is suitable for scenarios with variable interface parameters. The open platform needs to analyze the actual query parameter values ​​passed in by the user and dynamically determine which data rules to use based on the request interface information.

[0101] Assume that the open platform stores the relationships between authorization verification objects, request interfaces, data rules, and interface authorization information. The authorization verification objects include at least one of external developers, merchants (i.e., data providers), and the request initiating platform. For example, the request interface information includes the request interface path and / or interface query type. The authorization scope determined by the interface authorization information is represented by the data query authorization scope, where the numbers in the data query authorization scope are store identifiers. The relationships can be shown in Table 2 below:

[0102]

[0103] Table 2

[0104] It should be noted that in a practical application scenario, a data query request is initiated by a request-initiating platform (e.g., platform 1). Assuming the data query request is for retrieving store product information with storeIds [1001, 1002, 2001], the open platform receives the data query request. If the authorized verification object is determined to be developer 1, and the developer information OpenKey is OpenKey1, the platform determines the interface query type based on the request interface and the data rule based on the corresponding request query information. For example, if the request query information is the request query parameter storeIds, and it is determined that the request query parameter storeIds is bound to the data rule STOREID-1, the platform determines the data rule based on the data rule STOREID-1. The interface authorization information of Developer 1 under the request interface, that is, the data query authorization range is {1001, 1002, 1003, 2001, 2002, 2003}, indicates that based on the data rule STOREID-1, Developer 1 has the data query permission for store product information of stores 1001, 1002, 1003, 2001, 2002, and 2003. Based on the request query parameter storeIds being [1001, 1002, 2001], which matches the data query authorization range {1001, 1002, 1003, 2001, 2002, 2003}, it indicates that the authorization verification object carried in the data query request (i.e., Developer 1) has passed the data query permission verification or validation and can query the store product information of stores 1001, 1002, and 2001.

[0105] It should be noted that if the authorization verification object is determined to be the request initiating platform, the same principle applies as if the authorization verification object is determined to be the developer, and will not be elaborated further here.

[0106] It should be noted that in practical applications, at least one application included in the data server may have different interface identifiers for the same data query request, due to the different R&D companies, R&D teams, and even R&D personnel involved. Without unified management of the interface identifiers for request interfaces, these interfaces are highly likely to be different across applications. For example, in product A, the interface identifier for store product information query interface 1 is "selectProductList," corresponding to request interface path 1; while in product B, the interface identifier for store product information query interface 3 is "Product-Li," corresponding to request interface path 3.

[0107] Therefore, the above practical application scenario can be applied when the interface query types of the request interfaces are the same. The same data rules can be bound to the request query information (such as request query parameters and / or request interface information) corresponding to the request interfaces. For at least one request interface with the same interface query type, all authorized query parameters with data query permissions under at least one request interface based on the authorization verification object can be summarized. Among them, the interface query types corresponding to at least one request interface are the same.

[0108] For example, in the above example, the interface query type is store product information. When a data query request for store product information is triggered on the request initiating platform (Platform 1), the request query parameters can be matched with all authorized query parameters. If each data item in the request query parameters matches a data item in each of the authorized query parameters, then store product information can be obtained based on the request query parameters. This obtained store product information can then be used to add products to the shopping cart. This is suitable for users who have a need to purchase products.

[0109] It can also be used for inventory checks and verification of whether the information on displayed and sold products matches the inventory information. In this case, it is suitable for store staff to conduct inventory checks, etc., and there are no restrictions on this.

[0110] Optionally, if a data query request is initiated through a request initiating platform (such as platform 1), and the data query request is a request to query the store product information storeIds of [1001, 1002, 1004], and the authorized verification object is determined to be developer 1, the request query parameter storeIds of [1001, 1002, 1004] does not match the data query authorization range {1001, 1002, 1003, 2001, 2002, 2003}, indicating that the authorized verification object carried by the data query request (i.e., developer 1) has not passed the data query permission verification or validation, and cannot query the store product information of stores with store Ids of 1001, 1002, and 1004.

[0111] Optionally, if a data query request is initiated through a request initiating platform (such as platform 1), and the data query request is a request to query the store product information storeIds of [1001, 1002, 1004], and the authorized verification object is determined to be developer 1, the request query parameter storeIds of [1001, 1002, 1004] partially matches the data query authorization range {1001, 1002, 1003, 2001, 2002, 2003}. The partial matching result is: the match includes 1001 and 1002, and the non-match is 1004. This indicates that the authorized verification object carried by the data query request (i.e., developer 1) has passed the data query permission verification or validation and can query the store product information of stores 1001 and 1002, but has not passed the data query permission verification for querying the store product information of store 1004.

[0112] As an optional implementation, request interfaces with similar query types can be bound to the same data rules. Here, "similar query types" refers to request interfaces within the same business domain that have similar data query logic.

[0113] Referring to Table 2, in a practical application scenario, request interfaces querying store product information and store order information can be considered to have similar query types. Therefore, the data rules for querying store product information and store order information can be set to the same data rule, for example, both STOREID-1 and STOREID-2 can be set to the data rule STOREID. It is understandable that since querying store product information and store order information both involve data queries related to the store business domain, and the request interfaces corresponding to store product information and store order information have similar data query logic, they can be considered to have similar query types.

[0114] In this practical application scenario, when the query types of request interfaces are similar, the same data rules can be bound to the request query information (such as request query parameters and / or request interface information) corresponding to the request interfaces. This allows for the aggregation of all authorized query parameters that have data query permissions under at least one request interface based on the authorization verification object, where the query types of at least one request interface are similar.

[0115] As an optional implementation, this embodiment can be applied to membership marketing scenarios. Taking membership marketing as an example, marketing companies sometimes need to conduct marketing to members in different regions. For example, they may want to push messages to members corresponding to all merchants in a certain region. They can obtain data through the open platform to get the member information corresponding to all merchants in the region. At this time, they can reduce the possibility of data overreach by authorizing the designated developer to have data permissions in the regional data rules.

[0116] In a specific example, a data query request is initiated through the request initiation platform. Assume the data query request is to query the list of store members for merchant 1001 in region A. The open platform receives the data query request and determines that the corresponding request information includes authorization verification objects such as developer information and the merchant. The request query parameter `cityCodes` is [region A]. The request interface information can be the request interface path and / or interface query type. At this point, it can be determined whether the request query parameter `cityCodes` is bound to a data rule. If the data rule corresponding to the request query parameter can be obtained, it indicates that `cityCodes` is bound to a data rule. Based on the data rule, the authorization verification objects are determined, namely the developer information and the merchant's interface authorization information under the request interface. If the determined interface authorization information corresponds to the authorization scope of [region A, region B], it indicates that the authorized query parameter includes the store member list information corresponding to region A and region B respectively. In this case, the request query parameter `cityCodes` of [region A] matches the region A in the authorized query parameter, confirming successful permission verification. The data query request can then be forwarded to the target service object to perform the data query.

[0117] In a specific example, if no specified merchant identifier is passed, the data query request is to query the member list corresponding to all merchants in region B. Upon receiving the data query request, the open platform determines that the corresponding request information includes an authorization verification object such as developer information, and the request query parameter `cityCodes` is [region B]. The request interface information can be the request interface path and / or interface query type. At this point, it can be determined whether the request query parameter `cityCodes` is bound to a data rule. If the data rule corresponding to the request query parameter can be obtained, it indicates that `cityCodes` is bound to a data rule. Based on the data rule, the authorization verification object is determined, i.e., the interface authorization information of the developer information under the request interface. If the authorization scope corresponding to the interface authorization information is determined to be [region A, region B], it indicates that the authorized query parameter includes the store member list information corresponding to regions A and B respectively. In this case, the request query parameter `cityCodes` of [region B] matches the region B in the authorized query parameter, confirming successful permission verification. The data query request can then be forwarded to the target service object to perform the data query.

[0118] As an optional implementation method, this embodiment can be applied to the scenario of selling goods. Some offline supermarkets, due to their lack of R&D capabilities, can cooperate with companies with development capabilities when they need to do online promotion. For example, they can upload product promotion information to multiple well-known applications through an open platform. At this time, they can authorize designated developers to query data of different product categories to reduce the risk of data overreach.

[0119] In a specific example, a data query request is initiated through the request initiation platform. Assume the data query request is for seafood products from merchant 1001. Upon receiving the data query request, the open platform determines that the corresponding request information includes authorization verification objects such as developer information and the merchant. The request query parameter `goodsTypes` is "[Seafood]", and the request interface information can be the request interface path and / or interface query type. At this point, it can be determined whether the request query parameter `goodsTypes` is bound to a data rule. If the data rule corresponding to the request query parameter can be obtained, it indicates that `goodsTypes` is bound to a data rule. Based on the data rule, the authorization verification objects are then determined, namely the developer information and the merchant's interface authorization information under the request interface. If the determined interface authorization information corresponds to the authorization scope of "[Snacks, Seafood]", it indicates that the authorized query parameters include product information corresponding to both snacks and seafood. In this case, the request query parameter `goodsTypes` of "[Seafood]" matches the "Seafood" in the authorized query parameters, confirming successful permission verification. The data query request can then be forwarded to the target service object to perform the data query.

[0120] In a specific example, a data query request is to view the cat food product information for all merchants. The open platform receives the data query request and determines that the corresponding request information includes an authorization verification object such as developer information, and the request query parameter `goodsTypes` is "[cat food]". The request interface information can be the request interface path and / or interface query type. At this point, it can be determined whether the request query parameter `goodsTypes` is bound to a data rule. If the data rule corresponding to the request query parameter can be obtained, it indicates that `goodsTypes` is bound to a data rule. Based on the data rule, the authorization verification object is determined, which is the interface authorization information of the developer information under the request interface. If the authorization scope corresponding to the interface authorization information is determined to be "[cat food, snacks]", it indicates that the authorized query parameter includes the product information corresponding to the cat food category and the snack category respectively. In this case, the request query parameter `goodsTypes` of "[cat food]" matches the cat food in the authorized query parameter, confirming that its permission verification is successful. The data query request can then be forwarded to the target service object to perform the data query.

[0121] Optionally, the interface authorization information of the authorized verification object under the request interface is determined based on data rules. The interface authorization information determined for different data rules and / or different authorized verification objects under the request interface can be the same or different. In practical applications, the interface authorization information under the request interface can be set according to different data rules and / or different authorized verification objects, adapting to specific application scenario requirements, to meet the data access permission control needs of different application scenarios.

[0122] It should be noted that the above-listed application scenarios are only for the purpose of understanding the embodiments described in this embodiment. The scope of protection of this embodiment is not limited to the application scenarios mentioned above. In actual application, it can be adapted to the specific application scenario requirements. Based on different data rules and / or different authorization verification objects, interface authorization information can be set under the request interface to meet the permission control requirements for data access in different application scenarios.

[0123] Therefore, in this embodiment, by establishing a mapping relationship between request query information (i.e., request interface information and / or request query parameters) and data rules, unified or identical data rules can be set for different request query information, so that all subsequent verification logic is based on unified data rules, achieving complete reuse of permission verification logic. Different data rules can be set for different request query information to meet the permission control requirements for data access in different application scenarios.

[0124] Meanwhile, different data query types within the same product line, such as store member lists and store order lists, essentially involve data access isolated by store. Setting independent permission verification rules for each query type can easily lead to rule redundancy, impacting management efficiency. In this embodiment, interfaces for different query types can be bound to the same data rule, effectively reducing permission management and rule development costs. When store data or authorization policies change, only the definition of one data rule needs to be modified, and all bound interfaces will take effect simultaneously, improving the consistency of the global permission management strategy.

[0125] In one embodiment, the data processing method may further include: determining the query authorization status of the authorization verification object under the request interface; if the query authorization status is authorized, then performing the step of obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request.

[0126] The query authorization status is used to characterize whether the object being verified has the permission to query data through the request interface. This authorization status can include both authorized and unauthorized states. If the query authorization status is authorized, it means that the object being verified has obtained data query authorization under the request interface corresponding to the data query request, and can therefore access the request interface to query data, allowing for more granular permission verification processes to proceed.

[0127] Optionally, when performing permission verification, the query authorization status of the authorization verification object under the request interface can be determined first. If the query authorization status is authorized, the step of obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request is executed.

[0128] In one embodiment, to determine the query authorization status of the authorization verification object under the request interface, the authorization status information recorded for the request interface can be obtained. The authorization status information includes the authorization status corresponding to each authorization verification object under the request interface. The target authorization status information that matches the authorization verification object carried in the data query request is queried in the authorization status information. If the target authorization status information is an authorized status, the step of obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request is executed.

[0129] It is understandable that if no target authorization status information matching the authorization verification object is found in the authorization status information, it means that the authorization verification object is in an unauthorized state under the requested interface.

[0130] Optionally, the authorization status information includes the authorization status of each authorization verification object under the request interface. The authorization status of each authorization verification object under the request interface can be determined by setting a corresponding authorization status identifier. Specifically, it can be determined by the authorization status identifier value corresponding to the authorization status identifier of each authorization verification object. When the authorization status identifier value is the same as the preset identifier value, it indicates that the query authorization status of the authorization verification object under the request interface is authorized, indicating that the authorization verification object has the permission to query data through the request interface. When the authorization status identifier value is different from the preset identifier value, it indicates that the query authorization status of the authorization verification object under the request interface is unauthorized, indicating that the authorization verification object does not have the permission to query data through the request interface.

[0131] Optionally, the preset flag value can be set to a non-zero value.

[0132] Optionally, when the authorization verification object includes at least two items, the authorization status of each authorization verification object under the request interface can be determined independently, and then the overall query authorization status can be determined comprehensively. For example, for each authorization verification object, the authorization status identifier value corresponding to that authorization verification object under the current request interface can be found from the authorization status information, and the query authorization status of that authorization verification object under the request interface can be determined based on the authorization status identifier value. If the authorization status of all authorization verification objects under the request interface is authorized, then the overall authorization verification object is determined to have the permission to query data through the request interface. If any authorization verification object has an unauthorized authorization status under the request interface, then the overall authorization verification object is determined not to have the permission to query data through the request interface.

[0133] For example, assuming the authorization verification objects include developers and merchants, the first authorization status identifier value of the developer under the current requested interface and the second authorization status identifier value of the merchant under the current interface can be retrieved from the authorization status information. If both the first and second authorization status identifier values ​​are the same as the preset identifier values, it is determined that the authorization verification object has the permission to query data through the requested interface. If the first and / or second authorization status identifier values ​​are different from the preset identifier values, it is determined that the authorization verification object does not have the permission to query data through the requested interface.

[0134] In another embodiment, if the query authorization status is unauthorized, it means that the authorization verification object carried by the data query request has not obtained data query authorization under the request interface corresponding to the data query request. That is, accessing the request interface through the authorization verification object does not have data query permission and cannot query data. The data query request is an illegal request initiated by an unauthorized request initiator (such as an external attacker). The subsequent processing flow of the current data query request can be terminated immediately, and a reminder message can be returned to the request initiator. For example, the reminder message can be an access denial reminder to inform the request initiator that it cannot access the data due to insufficient permissions.

[0135] In the above embodiments, before obtaining interface authorization information, it is first determined whether the authorization verification object carried by the data query request has the data query permission to access the request interface and then perform the data query. Only when it is confirmed that the authorization verification object has the data query permission to access the request interface and then perform the data query will subsequent more granular permission verification steps be performed. This can quickly intercept a large number of invalid or malicious requests, effectively reduce the resource load generated in the permission verification stage of the data query process, and significantly optimize platform performance and resource utilization while ensuring security.

[0136] In one embodiment, the interface authorization information includes the authorization type of the authorization verification object under the requested interface. The data processing method may further include: if the authorization type of the authorization verification object under the requested interface is full authorization, it indicates that the authorization verification object has data query permissions. If the authorization type of the authorization verification object under the requested interface is partial authorization, the authorization scope corresponding to the interface authorization information is determined. When the interface authorization information indicates that the authorization verification object has data query permissions, the step of obtaining the target data based on the request query parameters is executed, after matching the request query parameters with the authorization query parameters in the authorization scope.

[0137] Among them, the authorization type refers to the type parameter that classifies the scope of data query access when accessing the request interface through the authorization verification object. It can be mainly divided into full authorization and partial authorization.

[0138] The authorization type is "full authorization," which means that the authorized verification object has complete and unrestricted access rights to the requested interface. Under this type, there is no need to further verify the specific authorization scope. That is, by default, when accessing the requested interface through the authorized verification object, all data can be queried. For example, if the data query request is to query store member data, and the authorization type of the authorized verification object under the requested interface is "full authorization," then all store member data can be queried.

[0139] In this context, "partial authorization" indicates that the access rights of the authorization verification object to the requested interface are limited. That is, when accessing the requested interface through the authorization verification object, only the data under the authorized query scope can be queried. The specific range of queried data needs to be further defined and limited by the data query authorization range. For example, if the data query request is to query store member data, and the authorization type of the authorization verification object under the requested interface is partial authorization, assuming the data query authorization range corresponding to accessing the requested interface through the authorization verification object is [1001, 1002, 1004], it means that only some store member data can be queried, such as the store member data corresponding to stores 1001, 1002, and 1004 respectively.

[0140] In one embodiment, partial authorization can be further subdivided into specific data item authorization, range authorization, and logical judgment authorization. Specific data item authorization, for example, authorizes only a single store or a single user for an authorization verification object. Centralized data item authorization refers to granting access to multiple items in a dataset through an authorization verification object, such as a list of multiple store identifiers. Range authorization is typically used for numerical or time ranges, such as allowing access to data within a certain time period or orders within a certain price range. Logical judgment authorization involves equality and inequality logic checks and can be used for more complex conditional authorization, such as allowing access to all data except for specific items.

[0141] Optionally, after obtaining the interface authorization information of the authorized verification object under the request interface corresponding to the data query request, the authorization type of the authorized verification object under the request interface can be determined from the interface authorization information. If the authorization type of the authorized verification object under the request interface is full authorization, it indicates that the authorized verification object has data query permissions. If the authorization type of the authorized verification object under the request interface is partial authorization, the authorization scope corresponding to the interface authorization information is determined. When the request query parameters are matched with the authorization query parameters in the authorization scope, and it is clear that the interface authorization information indicates that the authorized verification object has data query permissions, the step of obtaining the target data based on the request query parameters is executed.

[0142] In the above embodiments, a hierarchical permission verification strategy is introduced by setting authorization types for authorization verification objects. For high-trust objects, a full authorization type can be configured for them to enable rapid data query access, reduce unnecessary range calculation overhead, and improve data processing efficiency. For example, when it is necessary to authorize thousands of stores of a merchant, the merchant can directly grant full authorization to the authorization verification object and update the authorization type of the authorization verification object under the corresponding interface to full authorization, without having to store thousands of permission records.

[0143] For objects with ordinary trust levels, a complete and granular verification process will be initiated to ensure that their operations are restricted by checking the scope of authorization, thus ensuring data security and isolation. This hierarchical permission verification strategy flexibly configures different levels of permissions for different objects, achieving a balance between security and efficiency and meeting diverse business authorization needs.

[0144] In one embodiment, the data processing method further includes: in response to an authorization operation on the authorization verification object under the requested interface, obtaining authorization information for the authorization verification object; and determining the interface authorization information of the authorization verification object under the requested interface based on the authorization information.

[0145] It should be noted that the authorization operation refers to the instructions related to authorizing the object to be authorized.

[0146] Optionally, the authorization operations include, but are not limited to, authorization change operations, authorization request operations, and authorization confirmation operations. Specifically, the authorization change operation is used to modify or adjust the interface authorization information of the authorization verification object under the requested interface. The authorization request operation is used to request interface authorization information for the authorization verification object under the requested interface. The authorization confirmation operation is used to confirm the interface authorization information of the authorization verification object under the requested interface after an authorization request operation or authorization change operation for the authorization verification object under the requested interface.

[0147] Optionally, modifying or adjusting the interface authorization information can be done by adding, deleting, or replacing at least one of the authorization items in the interface authorization information.

[0148] As an optional implementation, when the authorization operation is an authorization request operation or an authorization change operation, in response to the authorization operation for the authorization verification object under the request interface, the authorization information for the authorization verification object is obtained, and when the authorization confirmation operation for the authorization verification object is received, the interface authorization information of the authorization verification object under the request interface is determined according to the authorization information.

[0149] In this embodiment, by introducing an authorization confirmation operation as a pre-processing step before the authorization takes effect, erroneous authorizations caused by accidental clicks or insufficient review can be effectively prevented. This ensures that each authorization request or authorization change operation requires double confirmation. Only after double confirmation will the received authorization information be updated based on the authorization information obtained through the authorization request or authorization change operation, thereby improving the security and reliability of permission changes.

[0150] Optionally, upon receiving an authorization denial operation for an authorization verification object, the current authorization process can be terminated, while preserving the original authorization information of the authorization verification object under the corresponding request interface.

[0151] Optionally, when the authorization operation is an authorization request operation, if the authorization information for the authorization verification object determined based on the authorization request operation is the authorization request information, then determining the interface authorization information of the authorization verification object under the request interface based on the authorization information includes: determining the authorization request information as the interface authorization information of the authorization verification object under the request interface.

[0152] The authorization request operation is a management action used to obtain access permissions for a specific authorization verification object under a specific request interface.

[0153] Optionally, if the received authorization operation is identified as an authorization request operation, the authorization information parsed from this operation can be explicitly classified as authorization request information, and the permission content described in the authorization request information can be directly converted and stored as formal interface authorization information. This direct conversion avoids the complex conversion and redefinition between the request information and the final permission configuration, improving the accuracy of the interface authorization information.

[0154] For example, an authorization request is a management action used by a product category application to obtain access permissions under the store display information query interface. The permission content described in the authorization request information may include the display data of merchant A's stores in region B. After recognizing and receiving the above authorization request operation, the permission content described in the authorization request information, such as the display data of merchant A's stores in region B, can be directly converted and stored as interface authorization information.

[0155] Optionally, when the authorization operation is an authorization change operation, if the authorization information for the authorization verification object determined based on the authorization change operation is authorization adjustment information, then determining the interface authorization information of the authorization verification object under the request interface based on the authorization information includes: updating the interface authorization information of the authorization verification object under the request interface according to the authorization adjustment information.

[0156] The authorization change operation is a management action used to modify the access permissions of the authorized verification object under the requested interface. The authorization adjustment information is parsed from the authorization change operation and is information data used to describe the specific content of the permission modification. The authorization adjustment information can clarify how the permission needs to be adjusted, such as adding authorization items, deleting authorization items, or replacing the entire authorization scope.

[0157] Understandably, authorization change operations can be initiated against the authorization verification object. Taking the data server storing merchant business data as an example, the authorization change operation can be initiated by the merchant against the authorization verification object. For example, due to the change of the business model of its own stores, the merchant needs to change the interface authorization information of the corresponding external developer under interface A. The original authorization scope corresponding to the received authorization information is stores: [1001, 1002, 1003]. Since store 1002 has changed its business model to internal direct operation, it initiates an authorization change operation against the external developer and inputs the authorization adjustment information, specifically stores: [1001, 1003]. The open platform responds to the authorization change operation against the external developer under interface A, obtains the authorization adjustment information, and when it receives the authorization confirmation operation against the external developer, it updates the interface authorization information according to the authorization adjustment information. The updated interface authorization information is: stores: [1001, 1003].

[0158] As an optional implementation, when the authorization operation is an authorization confirmation operation, in response to the authorization confirmation operation for the authorization verification object under the request interface, the authorization information for the authorization verification object is obtained, and the interface authorization information of the authorization verification object under the request interface is determined based on the authorization information.

[0159] Among them, obtaining the authorization information for the authorization verification object can be based on the authorization application operation and / or the authorization change operation to determine the authorization information for the authorization verification object.

[0160] The authorization confirmation operation refers to the final approval and confirmation action performed by the authorization administrator on the content recorded in the authorization information after the authorization operation, such as clicking the "Confirm Authorization" button or entering a secondary verification code.

[0161] For example, after obtaining the authorization information for the authorization verification object in response to the authorization operation on the request interface, the authorization manager needs to make a final confirmation of the authorization information. Only after receiving the authorization confirmation operation for the authorization verification object can the interface authorization information of the authorization verification object under the request interface be determined based on the authorization information.

[0162] In this embodiment, by introducing an authorization confirmation operation as a pre-processing step before the authorization takes effect, erroneous authorizations caused by accidental clicks or insufficient review can be effectively prevented. This ensures that each authorization request or authorization change operation requires double confirmation. Only after double confirmation will the received authorization information be updated based on the authorization information obtained through the authorization request or authorization change operation, thereby improving the security and reliability of permission changes.

[0163] Similarly, when the authorization operation is an authorization confirmation operation, the authorization information for the authorization verification object can be obtained first. In response to the authorization confirmation operation for the authorization verification object under the request interface, the interface authorization information of the authorization verification object under the request interface can be determined according to the authorization information. The specific steps are the same as those in the above embodiment where the authorization operation is an authorization confirmation operation, and will not be repeated here.

[0164] In the above embodiments, when the expected scope of authorization for the authorized verification object changes for the permission administrator, the open platform can open an authorization information adjustment window for the permission administrator. This allows the interface authorization information stored in the open platform to be updated and synchronized in a timely manner according to the actual permission management needs of the permission administrator, effectively improving the accuracy and real-time performance of permission management and reducing security risks or business blockages caused by delayed permission management.

[0165] In one embodiment, the data query request is generated by signing the request information based on an encryption key. For example... Figure 3 As shown in step S201, a data query request is received, and the request information corresponding to the data query request is obtained, including:

[0166] S302, Received a data query request and obtained the decryption key that matches the data query request.

[0167] Among them, the data query request is a request generated by signing the request information with an encryption key.

[0168] A decryption key is used to sign and decrypt the encrypted data query request. The key can be a confidential string or algorithm parameters. By using the decryption key to sign and decrypt the data query request, the open platform can obtain the plaintext information of the data query request and the corresponding signature timestamp. Understandably, the decryption key is assigned and bound by the open platform to each external application or application service.

[0169] In one embodiment, when an external developer registers the corresponding application or application service on the open platform, the open platform will set up or the two parties will negotiate to generate a corresponding key pair, which includes an encryption key and a decryption key.

[0170] Optionally, when the second terminal sends a data query request to the open platform, it creates a structured request data packet based on the request information. This request data packet is then digitally encrypted using an encryption key to obtain the encrypted data query request. The encrypted data query request is subsequently sent to the open platform's request interface address. Upon receiving the data query request, the open platform can obtain the decryption key that matches the data query request.

[0171] In one embodiment, the decryption key matching the data query request can be determined based on the application identifier of the application or application service that sent the data query request.

[0172] In one embodiment, when an application or application service on the second terminal transmits a data query request, it can use its own key to sign the request using a JSON Web Token (JWT) to obtain an encrypted data query request.

[0173] In a specific example, an application initiates a data query request to retrieve store member data. The application will then call the pre-connected store member list interface, i.e., Interface A, to access the open platform to obtain data. The parameters passed by the application when calling Interface A are: storeIds: [1001, 1002], the requested interface path, and openkey: kaifazheA. Subsequently, a JWT will be used to sign the request with the application's own key, generating an encrypted request to the open platform for the interface call.

[0174] S304. Use the decryption key to sign and decrypt the data query request to obtain the signature timestamp.

[0175] The signature decryption is an authentication and data integrity verification action. The open platform uses the decryption key to decrypt the digital signature part of the data query request, which can obtain the plaintext of the request parameters of the data query request and the signature timestamp.

[0176] Among them, the signature timestamp is a precise time stamp embedded in the signature data when the digital signature is generated. It records the specific time when the data query request was initiated and is a key security element used to prevent replay attacks.

[0177] Optionally, after obtaining the decryption key, the decryption key matching the data query request can be used to sign and decrypt the data query request to obtain a signature timestamp.

[0178] S306: If the signature timestamp is within a valid time range, determine that the validity period verification of the data query request is successful, and extract the request information corresponding to the data query request.

[0179] The valid time range is a pre-defined time interval used to determine whether the signature timestamp is valid. It is usually based on the current platform time and an acceptable offset is set to obtain the valid time range. For example, the signature timestamp should not differ from the platform time of the open platform by more than 5 minutes. Timestamps that exceed this range can be considered invalid timestamps.

[0180] Optionally, after obtaining the signature timestamp, the valid time range can be determined based on the current platform time. Then, the signature timestamp is compared with the valid time range. If the signature timestamp is within the valid time range, it can be determined that the data query request has passed the timeliness verification and the validity period verification of the data query request has been successful. The open platform can then extract the request information corresponding to the data query request.

[0181] In a specific example, an application initiates a data query request to retrieve store member data. The application will call the pre-connected store member list interface, i.e., Interface A, to access the open platform to obtain data. The parameters passed by the application when calling Interface A are: storeIds: [1001, 1002], the request interface path, and openkey: kaifazheA. Subsequently, it uses JWT to sign the request with its own key, generating an encrypted request to the open platform for interface calling. After receiving the encrypted request, the open platform can decrypt the signature using the developer's key to obtain a signature timestamp. Then, it performs a signature validity period verification based on the timestamp. If the validity period verification passes, it uses the plaintext request parameters for subsequent permission verification operations. The plaintext request parameters are openkey: kaifazheA, storeIds: [1001, 1002].

[0182] In the above embodiments, by signing and decrypting the data query request with the decryption key, it can be confirmed that the data query request has not been tampered with. By verifying the timestamp, expired or replayed old requests can be effectively intercepted. Only when both verifications are successful will reliable request information be extracted, providing a real and complete data foundation for subsequent permission verification and data acquisition processes, and reducing the risk of data overreach and security due to request forgery, tampering or replay.

[0183] In one embodiment, S206, if the interface authorization information indicates that the authorization verification object has data query permission, then the target data is obtained based on the request query parameters, including: if the interface authorization information indicates that the authorization verification object has data query permission, then the data query request is forwarded to the target service object, and the target data queried by the target service object based on the request query parameters in the data query request is received.

[0184] The target service object is responsible for executing specific data query logic and accessing the data server to retrieve target data based on the query parameters. For example, the target service object can be a data retrieval interface, which allows the user to obtain the corresponding data from the data server. Alternatively, the target service object can be an application or product that actually stores the target data; by forwarding the data query request to the application or product, the application or product can retrieve the target data from the data server based on the query parameters.

[0185] Optionally, the data server may integrate at least one application, each application being used to provide request interfaces for various data query requests to the outside world. In this case, the target server object is the request interface for various data query requests provided by each application, such as store member query interface, regional member query interface, product information query interface, etc.

[0186] Optionally, the data server may integrate at least one application that is user-facing. For example, the user may be a merchant, and the application may be software or a platform that is merchant-facing and serves the merchant, providing management services such as cashier, inventory management, supply chain management, membership marketing, data analysis, mobile store management, procurement and distribution, and other digital platforms covering the entire retail scenario and the entire supply chain.

[0187] For example, the application can provide data storage services to users, such as users being data providers or merchants, and storing data such as merchant stores, product information under the stores, and member information.

[0188] Optionally, an application can integrate services such as POS, inventory management, supply chain, membership marketing, data analysis, mobile store operations, procurement and distribution, and other digital platform services across the entire retail scenario and supply chain. These services can be integrated into one application or managed by at least two separate applications. There are no restrictions on this.

[0189] Optionally, the application can be an ERP (Enterprise Resource Planning) system, which is an integrated enterprise management software system. It is understood that an ERP system can be in SaaS form or as standalone software deployed locally.

[0190] Alternatively, by forwarding the data query request to the corresponding target service object, the target service object will execute specific data query logic according to the request query parameters in the data query request and obtain the target data from the data server.

[0191] In one embodiment, the open platform can send a data query request to the corresponding data acquisition interface, and call the data acquisition interface to obtain the target data from the data server according to the request query parameters.

[0192] In the above embodiments, by setting a target service object and having the target service object actually perform the data query operation to obtain the corresponding target data from the data server, the permission verification process and the data processing process can be separated, achieving efficient decoupling of security control and task execution, and greatly improving the security and efficiency of the data processing process.

[0193] In one embodiment, a data processing method is provided, which is applied to, for example... Figure 4 The data processing system shown can include an open platform, external applications, and a data server. External applications can be application services, websites, mini-programs, etc. The data server stores business data corresponding to different business products. Different business products can be different applications, which provide data storage services to users, such as merchants. Different applications will have different product open interfaces for querying stored data. The open platform can include a merchant client, an operations client, and a routing client. The merchant client interacts with merchants to implement merchant authorization management functions. The operations client interacts with internal development and operations personnel to implement interface development, deployment, and configuration functions. The routing client is responsible for communicating with external applications and the data server to implement specific permission verification and data processing tasks. External developers are service personnel who "connect" external applications, the open platform, and the data server by configuring interface information on the open platform.

[0194] Optionally, the interaction sequence diagram of the internal interaction process of the data processing system can be as follows: Figure 5 As shown, firstly, the operations staff within the open platform can develop and deploy interfaces for merchants. Taking interfaces A and B as an example, interface A is used to retrieve the store member list. The first request parameters of interface A include the merchant ID: shopAdminId, and the set of store IDs: storeIds. These two request parameters are used to restrict the interface validation object to access only members of specific stores of specific merchants. Interface B is another interface provided by the operations staff, used to query the store order list. The second request parameter of interface B also includes the set of store IDs: mdIds. In addition, both interfaces A and B are unified format interfaces exposed by the open platform, with unified interface specifications. Each interface also records the data access interface actually provided by the corresponding business party of the product.

[0195] In practical applications, an open platform can interface with at least one application. However, since different applications may be developed by different companies, or even different development teams or personnel within the same company, there is no unified management of the interface information for each data query type. This leads to inconsistencies in the interface information for the same data query type across different applications. Furthermore, since the interfaces within the open platform may be developed and deployed by different operations personnel, the request interface parameters for the same business object may differ across interfaces. For example, in interface A, the store identifier might be `storeIds`, while in interface B, it might be `mdIds`. The correspondence between interfaces and request interface parameters is shown in the table below:

[0196]

[0197] Before deploying an API, operations staff configure corresponding data rules for the request API parameters. For example, they might need to configure store data rules for APIs A and B. The data rule code is STORE-ID, and the data retrieval method is an HTTPS API. Once this data rule is configured in the operations backend, a list of all stores for a specified merchant can be viewed, and each specific store can be considered a data item under the data rule. For example, store data rules can be shown in the table below:

[0198] Data item key Data item value 1001 Store 1 1002 Store 2 1003 Store 3 … …

[0199] Understandably, the data rule's list of data items can be configured in multiple ways, such as obtaining data via HTTPS URLs to solve the real-time data acquisition problem. It also supports dynamically importing JSON format data and manually adding data, as well as storing data in the open platform's permission library and refreshing it periodically with a timer.

[0200] When both API A and API B require store verification, the operations team will configure data rule mappings for the request parameters of both API A and API B, specifically `storeIds-STORE-ID` for API A and `mdIds-STORE-ID` for API B. The mapping relationship is shown in the table below:

[0201] Interface Interface parameter Data rule Interface A: Get store member list interface storeIds STORE-ID Interface B: Query store order list interface mdIds STORE-ID

[0202] If external developers want to access a merchant's data, they need to apply for authorization from the merchant. After authorization is granted, the open platform will maintain authorization information corresponding to each authorization verification object. For example, authorization verification objects can include merchants, external applications, external developers, interface query types, interface data rules, etc.

[0203] Users can generate data query requests through external applications. These external applications then call pre-defined interfaces to invoke the open platform's routing interface. Upon receiving the data query request, the open platform performs permission and security checks on at least one authorized verification object corresponding to the request. If any permission or security check fails, the data query request is intercepted. If all permission and security checks pass, the platform calls the product's open interface provided on the data server by each business product to retrieve the target data requested in the query, assembles the target data, and returns it to the external application. The external application then displays the target data to the user, completing the data query.

[0204] like Figure 6 As shown, the specific steps of the data processing method are as follows:

[0205] S601, upon receiving a data query request, obtains the decryption key that matches the data query request.

[0206] The decryption key can be a key bound to an external developer. The data query request is generated by signing the request information based on the encryption key.

[0207] S602, use the decryption key to sign and decrypt the data query request to obtain the signature timestamp and the plaintext of the request parameters.

[0208] S603, determine whether the signature timestamp is within the valid time range. If not, execute S604; if yes, execute S605.

[0209] S604: End the data query request and generate a prompt message to send to the external application.

[0210] S605 extracts the authorization verification object and request parameters from the plaintext of the request parameters.

[0211] The plaintext request parameters can include the authorization verification object and the request query parameters. For example, the plaintext request parameters can be represented as ("openkey": kaifazheA, "storeIds": 1001, 1002), where the authorization verification object is developer A, and the request parameters are merchant IDs: 1001, 1002.

[0212] S606, Determine the query authorization status of the authorized verification object under the corresponding request interface of the data query request.

[0213] S607, determine whether the query authorization status is authorized. If not, execute S604; if yes, execute S608.

[0214] S608, obtain the request interface information and / or the data rules corresponding to the request query parameters.

[0215] Optionally, first check whether the request interface is bound to the data rule parameter mapping. Taking the request interface as interface A as an example, if it is found that the request query parameter storeIds is bound to the data rule parameter mapping of STORE-ID, then the data rule of STORE-ID will be obtained.

[0216] S609, determine the interface authorization information of the authorization verification object under the request interface based on data rules.

[0217] Optionally, the open platform will determine the authorization type of developer A under the request interface and the authorization query parameters, i.e., authorization data items, that exist under the STORE-ID data rule from the data rules.

[0218] S610: Determine whether the authorization type of the authorization verification object under the request interface is full authorization. If yes, execute S615; otherwise, execute S611.

[0219] S611, determine the authorization scope corresponding to the interface authorization information.

[0220] Optionally, if the authorization type is not full authorization, then it is partial authorization, and the open platform will perform the step of determining the authorization scope corresponding to the interface authorization information. It can be understood that the authorization scope is the range of data items constituted by each authorized data item.

[0221] S612, determine whether the request query parameters match the authorization query parameters. If yes, execute S613; otherwise, execute S608.

[0222] S613 forwards the data query request to the target product's open interface and receives the target data queried through the target product's open interface based on the query parameters requested in the data query request.

[0223] S614 sends the assembled target data to an external application.

[0224] The above data processing method has four key advantages. First, combining signatures with data rules effectively prevents users from forging signatures to access illegally authorized data. Second, data rules can be dynamically configured according to actual needs. For example, data rules can be set for merchant IDs, store IDs, regions, brands, etc., and all data rules have a unified format specification, which can be followed for configuration. Third, data rules are mapped to interface parameters, dynamically binding interface parameters. When needed, data rules can be imported by configuring the mapping between interface parameters and data rules; when not needed, the mapping can be turned off directly. Fourth, the data rule items support multiple authorization types for developers. For example, full authorization is sufficient when there are thousands of stores, requiring only one full authorization permission record instead of storing thousands of separate permission records. The specific types of authorization can also be expanded according to actual needs. Fifth, the interface and data rules can cover a two-tier authorization system for merchants and developers. If the interface involves the merchant's core data, the developer needs to apply for authorization from the merchant. Only when the merchant agrees to the authorization can the relevant data be queried through the interface. If the interface does not involve the merchant's core data, the developer can directly query the relevant data through the interface. This permission can be granted by adding an attribute to the interface indicating whether merchant authorization is required.

[0225] It should be understood that although the steps in the flowcharts of the embodiments described above 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 embodiments described above 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.

[0226] Based on the same inventive concept, this application also provides a data processing apparatus for implementing the data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more data processing apparatus embodiments provided below can be found in the limitations of the data processing method described above, and will not be repeated here.

[0227] In one embodiment, such as Figure 7As shown, a data processing apparatus 700 is provided, including: a request receiving module 701, an interface authorization information acquisition module 702, and a data query module 703, wherein:

[0228] The request receiving module 701 is used to receive a data query request and obtain the request information corresponding to the data query request. The request information includes at least one authorization verification object and request query parameters.

[0229] The interface authorization information acquisition module 702 is used to acquire the interface authorization information of the authorization verification object under the request interface corresponding to the data query request.

[0230] The data query module 703 is used to obtain target data based on the request query parameters if the interface authorization information indicates that the authorized verification object has data query permissions.

[0231] In one embodiment, the interface authorization information acquisition module 702 is used to: acquire data rules determined by request query information corresponding to the request interface; the request query information includes request interface information and / or request query parameters corresponding to the request interface; and determine the interface authorization information of the authorization verification object under the request interface based on the data rules.

[0232] In one embodiment, the data processing apparatus 700 further includes:

[0233] The authorization status determination module is used to determine the query authorization status of the authorization verification object under the request interface.

[0234] The authorized execution module is used to return the steps of obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request through the interface authorization information acquisition module 702.

[0235] In one embodiment, the interface authorization information includes the authorization type of the authorization verification object under the requested interface. The data processing apparatus 700 further includes:

[0236] The permission determination module is used to determine the authorization scope corresponding to the interface authorization information. If the authorization type of the authorization verification object under the request interface is full authorization, it indicates that the authorization verification object has data query permission. If the authorization type of the authorization object under the request interface is partial authorization, it determines the authorization scope corresponding to the interface authorization information. When the interface authorization information indicates that the authorization verification object has data query permission, it executes the step of obtaining the target data based on the request query parameters.

[0237] In one embodiment, the data processing apparatus 700 further includes:

[0238] The authorization change operation response module is used to respond to authorization operations on the authorization verification object under the request interface and obtain the authorization adjustment information of the authorization verification object.

[0239] The authorization information update module is used to update the interface authorization information of the authorization verification object under the requested interface according to the authorization adjustment information.

[0240] In one embodiment, the data query request is generated by signing the request information based on an encryption key. The request receiving module 701 is configured to: receive the data query request, obtain a decryption key matching the data query request; use the decryption key to sign and decrypt the data query request to obtain a signature timestamp; if the signature timestamp is within a valid time range, determine that the validity period verification of the data query request is successful, and extract the request information corresponding to the data query request.

[0241] In one embodiment, the data query module 703 is used to: if the interface authorization information indicates that the authorized verification object has data query permission, forward the data query request to the target service object, and receive the target data queried by the target service object based on the query parameters requested in the data query request.

[0242] Each module in the aforementioned data processing 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, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0243] In one embodiment, a computer device is provided, which may be a server integrating an open platform, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to data processing. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a data processing method.

[0244] Those skilled in the art will understand that Figure 8The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Optional computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0245] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement optional implementation steps of the data processing method described above.

[0246] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements optional implementation steps of the data processing method described above.

[0247] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements optional implementation steps of the data processing method described above.

[0248] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the acquisition, storage, processing, and transmission of the data all comply with relevant laws and regulations.

[0249] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0250] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0251] The embodiments described above are merely examples of several implementation methods of this application, and their descriptions are optional and detailed, but they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data processing method, characterized in that, The method includes: Upon receiving a data query request, obtain the request information corresponding to the data query request, wherein the request information includes at least one authorization verification object and request query parameters; Obtain the interface authorization information of the authorization verification object under the request interface corresponding to the data query request; If the interface authorization information indicates that the authorized verification object has data query permissions, then the target data is obtained based on the request query parameters.

2. The method according to claim 1, characterized in that, The step of obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request includes: Obtain the data rules determined by the request query information corresponding to the request interface; the request query information includes request interface information and / or the request query parameters. Based on the data rules, the interface authorization information of the authorization verification object under the requested interface is determined.

3. The method according to claim 1, characterized in that, The method further includes: Determine the query authorization status of the authorization verification object under the request interface; If the query authorization status is authorized, then the step of obtaining the interface authorization information of the authorization verification object under the request interface corresponding to the data query request is executed.

4. The method according to any one of claims 1 to 3, characterized in that, The interface authorization information indicates that the authorized verification object has data query permissions, including satisfying at least one of the following conditions: The request query parameters are matched with the authorization query parameters, wherein the authorization query parameters are determined based on the authorization scope corresponding to the interface authorization information; and The authorization type of the authorization verification object under the request interface is full authorization, wherein the interface authorization information includes the authorization type of the authorization verification object under the request interface.

5. The method according to claim 1, characterized in that, The interface authorization information includes the authorization type of the authorization verification object under the requested interface, and the method further includes: If the authorization type of the authorization verification object under the request interface is full authorization, it indicates that the authorization verification object has data query permission; If the authorization type of the authorization verification object under the request interface is partial authorization, then the authorization scope corresponding to the interface authorization information is determined. When the interface authorization information indicates that the authorization verification object has data query permission, the step of obtaining target data based on the request query parameters is executed.

6. The method according to any one of claims 1 to 3 and 5, characterized in that, The method further includes: In response to the authorization operation performed on the authorization verification object under the request interface, obtain the authorization information for the authorization verification object; The authorization information is used to determine the interface authorization information of the authorization verification object under the request interface.

7. The method according to any one of claims 1 to 3 and 5, characterized in that, The data query request is generated by signing the request information based on the encryption key; The step of receiving a data query request and obtaining the request information corresponding to the data query request includes: Upon receiving a data query request, obtain the decryption key that matches the data query request; The data query request is signed and decrypted using the decryption key to obtain a signature timestamp; If the signature timestamp is within a valid time range, the validity period of the data query request is determined to be successfully verified, and the request information corresponding to the data query request is extracted.

8. The method according to any one of claims 1 to 3 and 5, characterized in that, If the interface authorization information indicates that the authorized verification object has data query permissions, then the target data is obtained based on the request query parameters, including: If the interface authorization information indicates that the authorized verification object has data query permissions, then the data query request is forwarded to the target service object, and the target data queried by the target service object based on the query parameters requested in the data query request is received.

9. A data processing apparatus, characterized in that, The device includes: The request receiving module is used to receive a data query request and obtain the request information corresponding to the data query request, wherein the request information includes at least one authorization verification object and request query parameters; The interface authorization information acquisition module is used to acquire the interface authorization information of the authorization verification object under the request interface corresponding to the data query request; The data query module is used to obtain target data based on the request query parameters if the interface authorization information indicates that the authorized verification object has data query permissions.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images