Cross-platform capability opening method and device
By decoupling the permission verification process into two stages—access permission verification and data scope adjudication—and utilizing the permission context reconstruction module of the unified API gateway, the problem of permission context transmission gaps in enterprise-level capability open platforms is solved, achieving efficient permission control and independent system evolution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-15
- Publication Date
- 2026-04-14
AI Technical Summary
In the construction of enterprise-level capability open platforms, existing technologies are unable to achieve seamless integration between centralized management of a unified portal and refined data permission control of downstream systems without compromising the autonomy of downstream systems. This results in gaps in permission context transmission, bloated permission models, and low operational efficiency.
The permission verification process is decoupled into two stages: access permission verification and data scope adjudication. Through the permission context reconstruction module in the unified API gateway, the verification results of the previous stage are transformed into instruction information that can be directly used in the next stage, forming an efficient verification responsibility chain.
It completely solves the problem of broken permission context transmission, realizes clear decoupling and independent evolution of the verification responsibility chain, improves the maintainability and scalability of the system, and reduces operation and maintenance costs.
Smart Images
Figure CN121864436A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of service integration technology, and in particular relates to a method and apparatus for cross-platform capability opening. Background Technology
[0002] In the construction of enterprise-level capability open platforms, integrating existing capability provider systems (hereinafter referred to as "capability provider systems") into a unified portal has become an inevitable trend to improve the efficiency of enterprise digital collaboration. However, a core technical contradiction has long existed in this process: the unified portal needs to achieve centralized access control and traffic scheduling to ensure the overall security and operational efficiency of the platform; while downstream capability provider systems, for the sake of business autonomy and data security, must retain the final right of interpretation and fine-grained control over their own data resources.
[0003] Current technical solutions in the industry generally suffer from inherent flaws that are difficult to overcome, and these flaws have not been effectively resolved, as detailed below: Centralized authentication solutions require all capability provider systems to migrate their data permission models and management rules to a unified portal. This approach severely infringes on the business autonomy of capability provider systems and faces significant resistance in practical implementation. Furthermore, the overlapping complexity of data permissions across different systems leads to a bloated permission model in the unified portal, significantly reducing operational efficiency. This solution, through "permission contracts that only synchronize identifiers and local data scope adjudication," eliminates the need for downstream systems to relinquish their permission models, fully preserving data control and completely resolving this intrusive problem.
[0004] Gateway proxy and token solution: The unified gateway only performs application identity authentication and generates a generic token (such as JWT). After the capability provider system parses the token, it still needs to query the local permission system again based on the user identifier in it—essentially a "pseudo-unified authentication" that does not solve the problem of the gap in the transmission of permission context across systems.
[0005] Traditional API gateway solutions primarily focus on API traffic control, authentication, and authorization. However, their authorization granularity is limited to the interface or routing level, completely failing to address the core issue of "which specific business data a caller is authorized to access (i.e., data scope permissions)." This "last mile" data permission issue is directly left to downstream business systems, and no standardized context passing mechanism is provided, leading to vulnerabilities in permission control (a government platform once experienced a security incident where a caller arbitrarily queried data from other regions due to a lack of data scope control). This solution, through a "two-stage verification chain," is the first to separate "interface-level access permission" and "data-level scope adjudication" into collaborative processes, filling the gap in data permission control.
[0006] Therefore, there is an urgent need in this field for a new architecture that can seamlessly integrate the centralized management advantages of a unified portal with the refined data access control capabilities of downstream systems without compromising the autonomy of downstream systems, thereby forming a complete and efficient chain of responsibility for access verification. Summary of the Invention
[0007] In view of the shortcomings of the prior art, the purpose of the invention is to provide a cross-platform capability opening method and device, which decouples the permission verification process of a single API call request into two sequential and clearly defined stages: access permission verification and data scope adjudication; through the permission context reconstruction module in the unified API gateway, the verification result of the previous stage is transformed into instruction information that can be directly used in the next stage, forming an efficient verification responsibility chain.
[0008] In a first aspect, the present invention proposes a cross-platform capability opening method, applicable to a system comprising: a unified capability portal, a unified API gateway, and multiple capability provider systems, including: When the capability authorization takes effect, the unified capability portal will synchronize the permission contract to the corresponding capability provider system, and the unified capability portal will receive a confirmation that the permission contract has been successfully synchronized. When an external API request arrives at the unified API gateway, the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. If the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules; The unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies; The data scope arbiter in the corresponding capability provider system determines whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the determination result is that it originates from the unified capability portal and carries a permission context; The data range adjudicator parses the permission identifier in the standardized HTTP request header, calls the local data permission query service, and the local data permission query service dynamically parses and returns the data range that can be accessed in this request by combining the synchronized permission contract and local business rules. The data scope arbiter injects the accessible data scope into subsequent business processing flows; Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
[0009] Furthermore, the aforementioned method for opening up cross-platform capabilities also includes: If the unified capability portal does not receive a confirmation of successful synchronization of the permission contract, the unified capability portal will periodically retry synchronizing the permission contract to the corresponding capability provider system. If the scheduled retry fails, the permission contract will be marked as pending synchronization and an alert will be issued. After the capability provider system restarts, it requests the contracts to be synchronized from the unified capability portal.
[0010] Furthermore, the aforementioned method for opening up cross-platform capabilities also includes: If the determination result is that the AppID of the external request does not have the interface-level permission to call the target API ID, a 403 Forbidden response is returned; The unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract through the access permission verification module in the unified API gateway. The unified API gateway encapsulates external requests into requests with embedded standardized HTTP request headers according to preset rules through the permission context reconstruction module in the unified API gateway.
[0011] Furthermore, in the aforementioned cross-platform capability opening method, the process by which the unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through a load balancing strategy includes: The unified API gateway filters or overrides the standardized HTTP request headers provided by the client.
[0012] Furthermore, the aforementioned method for opening up cross-platform capabilities also includes: When the data range arbiter detects a missing standardized HTTP request header while parsing the permission identifier in the request header, it returns a 403 Forbidden response. Attach missing field hints to the response message.
[0013] Furthermore, in the aforementioned method for opening up cross-platform capabilities, the local data permission query service dynamically parses and returns the range of data accessible for this request by combining the synchronized permission contract and local business rules, including: When there is a conflict between the synchronized permission contract and the local business rules, the local business rules shall prevail. When the local data permission query service malfunctions and the adjudication time exceeds the preset duration, a degradation strategy is triggered, a 503 Service Unavailable response is returned, and the log is logged simultaneously. The logs contain the AppID, API ID, and timeout information.
[0014] Furthermore, in the aforementioned method for opening up cross-platform capabilities, the subsequent business processing flow includes: If the business logic is a database query, use the accessible data range as the WHERE condition of the SQL statement; If the business logic involves cached queries, the accessible data range will be used as part of the cache key.
[0015] A second aspect of the present invention also proposes a cross-platform capability opening device, applied to a system comprising: a unified capability portal, a unified API gateway, and multiple capability provider systems, including: Synchronization module: When capability authorization takes effect, the unified capability portal synchronizes the permission contract to the corresponding capability provider system, and the unified capability portal receives a confirmation of successful synchronization of the permission contract. The first judgment module is used when an external API request arrives at the unified API gateway. The unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. Encapsulation module: If the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules. Routing module: Used by the unified API gateway to route requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies; The second judgment module is used by the data range arbiter in the corresponding capability provider system to determine whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the judgment result is that it originates from the unified capability portal and carries a permission context. Parsing module: Used by the data range adjudicator to parse the permission identifier in the standardized HTTP request header, call the local data permission query service, and the local data permission query service dynamically parses and returns the data range that can be accessed in this request by combining the synchronized permission contract and local business rules. Injection module: Used by the data range arbiter to inject the accessible data range into the subsequent business processing flow; Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
[0016] A third aspect of the present invention also provides an electronic device comprising: a processor and a memory; The processor executes one of the above methods for opening up cross-platform capabilities by calling programs or instructions stored in memory.
[0017] In a fourth aspect, the present invention also provides a computer-readable storage medium that stores a program or instructions that cause a computer to execute any of the preceding cross-platform capability opening methods.
[0018] The beneficial effects of this invention are as follows: 1. Completely resolve the issue of fragmented permission context transmission. The permission context reconstruction module transforms the gateway verification result into a standardized instruction set: a standardized HTTP request header. This constructs an instruction-driven cross-system permission interaction mechanism. Unlike the traditional token information carrying mode, this application clearly informs the capability provider system which identifiers to use for data adjudication, rather than letting the downstream capability provider system parse the information itself, thus completely eliminating the transmission gap of permission context between systems. At the same time, the standardized instruction set is lightweight, containing only 3-5 request headers, avoiding the redundant information transmission and parsing overhead of traditional tokens.
[0019] 2. Achieve clear decoupling and independent evolution of the verification responsibility chain. The unified API gateway clearly defines the interface-level permissions for access control and the responsibilities of the data scope that capability provider systems can access. The unified capability portal does not need to understand the complex data permission logic of capability provider systems, such as regional division rules of different systems, and can focus on centralized management. Capability provider systems do not need to modify their core permission models; they only need to add a data scope adjudicator plugin to connect to the platform. This decoupling allows both parties to evolve independently. For example, when the unified API gateway upgrades its traffic control logic, no cooperation from capability provider systems is required. When capability provider systems adjust their data permission rules, no changes to the API gateway are required, greatly improving system maintainability and scalability.
[0020] 3. Improve technical performance and reduce operation and maintenance costs The capability provider system receives highly refined request instructions, and its local data permission query service can perform index-level queries based on identifiers in the instructions, such as AppID and API ID, avoiding the high overhead of parsing tokens and multi-table join queries in traditional token schemes. Attached Figure Description
[0021] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.
[0022] Figure 1 A method for opening up cross-platform capabilities provided in this embodiment of the invention. Figure 1 ; Figure 2 A method for opening up cross-platform capabilities provided in this embodiment of the invention. Figure 2 ; Figure 3 A diagram of a cross-platform capability opening device provided in an embodiment of the present invention; Figure 4 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0023] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0024] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.
[0025] In the description of this invention, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.
[0027] This invention proposes a cross-platform capability opening method, device, electronic device, and storage medium, which decouples the permission verification process of a single API call request into two sequential and clearly defined stages: access permission verification and data scope adjudication. Through the permission context reconstruction module in the unified API gateway, the verification result of the previous stage is transformed into instruction information that can be directly used in the next stage, forming an efficient verification responsibility chain.
[0028] Before introducing the embodiments of the present invention, the technical terms involved in the present invention will be introduced first.
[0029] Unified Capability Portal: It undertakes functions such as capability product management, developer application review, and permission contract synchronization. It is the initial generation point for permission contracts. When synchronizing permission contracts, only AppID, ProductID, and API ID are transmitted, without including the data range, to protect the data autonomy of the capability provider's system.
[0030] Unified API Gateway: As the sole entry point for all API requests, it has a built-in access permission verification module and a permission context reconstruction module. The permission context reconstruction module can be integrated into the gateway or deployed as a standalone service, and its core function is to generate standardized HTTP request headers.
[0031] Capability provider system: This refers to the existing heterogeneous business system, with no fewer than one such system. Internally, it deploys a "data scope arbiter", a "local data permission query service", and a "business logic layer". The "data scope arbiter" can be implemented using technologies such as interceptors and Spring aspects. It is responsible for capturing requests, parsing instructions, and triggering data scope adjudication.
[0032] Method Implementation Examples Figure 1 A method for opening up cross-platform capabilities provided in this embodiment of the invention. Figure 1 .
[0033] In a first aspect, this invention proposes a cross-platform capability opening method, applicable to a system comprising a unified capability portal, a unified API gateway, and multiple capability provider systems, combined with... Figure 1 It includes seven steps, S1 to S7: S1: When the capability authorization takes effect, the unified capability portal will synchronize the permission contract to the corresponding capability provider system, and the unified capability portal will receive a confirmation that the permission contract has been successfully synchronized.
[0034] Specifically, in this embodiment of the invention, capability authorization can take effect when a developer's API application is approved, and the unified capability portal synchronizes the permission contract to the corresponding capability provider system. Here, the permission contract is an authorization record, and the synchronization adopts a confirmation receipt mechanism: after the unified capability portal sends the permission contract, it waits for the capability provider system to return a synchronization success receipt. When the unified capability portal receives the receipt indicating that the permission contract has been successfully synchronized, it means that the permission contract has been successfully synchronized. The permission contract clearly defines the association between the calling subject (AppID), the capability carrier (ProductID), and the accessible resource (API ID), but does not yet include a specific data range. The data range is dynamically determined by the capability provider system in the subsequent adjudication process to ensure its data control rights.
[0035] S2: When an external API request arrives at the unified API gateway, the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract.
[0036] Specifically, in this embodiment of the invention, external API requests pass through the unified API gateway of the unified capability portal, which has the identifier of the unified capability portal, such as X-UNIFY-APP-ID. The access permission verification module in the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. This determination result is a binary decision: pass or reject, which is only responsible for coarse-grained control over whether the interface can be called.
[0037] S3: If the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules.
[0038] Specifically, in this embodiment of the invention, if the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, that is, through, the permission context reconstruction module of the unified API gateway is triggered. The permission context reconstruction module of the unified API gateway extracts the AppID and API ID from the request, and if necessary, also extracts the ProductID, and encapsulates the external request into a request with a standardized HTTP request header, such as: X-UNIFY-APP-ID: app_demo, X-UNIFY-API-ID: api_community_query It should be understood that the request encapsulated here as an embedded standardized HTTP request header is a lightweight instruction set that only conveys the basis required for downstream adjudication, rather than a heavy token containing all the information, thus avoiding data redundancy and parsing overhead.
[0039] S4: The unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies.
[0040] Specifically, in this embodiment of the invention, the unified API gateway filters or overrides the client's built-in X-UNIFY-* request headers when routing requests with embedded standardized HTTP request headers to the corresponding capability provider system through a load balancing strategy, so as to prevent the client from transmitting incorrect permission information through its built-in X-UNIFY-* headers.
[0041] S5: The data scope arbiter in the corresponding capability provider system determines whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the determination result is that it originates from the unified capability portal and carries a permission context.
[0042] Specifically, in this embodiment of the invention, at the interface entry point of the capability provider system, the data scope adjudicator, such as the Spring aspect, automatically captures requests and determines that the request originates from the unified portal and carries a permission context by recognizing standardized fields such as X-UNIFY-APP-ID, and then initiates the data scope adjudication process.
[0043] S6: The data range adjudicator parses the permission identifier in the standardized HTTP request header, calls the local data permission query service, and dynamically parses and returns the data range that can be accessed in this request by combining the synchronized permission contract and local business rules.
[0044] Specifically, in this embodiment of the invention, the data range arbiter parses the permission identifier in the standardized HTTP request header, where the permission identifier is: The combination of X-UNIFY-AppID and X-UNIFY-API ID can be used to retrieve the corresponding data authorization range. A local lightweight data permission query service is then invoked. This service dynamically parses and returns the data range accessible for this request, combining the synchronized permission contract with local business rules. Local business rules include the region and authorization level of the AppID. The accessible data range is a precise range; for example, if the AppID is app_123 and the API ID is api_community_query, it returns a list of community IDs [1001, 1002]. If no data range is accessible, an empty list is returned (without an error message).
[0045] S7: The data range arbiter injects the accessible data range into the subsequent business processing flow.
[0046] Specifically, in this embodiment of the invention, the data range arbiter seamlessly injects the parsed accessible data range into the subsequent business processing flow, which is described in detail below.
[0047] Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
[0048] Figure 2 A method for opening up cross-platform capabilities provided in this embodiment of the invention. Figure 2 .
[0049] Furthermore, the aforementioned method for opening up cross-platform capabilities, combined with Figure 2 It also includes three steps, S21 to S23: S21: The unified capability portal did not receive a confirmation of successful synchronization of the permission contract. The unified capability portal will periodically retry synchronizing the permission contract to the corresponding capability provider system. S22: If the timed retry fails, mark the permission contract as pending synchronization and issue an alert; S23: After the capability provider system restarts, it requests the contracts to be synchronized from the unified capability portal.
[0050] Specifically, in this embodiment of the invention, if the unified capability portal does not receive a confirmation of successful synchronization of the permission contract, the unified capability portal marks the permission contract status as pending synchronization, triggers an alarm, and retries periodically, such as once every 5 minutes, for a total of 3 times. If the result of the periodic retry is unsuccessful, the permission contract is marked as pending synchronization and an alarm is triggered. After the capability provider system restarts, it actively requests the unsynchronized contract from the unified capability portal to avoid the loss of the contract due to the restart of the capability provider system and to retry periodically.
[0051] Furthermore, the aforementioned method for opening up cross-platform capabilities also includes: If the determination result is that the AppID of the external request does not have the interface-level permission to call the target API ID, a 403 Forbidden response is returned.
[0052] Specifically, in this embodiment of the invention, the access permission verification module in the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. This determination result is a binary decision: pass or reject, which is only responsible for coarse-grained control over whether the interface can be called. If the determination result is that the AppID of the external request does not have the interface-level permission to call the target API ID, that is, reject, and directly return a 403 Forbidden response without proceeding to the subsequent process.
[0053] Furthermore, in the aforementioned cross-platform capability opening method, the process by which the unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through a load balancing strategy includes: The unified API gateway filters or overrides the standardized HTTP request headers provided by the client.
[0054] Specifically, in this embodiment of the invention, the unified API gateway filters or overrides the client's built-in X-UNIFY-* request headers when routing requests with embedded standardized HTTP request headers to the corresponding capability provider system through a load balancing strategy, so as to prevent the client from transmitting incorrect permission information through its built-in X-UNIFY-* headers.
[0055] Furthermore, the aforementioned method for opening up cross-platform capabilities also includes: When the data range arbiter detects a missing standardized HTTP request header while parsing the permission identifier in the request header, it returns a 403 Forbidden response. Attach missing field hints to the response message.
[0056] Specifically, in this embodiment of the invention, when the data range arbitrator detects a missing standardized HTTP request header while parsing the permission identifier in the request header, the permission identifier here is: The combination of X-UNIFY-AppID and X-UNIFY-API ID standardizes the missing HTTP request headers, such as the missing X-UNIFY-APP-ID. In this case, a 403 Forbidden response is returned directly, and the missing field is appended to the X-UNIFY-Error header in the response message, such as: Missing X-UNIFY-APP-ID.
[0057] Furthermore, in the aforementioned method for opening up cross-platform capabilities, the local data permission query service dynamically parses and returns the range of data accessible for this request by combining the synchronized permission contract and local business rules, including: When there is a conflict between the synchronized permission contract and the local business rules, the local business rules shall prevail.
[0058] Specifically, in this embodiment of the invention, when a synchronized permission contract conflicts with local business rules, the local business rules shall prevail. For example, if a synchronized permission contract allows access to data nationwide, but local business rules restrict access only to Guangdong Province, the final decision shall be made according to Guangdong Province to ensure data control of downstream systems.
[0059] When the local data permission query service malfunctions and the adjudication time exceeds the preset duration, a degradation strategy is triggered, a 503 Service Unavailable response is returned, and the log is logged simultaneously. The logs contain the AppID, API ID, and timeout information.
[0060] Specifically, in this embodiment of the invention, when the local data permission query service is abnormal, such as when the database crashes, the data range arbiter triggers a degradation, returns a 503 Service Unavailable response, and records an exception log containing the AppID, API ID, and timeout. At the same time, the service circuit breaker is triggered, and the local data permission query service will not be called again within 1 minute to avoid cascading failures.
[0061] Furthermore, in the aforementioned method for opening up cross-platform capabilities, the subsequent business processing flow includes: If the business logic is a database query, use the accessible data range as the WHERE condition of the SQL statement; If the business logic is a cache query, the accessible data range is used as part of the cache key. Specifically, in this embodiment of the invention, if the business logic is a database query, the accessible data range is directly used as the WHERE condition of the SQL, such as: WHERE community_id IN (1001, 1002); if it is a cache query, the accessible data range is used as part of the cache key, such as: cache_key: app_demo_api_community_query_[1001,1002], ensuring that only data within the authorized range is returned.
[0062] Device Examples Figure 3 This is a diagram of a cross-platform capability opening device provided in an embodiment of the present invention.
[0063] A second aspect of the present invention also proposes a cross-platform capability opening device, applied to a system comprising: a unified capability portal, a unified API gateway, and multiple capability provider systems, including: Synchronization module 31: When capability authorization takes effect, the unified capability portal synchronizes the permission contract to the corresponding capability provider system, and the unified capability portal receives a confirmation of successful synchronization of the permission contract.
[0064] Specifically, in this embodiment of the invention, capability authorization can take effect when a developer's API application is approved, and the synchronization module 31 of the unified capability portal synchronizes the permission contract to the corresponding capability provider system. Here, the permission contract is an authorization record, and the synchronization adopts a confirmation receipt mechanism: after the unified capability portal sends the permission contract, it waits for the capability provider system to return a synchronization success receipt. When the unified capability portal receives the receipt indicating that the permission contract has been successfully synchronized, it means that the permission contract has been successfully synchronized. The permission contract clearly defines the association between the calling subject (AppID), the capability carrier (ProductID), and the accessible resource (API ID), but does not yet include a specific data range. The data range is dynamically determined by the capability provider system in the subsequent adjudication process to ensure its data control rights.
[0065] First judgment module 32: When an external API request arrives at the unified API gateway, the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract.
[0066] Specifically, in this embodiment of the invention, external API requests pass through the unified API gateway of the unified capability portal, which has the identifier of the unified capability portal, such as X-UNIFY-APP-ID. The first judgment module 32 in the unified API gateway judges whether the AppID of the external request has the interface-level permission to call the target API ID according to the synchronized permission contract. This judgment result is a binary judgment: pass or reject, which is only responsible for coarse-grained control of whether the interface can be called.
[0067] Encapsulation module 33: If the judgment result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules.
[0068] Specifically, in this embodiment of the invention, if the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, that is, through, the permission context reconstruction module of the unified API gateway is triggered. The permission context reconstruction module of the unified API gateway extracts the AppID and API ID from the request, and if necessary, also extracts the ProductID. The encapsulation module 33 encapsulates the external request into a request with embedded standardized HTTP request headers, such as: X-UNIFY-APP-ID: app_demo, X-UNIFY-API-ID: api_community_query It should be understood that the request encapsulated here as an embedded standardized HTTP request header is a lightweight instruction set that only conveys the basis required for downstream adjudication, rather than a heavy token containing all the information, thus avoiding data redundancy and parsing overhead.
[0069] Routing module 34: Used by the unified API gateway to route requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies.
[0070] Specifically, in this embodiment of the invention, the routing module 34 of the unified API gateway filters or overrides the client's built-in X-UNIFY-* request header during the process of routing the request with the embedded standardized HTTP request header to the corresponding capability provider system through the load balancing strategy, so as to prevent the client from transmitting incorrect permission information through the built-in X-UNIFY-* header.
[0071] The second judgment module 35 is used in the corresponding capability provider system to determine whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the judgment result is that it originates from the unified capability portal and carries a permission context.
[0072] Specifically, in this embodiment of the invention, at the interface entry point of the capability provider system, the data scope arbiter, such as a Spring aspect, automatically captures requests. The second judgment module 35 determines that the request originates from the unified portal and carries a permission context by recognizing standardized fields such as X-UNIFY-APP-ID, and then initiates the data scope adjudication process.
[0073] Parsing Module 36: Used by the data range adjudicator to parse the permission identifier in the standardized HTTP request header, call the local data permission query service, and dynamically parse and return the data range that can be accessed in this request by combining the synchronized permission contract and local business rules.
[0074] Specifically, in this embodiment of the invention, the parsing module 36 of the data range arbiter parses the permission identifier in the standardized HTTP request header, where the permission identifier is: The combination of X-UNIFY-AppID and X-UNIFY-API ID can be used to retrieve the corresponding data authorization range. A local lightweight data permission query service is then invoked. This service dynamically parses and returns the data range accessible for this request, combining the synchronized permission contract with local business rules. Local business rules include the region and authorization level of the AppID. The accessible data range is a precise range; for example, if the AppID is app_123 and the API ID is api_community_query, it returns a list of community IDs [1001, 1002]. If no data range is accessible, an empty list is returned (without an error message).
[0075] Injection Module 37: Used by the data range arbiter to inject the accessible data range into the subsequent business processing flow.
[0076] Specifically, in this embodiment of the invention, the injection module 37 of the data range arbiter seamlessly injects the parsed accessible data range into the subsequent business processing flow.
[0077] Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
[0078] A third aspect of the present invention also provides an electronic device comprising: a processor and a memory; The processor executes one of the above methods for opening up cross-platform capabilities by calling programs or instructions stored in memory.
[0079] In a fourth aspect, the present invention also provides a computer-readable storage medium that stores a program or instructions that cause a computer to execute any of the preceding cross-platform capability opening methods.
[0080] Figure 4 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention.
[0081] like Figure 4 As shown, the electronic device includes at least one processor 401, at least one memory 402, and at least one communication interface 403. The various components of the electronic device are coupled together via a bus system 404. The communication interface 403 is used for information transmission with external devices. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 4 The general designated all buses as Bus System 404.
[0082] It is understood that the memory 402 in this embodiment can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.
[0083] In some implementations, memory 402 stores elements such as executable units or data structures, or subsets thereof, or extended sets thereof: operating systems and applications.
[0084] The operating system includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. Application programs include various applications, such as media players and browsers, used to implement various application functions. Programs implementing any method in the cross-platform capability opening method provided in this embodiment of the invention can be included in the application programs.
[0085] In this embodiment of the invention, the processor 401 executes the steps of various embodiments of the cross-platform capability opening method provided by the present invention by calling the program or instructions stored in the memory 402, specifically, the program or instructions stored in the application.
[0086] When the capability authorization takes effect, the unified capability portal will synchronize the permission contract to the corresponding capability provider system, and the unified capability portal will receive a confirmation that the permission contract has been successfully synchronized. When an external API request arrives at the unified API gateway, the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. If the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules; The unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies; The corresponding capability provider system determines whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the determination result is that it originates from the unified capability portal and carries a permission context; The data range adjudicator parses the permission identifier in the standardized HTTP request header, calls the local data permission query service, and the local data permission query service dynamically parses and returns the data range that can be accessed in this request by combining the synchronized permission contract and local business rules. The data scope arbiter injects the accessible data scope into subsequent business processing flows; Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
[0087] Any method in the cross-platform capability opening method provided in this embodiment of the invention can be applied to, or implemented by, processor 401. Processor 401 can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 401 or by instructions in software form. Processor 401 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor.
[0088] The steps of any method in the cross-platform capability opening method provided in this embodiment of the invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software units in the decoding processor. The software units can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 402, and processor 401 reads the information in memory 402 and combines it with its hardware to complete the steps of the method.
[0089] Those skilled in the art will understand that although some embodiments described herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of the invention and form different embodiments.
[0090] Those skilled in the art will understand that the descriptions of the various embodiments have different focuses, and for parts not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0091] Although embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention. All such modifications and variations fall within the scope defined by the appended claims. The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
[0092] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A method for opening up cross-platform capabilities, characterized in that, It is applied to systems comprising a unified capability portal, a unified API gateway, and multiple capability provider systems, including: When the capability authorization takes effect, the unified capability portal will synchronize the permission contract to the corresponding capability provider system, and the unified capability portal will receive a confirmation that the permission contract has been successfully synchronized. When an external API request arrives at the unified API gateway, the unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. If the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules; The unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies; The data scope arbiter in the corresponding capability provider system determines whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the determination result is that it originates from the unified capability portal and carries a permission context; The data range adjudicator parses the permission identifier in the standardized HTTP request header, calls the local data permission query service, and the local data permission query service dynamically parses and returns the data range that can be accessed in this request by combining the synchronized permission contract and local business rules. The data scope arbiter injects the accessible data scope into subsequent business processing flows; Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
2. The cross-platform capability opening method according to claim 1, characterized in that, The method further includes: If the unified capability portal does not receive a confirmation of successful synchronization of the permission contract, the unified capability portal will periodically retry synchronizing the permission contract to the corresponding capability provider system. If the scheduled retry fails, the permission contract will be marked as pending synchronization and an alert will be issued. After the capability provider system restarts, it requests the contracts to be synchronized from the unified capability portal.
3. The method for opening up cross-platform capabilities according to claim 1, characterized in that, The method further includes: If the determination result is that the AppID of the external request does not have the interface-level permission to call the target API ID, a 403 Forbidden response is returned; The unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract through the access permission verification module in the unified API gateway. The unified API gateway encapsulates external requests into requests with embedded standardized HTTP request headers according to preset rules through the permission context reconstruction module in the unified API gateway.
4. The method for opening up cross-platform capabilities according to claim 1, characterized in that, The unified API gateway routes requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies, including: The unified API gateway filters or overrides the standardized HTTP request headers provided by the client.
5. The method for opening up cross-platform capabilities according to claim 1, characterized in that, The method further includes: When the data range arbiter detects a missing standardized HTTP request header while parsing the permission identifier in the request header, it returns a 403 Forbidden response. Attach missing field hints to the response message.
6. The cross-platform capability opening method according to claim 1, characterized in that, The local data permission query service dynamically parses and returns the range of data that can be accessed for this request, based on synchronized permission contracts and local business rules, including: When there is a conflict between the synchronized permission contract and the local business rules, the local business rules shall prevail. When the local data permission query service malfunctions and the adjudication time exceeds the preset duration, a degradation strategy is triggered, a 503 Service Unavailable response is returned, and the log is logged simultaneously. The logs contain the AppID, API ID, and timeout information.
7. The cross-platform capability opening method according to claim 1, characterized in that, The subsequent business processing flow includes: If the business logic is a database query, use the accessible data range as the WHERE condition of the SQL statement; If the business logic involves cached queries, the accessible data range will be used as part of the cache key.
8. A cross-platform capability open device, characterized in that, It is applied to systems comprising a unified capability portal, a unified API gateway, and multiple capability provider systems, including: Synchronization module: When capability authorization takes effect, the unified capability portal synchronizes the permission contract to the corresponding capability provider system, and the unified capability portal receives a confirmation of successful synchronization of the permission contract. The first judgment module is used when an external API request arrives at the unified API gateway. The unified API gateway determines whether the AppID of the external request has the interface-level permission to call the target API ID based on the synchronized permission contract. Encapsulation module: If the determination result is that the AppID of the external request has the interface-level permission to call the target API ID, the unified API gateway extracts the AppID and API ID from the external request and encapsulates the external request into a request with embedded standardized HTTP request headers according to preset rules. Routing module: Used by the unified API gateway to route requests with embedded standardized HTTP request headers to the corresponding capability provider system through load balancing strategies; The second judgment module is used by the data range arbiter in the corresponding capability provider system to determine whether the request with the embedded standardized HTTP request header originates from the unified capability portal and carries a permission context. If the judgment result is that it originates from the unified capability portal and carries a permission context; Parsing module: Used by the data range adjudicator to parse the permission identifier in the standardized HTTP request header, call the local data permission query service, and the local data permission query service dynamically parses and returns the data range that can be accessed in this request by combining the synchronized permission contract and local business rules. Injection module: Used by the data range arbiter to inject the accessible data range into the subsequent business processing flow; Among them, the unified capability portal is a unified capability open platform that integrates the independent capability open platforms of multiple product lines.
9. An electronic device, characterized in that, include: Processor and memory; The processor executes a cross-platform capability opening method as described in any one of claims 1 to 7 by calling programs or instructions stored in the memory.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions that cause a computer to perform a cross-platform capability opening method as described in any one of claims 1 to 7.