Upstream and downstream platform docking method and device, electronic equipment, storage medium and computer program product

Abstract

The invention provides an upstream and downstream platform docking method and device, electronic equipment, a storage medium and a computer program product, and relates to the technical field of system docking, and the method comprises the following steps: receiving a first request; wherein the first request comprises upstream identity information; the upstream identity information is used for indicating a request source; sending a second request in response to the first request; the upstream platforms and the request data corresponding to the second request are determined in a preset set based on the upstream identity information, and the preset set comprises the upstream identity information corresponding to each upstream platform and related data; and finally completing system docking of the upstream platform and the downstream platform. Through the scheme in the embodiment of the invention, a downstream platform can support a many-to-one SSO login scene of a plurality of upstream platforms.

Description

Technical Field

[0001] This application relates to the field of system interoperability technology, and in particular to a method, apparatus, electronic device, storage medium and computer program product for interoperating upstream and downstream platforms. Background Technology

[0002] Current single sign-on technologies, such as OAuth 2.0, can enable single sign-on (SSO) scenarios from upstream platform A to downstream platform B. They can also support "one-to-many" SSO scenarios, where one upstream platform connects to multiple downstream platforms. However, when a downstream platform B needs to connect to multiple upstream platforms or multiple upstream environments, the downstream platform does not support "many-to-one" SSO scenarios, where multiple upstream platforms connect to a single downstream platform. Summary of the Invention

[0003] The embodiments of this application provide a method, apparatus, electronic device, storage medium, and computer program product for connecting upstream and downstream platforms, which can realize SSO scenarios where a downstream platform connects to multiple upstream platforms simultaneously.

[0004] The technical solution of this application is implemented as follows:

[0005] This application provides a method for connecting upstream and downstream platforms, including:

[0006] Receive a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request;

[0007] In response to the first request, a second request is sent; the upstream platform and request data corresponding to the second request are determined in a preset set based on the upstream identity information, the preset set including: the upstream identity information and related data corresponding to each upstream platform;

[0008] Finally, the system integration between the upstream and downstream platforms was completed.

[0009] In the above scheme, before responding to the first request and sending the second request, the method further includes:

[0010] Configure upstream data for the upstream platform system integration; wherein, the upstream data includes at least one of the following corresponding to the upstream platform: upstream identity information, and relevant data for system integration and subsequent processes.

[0011] In the above scheme, responding to the first request and sending the second request includes:

[0012] In response to the first request, based on the upstream identity information, the upstream platform corresponding to the second request and the corresponding request data are determined in the preset set, wherein the request data includes at least one of the following: request address, client identifier, callback address and request parameters;

[0013] The second request is sent based on the upstream platform and the request data.

[0014] In the above scheme, after responding to the first request and sending the second request, the method further includes:

[0015] The system receives a third request in response to the second request from the upstream platform; wherein the third request includes: the upstream identity information and a callback address;

[0016] In response to the third request, provide business support to the upstream platform.

[0017] In the above scheme, responding to the third request and providing business support to the upstream platform includes:

[0018] In response to the third request, a fourth request is sent to the upstream platform; wherein the fourth request includes at least one of the following corresponding to the upstream platform: request address, client identifier, client password, token interface, user interface, and callback address;

[0019] Receive the token returned by the upstream platform in response to the fourth request;

[0020] The login role corresponding to the upstream platform is determined based on the token, and business support is provided to the upstream platform based on the login role.

[0021] This application also provides a method for connecting upstream and downstream platforms, applied to an upstream platform, including:

[0022] In response to user requests, a first request is sent to the downstream platform; wherein, the first request includes: upstream identity information;

[0023] The system receives a second request from the downstream platform in response to the first request, and completes the system connection between the upstream and downstream platforms based on the second request; wherein the second request includes corresponding request data; the upstream platform and the request data are determined by the downstream platform based on the upstream identity information in a preset set; the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0024] In the above scheme, before responding to user requests and sending a first request to the downstream platform, the method further includes:

[0025] Configure downstream data for the downstream platform system; wherein the downstream data includes at least one of the following of the downstream platform: request address, client identifier, callback address, and request parameters.

[0026] In the above scheme, receiving the second request from the downstream platform in response to the first request, and completing the system connection between the upstream and downstream platforms based on the second request, includes:

[0027] The system receives the second request from the downstream platform in response to the first request; wherein the second request includes at least one of the following: request address, client identifier, callback address, and request parameters;

[0028] The second request is authenticated based on the configured downstream data, and the connection is completed.

[0029] In the above scheme, after receiving the second request from the downstream platform in response to the first request, the method further includes:

[0030] In response to the second request, a third request is sent to the downstream platform; wherein the third request includes: the upstream identity information and the callback address.

[0031] In the above scheme, after responding to the second request and sending a third request back to the downstream platform, the method further includes:

[0032] Receive a fourth request from the downstream platform in response to the third request; wherein the fourth request includes at least one of the following from the upstream platform: request address, client identifier, client password, token interface, user interface, and callback address;

[0033] In response to the fourth request, a token is sent back to the downstream platform for business support provided by the downstream platform.

[0034] This application also provides an upstream and downstream platform docking device, applied to a downstream platform, including:

[0035] A first receiving unit is configured to receive a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request;

[0036] The first sending unit is used to respond to the first request and send a second request. The upstream platform and request data corresponding to the second request are determined in a preset set based on the upstream identity information. The preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0037] The first sending unit is used to finally complete the system docking between the upstream and downstream platforms.

[0038] This application also provides an upstream and downstream platform docking device, applied to an upstream platform, including:

[0039] The second sending unit is used to respond to user requests and send a first request to the downstream platform; wherein, the first request includes: upstream identity information;

[0040] The second receiving unit is used to receive the second request fed back by the downstream platform in response to the first request, and to complete the system docking between the upstream and downstream platforms based on the second request; wherein, the second request includes corresponding request data; the upstream platform and the request data are determined by the downstream platform based on the upstream identity information in a preset set; the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0041] This application also provides an electronic device, including a first memory and a first processor. The first memory stores a computer program that can run on the first processor. When the first processor executes the computer program, it implements the steps in a method on a downstream platform side.

[0042] This application also provides an electronic device, including a second memory and a second processor. The second memory stores a computer program that can run on the second processor. When the second processor executes the computer program, it implements the steps in the method on the upstream platform side.

[0043] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a first processor, implements the steps in a method on a downstream platform side.

[0044] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a second processor, implements the steps in the method on the upstream platform side.

[0045] This application also provides a computer program product, including a computer program that, when executed by a first processor, implements the steps in a method on one side of a downstream platform.

[0046] This application also provides a computer program product, including a computer program that, when executed by a second processor, implements the steps of a method on the upstream platform side.

[0047] In this embodiment, a first request is received; the first request includes upstream identity information, which indicates the source of the request. In response to the first request, a second request is sent, whereby the upstream platform corresponding to the second request, i.e., the request data, is determined from a preset set based on the upstream identity information. The preset set includes upstream identity information and related data corresponding to each upstream platform. Finally, the system connection between the upstream and downstream platforms is completed. Thus, when multiple upstream platforms log in simultaneously, the request data corresponding to each upstream platform can be obtained from the preset set, and then a second request can be sent to each upstream platform simultaneously based on the upstream request data for login authentication. This enables the downstream platform to support a "many-to-one" SSO scenario with multiple upstream platforms. Attached Figure Description

[0048] Figure 1 An optional effect diagram of the related technology provided in the embodiments of this application;

[0049] Figure 2 An optional effect diagram of the related technology provided in the embodiments of this application;

[0050] Figure 3 An optional effect diagram of the related technology provided in the embodiments of this application;

[0051] Figure 4 An optional effect diagram of the related technology provided in the embodiments of this application;

[0052] Figure 5 This is a schematic diagram of the upstream and downstream platform docking system provided in the embodiments of this application;

[0053] Figure 6 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0054] Figure 7 An optional effect diagram of the upstream and downstream platform docking method provided in the embodiments of this application;

[0055] Figure 8 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0056] Figure 9 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0057] Figure 10 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0058] Figure 11 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0059] Figure 12 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0060] Figure 13 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0061] Figure 14 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0062] Figure 15 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0063] Figure 16 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0064] Figure 17 A schematic diagram of an optional process for the upstream and downstream platform docking method provided in the embodiments of this application;

[0065] Figure 18 An interactive schematic diagram of the upstream and downstream platform docking method provided in the embodiments of this application;

[0066] Figure 19 Schematic diagram of the upstream and downstream platform docking device provided in the embodiments of this application Figure 1 ;

[0067] Figure 20 A hardware entity illustration of an electronic device provided in the embodiments of this application. Figure 1 ;

[0068] Figure 21 Schematic diagram of the upstream and downstream platform docking device provided in the embodiments of this application Figure 2 ;

[0069] Figure 22 A hardware entity illustration of an electronic device provided in the embodiments of this application. Figure 2 . Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0071] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0072] If the application documents contain similar descriptions such as "first / second", the following explanation shall be added: In the following description, the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0073] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0074] Among the related technologies, the one involved is Single Sign-On (SSO) technology, which is also applicable to unified authentication / authorization login scenarios. SSO technology is used to enable users to log in across systems without needing to log in: such as... Figure 1 After a user (e.g., "zhangsan") logs into the *** platform's workbench, single sign-on (SSO) technology allows them to securely log in to the *** platform as the user account "zhangsan" without having to re-enter their username and password, thus enjoying the services provided. The core technology enabling this user scenario is SSO, with the most widely used protocols including OAuth 2.0 and Central Authentication Service (CAS), especially OAuth 2.0.

[0075] Current single sign-on technologies, such as OAuth 2.0, can implement single sign-on (SSO) scenarios from upstream A to downstream B, as well as "one-to-many" SSO scenarios, where one upstream connects to multiple downstreams. For example... Figure 2 OAuth2.0 implemented by A can be easily configured to redirect to multiple environment entry points and parameters of B, and can also achieve single sign-on to multiple different business platforms, enabling single sign-on integration across multiple environments.

[0076] However, this is not supported when a downstream B platform needs to connect to multiple upstream platforms or multiple upstream environments, i.e., a "many-to-one" scenario between upstream and downstream.

[0077] Similar to the "many-to-1" single sign-on scenarios described above, current single sign-on protocols and related designs cannot achieve simultaneous single sign-on with multiple upstream entities through a single interface or simple configuration. The scenarios and reasons are as follows: Figure 3 , Figure 4 As shown. Reason: Technically, Figure 3 In a "many-to-1" single sign-on scenario, the upstream platform (A / X / Y / Z) implements OAuth 2.0, while the downstream platform B is responsible for implementing the SSO integration logic and timing with the upstream platform (including SSO parameters that match the upstream configuration). Figure 4 As shown, one connection logic (SSO connection and SSO parameters) can only correspond to one upstream, meaning only one can be effective at a time. Therefore, it cannot simultaneously support "many-to-one" single sign-on scenarios.

[0078] To address the aforementioned technical problems, this application proposes an upstream and downstream platform docking system, primarily relating to downstream platform B in the diagram. For example, in conjunction with... Figure 5 Downstream platform B in this system consists of a "Configuration Management Module," a "Unified Front-End Integration Module," a "Unified Callback Integration Module," and a "Back-End Integration Module." Specifically: the "Configuration Management Module" provides configuration support for multiple upstream platforms. The "Unified Front-End Integration Module," "Unified Callback Integration Module," and "Back-End Integration Module" provide general / unified single sign-on (SSO) integration logic and dynamic support for multiple upstream platforms. Dynamic parameters are carried during upstream and downstream interaction requests (including menu link configuration) at each stage of SSO, enabling simultaneous "many-to-one" SSO support for multiple upstream platforms.

[0079] I. Integration with the configuration management module:

[0080] The configuration management module is responsible for managing and configuring data related to multiple upstream services / platforms: environment identity and parameter information. This includes, but is not limited to, upstream product identifiers, environment identifiers, request addresses, request parameters, interface addresses, callback addresses, etc., which are summarized into two categories:

[0081] Upstream product and system environment parameters: Upstream product identifiers, environment identifiers, etc. are used to identify upstream products and system environments, and product environment parameters are kept unique.

[0082] II. Unified front-end interface module:

[0083] This module provides services to external users. For example, if a menu entry for downstream platform B is configured in upstream platform A, the services provided by this module will be requested when a user triggers an action.

[0084] This module is responsible for initiating single sign-on requests to the upstream system. In a "many-to-one" single sign-on scenario, it is a common module, specifically:

[0085] Identify which upstream system initiated the request based on the parameters in the request (product and environmental parameters, etc.).

[0086] The "Backend Integration Module" retrieves the SSO request parameters for the corresponding upstream product environment from the "Integration Configuration Management Module" and initiates an SSO request.

[0087] SSO request parameters include, but are not limited to, the request parameters contained in the SSO protocol (such as the OAuth protocol), such as the request address, request parameters, interface address, callback address, etc. in Table 1.

[0088] III. Backend Integration Module:

[0089] This module is responsible for implementing the SSO integration logic with the upstream platform environment (including integration requests and all OAuth single sign-on related timing). In "many-to-one" single sign-on scenarios, it is a common module. The logic it handles includes, but is not limited to:

[0090] 1. Based on the upstream platform environment that initiated the SSO request, obtain the corresponding SSO request parameters and return them to the unified front-end integration module.

[0091] 2. Based on the user login authentication result, initiate requests for token acquisition, user information acquisition, and resource acquisition from the corresponding upstream platform environment.

[0092] IV. Unified Callback Integration Module:

[0093] This module provides services to external parties.

[0094] In OAuth integration, after the upstream platform system is responsible for OAuth user login authentication, it initiates access to this callback module. Through the callback module:

[0095] The services provided to users are redirected to downstream platforms (such as B), whereby B provides the services to users.

[0096] Support downstream platforms (B) to continue executing subsequent OAuth integration logic, such as obtaining tokens, user information, and resources through the "backend integration module".

[0097] That is, based on the product and / or environment parameters requested when the upstream platform (such as A1) initiates a callback, the interface address and other required addresses and parameters of the corresponding upstream platform (A1) are obtained from the interface configuration module, and subsequent related requests with the upstream SSO are initiated.

[0098] Ultimately, downstream platform B obtains user information and related resource information and provides services to that user. In a "many-to-one" single sign-on scenario, the "unified callback integration module" is a common module.

[0099] V. Menu entry points on the upstream platform:

[0100] "Menu entry" refers to the entry point configured in the upstream system environment for users to log in to the downstream system via single sign-on, such as a menu, and generally refers to user entry points.

[0101] Specifically, in this proposal, the menu entry configuration includes, but is not limited to, the following:

[0102] The menu configuration directly requests services provided by the "Unified Front-End Integration Module," and directly requests services such as... Figure 6 The address urlB shown is shown.

[0103] The menu configuration indirectly requests services provided by the "Unified Front-End Integration Module," first requesting a service from the upstream system, and then requesting... Figure 6 The address urlB shown is shown.

[0104] Example of a URLB request:

[0105] Request the service URLB provided by the "Unified Front-end Integration Module".

[0106] It includes parameters related to upstream systems and / or environments (such as A1), such as "Upstream Product Identifier" and "Upstream Environment Identifier" in Table 1.

[0107] urlB? appid=appid_1&env=dev

[0108] Alternatively, configurations from upstream and downstream systems can be manually obtained, and requests can be made directly. Figure 6 The S300B carries the necessary upstream and downstream data.

[0109] VI. Auxiliary Explanation of Upstream System Modules:

[0110] Combination Figure 5 The upstream platform refers to A1, A2, and A3. A brief explanation of the upstream system modules follows; all modules are OAuth-related business modules:

[0111] OAuth protocol module: Implements the content, timing, and functions of OAuth-related protocols, such as the OAuth 2.0 protocol.

[0112] OAuth configuration module: OAuth Client related configuration information, such as downstream system B, which exists as a client of upstream system A1.

[0113] Among them, the OAuth protocol module and the OAuth configuration module are standard modules related to OAuth.

[0114] For example, Table 1 illustrates the configuration of downstream data for downstream platform B in A1:

[0115] client_id client_secret redirect_uri …… client_id_1 client_secret_1 redirect_uri_1 ……

[0116] Table 1

[0117] For example, Table 2 illustrates the configuration of downstream data for downstream platform B in A2:

[0118] client_id client_secret redirect_uri …… client_id_2 client_secret_2 redirect_uri_2 ……

[0119] Table 2

[0120] In other words, downstream platform B may have different identities in upstream platforms A1 and A2, but they may also be the same if A1 and A2 belong to the same product. The client_id, client_secret, and redirect_uri in the upstream platforms must be matched with their configurations; otherwise, OAuth single sign-on will fail due to identity verification failure.

[0121] In this embodiment of the application, the following is achieved: Many-to-one configuration is supported: a "connection configuration management module" is introduced to configure and manage the configurations of multiple upstream entities, supporting "many-to-one" configuration; simultaneously, mutual security authentication between upstream and downstream entities is implemented.

[0122] In terms of business logic, it supports many-to-1 relationships: By introducing dynamic parameters into various interaction links and modules in the upstream and downstream of single sign-on, and adopting a unified interface logic and dynamic parameters, it can process requests based on "dynamic upstream" requests and return to the corresponding "dynamic upstream," ultimately achieving dynamic single sign-on that can support multiple simultaneous logins. It supports "many-to-1" relationships in business logic.

[0123] Ultimately, it can not only solve the problem of single point of connection for "the same product in multiple different environments", but also the problem of single point of connection for "multiple different products" and the problem of single sign-on for "multiple different products in different environments", that is, it can simultaneously support "many to one" single sign-on for multiple upstream product environments.

[0124] This proposal suggests a system that supports "many-to-1" single sign-on, along with the corresponding integration method. The proposed configuration, business logic, and business modules are based on a B / S architecture, and interface interactions and parameters can be easily obtained through browser requests and request parameters.

[0125] This application provides a method for connecting upstream and downstream platforms. Please refer to [link / reference]. Figure 6This is an optional flowchart illustrating the upstream and downstream platform integration method provided in this application embodiment, which will be combined with... Figure 6 The steps shown are explained below:

[0126] S101. Receive a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request.

[0127] In this embodiment, the upstream platform responds to a user's request by sending a first request (single sign-on request) to the downstream platform. The first request includes upstream identity information corresponding to the upstream platform. This upstream identity information indicates the source of the request; it includes at least one of the following: an upstream platform identifier, an upstream platform name, and an upstream environment identifier. In this embodiment, multiple upstream platforms may also send the first request to the downstream platform, each including upstream identity information corresponding to its upstream platform.

[0128] Among them, multiple upstream platforms can include multiple upstream platforms of the same product in different environments, or upstream platforms of different products, or multiple upstream platforms of different products in different environments.

[0129] S102. In response to the first request, send a second request; the upstream platform and request data corresponding to the second request are determined in a preset set based on the upstream identity information, the preset set including: the upstream identity information and related data corresponding to each upstream platform.

[0130] In this embodiment, the downstream platform can pre-configure a preset set. The preset set includes: upstream identity information corresponding to each upstream platform and relevant data for system integration and subsequent processes. After receiving a first request, the downstream platform can determine the source of the first request—the upstream platform—and the corresponding request data from the preset set based on the upstream identity information. Then, based on the upstream platform and the request data, a second request is sent. The request data includes at least one of the following: a request address, a client identifier, a callback address, and request parameters.

[0131] In this embodiment, before receiving the first request, a preset set can obtain the upstream identity information and corresponding related data for each upstream platform. The preset set is constructed based on the upstream identity information and corresponding related data for each upstream platform. Downstream data is used to characterize the request parameters configured by the downstream platform in its corresponding upstream platform. The downstream data includes the following parameters configured by the downstream platform in different upstream platforms: request address, client identifier, client password, and callback address.

[0132] In this embodiment, after receiving multiple first requests from multiple upstream platforms, the downstream platform can determine the source of each first request—the upstream platform—and the corresponding request data for each upstream platform from a preset set based on the identity information of each upstream platform. Then, based on the upstream platform and the request data, it sends a second request to the corresponding upstream platform.

[0133] In this embodiment of the application, combined with Figure 7 S300A, the downstream platform determines the SSO / OAuth parameters corresponding to the upstream platform environment from a preset set based on any one of the upstream platform identifier, upstream platform name, and upstream environment identifier in the first request, including but not limited to the request data contained in the SSO protocol.

[0134] S103. Finally, complete the system integration between the upstream and downstream platforms.

[0135] In this embodiment, the downstream platform can send a second request (authentication request) to the upstream platform based on the request data corresponding to the upstream platform. After receiving the second request, the upstream platform can complete the authentication of the downstream platform based on the request data included in the second request, thereby realizing system integration with the downstream platform.

[0136] For example, in combination Figure 7 In S300B, downstream platform B can send an OAuth request (second request) to each upstream platform (A1 to A3). The OAuth request carries the correct OAuth request parameters (request data) and initiates the OAuth request. After receiving the request, the upstream platform completes the user login authentication process.

[0137] In this embodiment of the application, after the upstream platform completes the authentication of the downstream platform, it can send a third request to the downstream platform based on the callback address in the request data to call back the corresponding resources and services.

[0138] Please see Figure 8 This is an optional flowchart illustrating the upstream and downstream platform integration method provided in this application embodiment, and will be explained in conjunction with the steps shown:

[0139] S11, Configuration.

[0140] In this embodiment, different upstream platforms register and / or configure themselves on downstream platforms, including but not limited to "upstream product and system environment parameters" and "SSO / OAuth integration request related data." The upstream platform configures the menu entry and settings for SSO to the downstream platform, and can directly or indirectly send the first request "Unified Front-End Integration Module" through the menu entry. This request includes a request address (the unified front-end integration module request address, such as urlB), product and / or environment parameters. Parameters may include the downstream platform's client_id and other identity information in A1, as well as parameters required for OAuth, to authenticate the downstream platform's identity in subsequent integration requests.

[0141] S12. The upstream triggers single sign-on, carrying information such as upstream product and / or environmental parameters.

[0142] In this embodiment, the upstream platform triggers a single sign-on to the downstream platform, requesting services provided by the "unified front-end interface module" and carrying information such as upstream product and / or environmental parameters.

[0143] S13. The downstream initiates the first request to the corresponding upstream based on the parameters (optionally, through a unified front-end module).

[0144] In this embodiment, the downstream platform obtains the corresponding parameters from the requester: B's "Unified Front-End Access Module" obtains the SSO / OAuth parameters corresponding to the upstream platform and environment from B's "Interface Configuration Management Module" based on the requested product and / or environment parameters. These parameters include, but are not limited to, the request parameters contained in the SSO protocol. Based on the obtained SSO / OAuth parameters from the upstream platform, the downstream platform initiates an OAuth request to the upstream platform: the "Unified Front-End Interface Module" carries the correct OAuth request parameters and initiates the OAuth request. After receiving the request, the upstream system completes the user login authentication process.

[0145] S14. After the upstream completes the user login authentication process, it initiates a callback to the downstream, carrying information such as upstream product and / or environmental parameters.

[0146] In this embodiment, after the upstream platform completes the user login authentication process, it initiates a callback to the downstream, carrying information such as upstream product and / or environmental parameters, as well as the callback address.

[0147] S15. The downstream system completes the subsequent process based on the corresponding parameters (optionally, through a backend interface module) to achieve single sign-on.

[0148] In this embodiment, the downstream platform's "unified callback docking module" obtains the request interface address and parameters corresponding to the product and / or environment based on the different product environment parameters of the request, and makes subsequent OAuth requests, such as token requests, obtaining user information and resource information, to complete the entire single sign-on process (OAuth single sign-on includes authorization requests (determining the login stage, authorization stage), token requests, user information requests, resource requests, etc. For details, please refer to the publicly known OAuth protocol in Chapter 11).

[0149] In this embodiment, a first request is received from multiple upstream platforms. Each first request includes upstream identity information corresponding to each upstream platform. In response to the first request, request data corresponding to each upstream platform is determined from a preset set based on the upstream identity information. The preset set includes upstream identity information and related data corresponding to different upstream platforms. A second request is sent to each upstream platform based on the upstream request data, allowing each upstream platform to complete login integration with the downstream platform. Thus, when multiple upstream platforms log in simultaneously, the request data corresponding to each upstream platform can be obtained from the preset set, and then a second request can be sent to each upstream platform simultaneously based on the request data for login authentication, thereby enabling the downstream platform to support a "many-to-one" SSO scenario.

[0150] Please see Figure 9 This is a schematic diagram of an optional process for the upstream and downstream platform integration method provided in the embodiments of this application. Figure 6 The steps shown in the diagram may include S201 to S202, which will be explained in conjunction with the steps shown:

[0151] S201. Configure upstream data for the upstream platform system connection; wherein, the upstream data includes at least one of the following corresponding to the upstream platform: upstream identity information, and relevant data for system connection and subsequent processes.

[0152] In this embodiment, the downstream platform can obtain the upstream identity information of each upstream platform, as well as relevant data for system integration and subsequent processes, through the corresponding interfaces of each upstream platform or human-computer interaction devices. The downstream platform then constructs a preset set based on the correspondence between each upstream platform and its corresponding upstream identity information and relevant data. The upstream identity information includes at least one of the following: upstream platform identifier, upstream platform name, and upstream environment identifier; the relevant data includes at least one of the following: request address, client identifier, client password, callback address, token interface, and user interface.

[0153] For example, in combination Figure 7S100 A Integration Configuration: The upstream product environment is registered and / or configured in the downstream platform B, including but not limited to "upstream platform identifier, upstream platform name and upstream environment identifier", and "SSO / OAuth integration request related data: request address, client identifier, client password, token interface, user interface and callback address".

[0154] For example, the structure of the preset set can be illustrated by Table 3: the upstream platforms may include A1, A2, and A3. The request parameters for each upstream platform may include: client identifier (client_id) and client password (client_secret). The interface for each upstream platform may include: a token interface and a user interface.

[0155]

[0156]

[0157] Table 3

[0158] In this embodiment, upstream data is configured for system integration with the upstream platform. This upstream data includes at least one of the following corresponding to the upstream platform: the upstream identity information, and relevant data for system integration and subsequent processes. Thus, when multiple upstream platforms log in simultaneously, request data corresponding to each upstream platform can be obtained from a preset set. Then, based on the request data, a second request is sent to each upstream platform for login authentication, thereby enabling the downstream platform to support a "many-to-one" SSO scenario involving multiple upstream platforms.

[0159] Please see Figure 10 This is a schematic diagram of an optional process for the upstream and downstream platform integration method provided in the embodiments of this application. Figure 6 The illustrated S102 can also be implemented via S301 to S302, which will be explained in conjunction with the illustrated steps:

[0160] S301. In response to the first request, based on each upstream identity information in a preset set, determine the upstream platform corresponding to the second request and the corresponding request data; wherein, the request data includes at least one of the following: request address, client identifier, callback address and request parameters.

[0161] In this embodiment of the application, the downstream platform responds to the first request and, based on the upstream identity information, determines the upstream platform corresponding to the target of the second request in a preset set, as well as the request data corresponding to the upstream platform. The request data includes at least one of the following: request address, client identifier, callback address, and request parameters.

[0162] In this embodiment, when a downstream platform receives first requests from multiple upstream platforms, the downstream platform can send a second request to each upstream platform based on the request address, client identifier, callback address, and request parameters in the request data corresponding to each upstream platform. This allows each upstream platform to authenticate the downstream platform and complete system integration.

[0163] S302. Send the second request based on the upstream platform and the request data.

[0164] In this embodiment of the application, the downstream platform can send a second request to the upstream platform based on the determined address of the upstream platform and the request data.

[0165] In this embodiment, in response to the first request, based on the upstream identity information, the upstream platform corresponding to the first request and at least one of the following is determined from a preset set: request address, client identifier, callback address, and request parameters. In this way, the downstream platform can determine the upstream platform of the first request based on the upstream identity information in the first request, and determine the request data corresponding to that upstream platform from the preset set, thereby achieving many-to-one login authentication.

[0166] Please see Figure 11 This is a schematic diagram of an optional process for the upstream and downstream platform integration method provided in the embodiments of this application. Figure 6 The steps shown in S103 may be followed by S401 to S402, which will be explained in conjunction with the steps shown:

[0167] S401. Receive the third request from the upstream platform in response to the second request; wherein the third request includes: the upstream identity information and the callback address.

[0168] In this embodiment, since the second request includes a callback address, the upstream platform can send a third request (callback request) to the downstream platform based on the callback address. The third request is used to request callback resources or services from the downstream platform. The third request includes the upstream identity information of the corresponding upstream platform and the callback address. The upstream identity information may include: upstream platform identifier, upstream platform name, and upstream environment identifier.

[0169] For example, in combination Figure 7 After the upstream S400 platform completes the user login authentication process, it initiates a callback to the downstream platform, carrying information such as upstream product and / or environment parameters. That is, after successful OAuth user login authentication on upstream platform A1, it executes an OAuth third-party request to downstream system B, including the callback address callbackB, and the callback parameters contain upstream product and / or environment information.

[0170] S402. In response to the third request, provide business support to the upstream platform.

[0171] In this embodiment of the application, the downstream platform responds to the third request, obtains the token corresponding to the upstream platform based on the upstream data corresponding to the upstream platform, determines the login role corresponding to each upstream platform based on the user information contained in the token, and provides business support to each upstream platform based on the login role.

[0172] In this embodiment, a third request is received from an upstream platform in response to a second request. The third request includes the upstream platform's upstream identity information and callback address. The response to the third request provides business support to the upstream platform. Thus, after the upstream platform authenticates the downstream application, it can use the third request to call back the corresponding resources to provide services to the user.

[0173] Please see Figure 12 This is a schematic diagram of an optional process for the upstream and downstream platform integration method provided in the embodiments of this application. Figure 11 The illustrated S402 can also be implemented via S501 to S503, which will be explained in conjunction with the illustrated steps:

[0174] S501. In response to the third request, send a fourth request to the upstream platform.

[0175] In this embodiment of the application, the downstream platform responds to the third request and, based on the upstream identity parameters corresponding to the upstream platform, determines at least one of the following corresponding to the upstream platform from a preset set: request address, client identifier, client password, token interface, user interface, and callback address, and sends a fourth request (interface request) to the upstream platform based on the determined parameters.

[0176] S502. Receive the token returned by the upstream platform in response to the fourth request.

[0177] In this embodiment of the application, after receiving the fourth request, the upstream platform can send the token of the currently logged-in user back to the downstream platform.

[0178] S503. Determine the login role corresponding to the upstream platform based on the token, and provide business support to the upstream platform based on the login role.

[0179] In this embodiment, the downstream platform can analyze the token to determine the login role corresponding to the upstream platform. Based on the login role, the downstream platform provides corresponding resources to each upstream platform, allowing the upstream platform to load the corresponding services on the front end.

[0180] In this embodiment, in response to the third request, a fourth request is sent to the upstream platform. The token returned by the upstream platform in response to the fourth request is received. Based on the token, the login role corresponding to the upstream platform is determined, and business support is provided to each upstream platform based on the login role. Thus, after the upstream platform successfully authenticates the downstream user, it can use the third request to call back the corresponding resources to provide services to the user.

[0181] Please see Figure 13 This is an optional flowchart illustrating the upstream and downstream platform integration method provided in this application embodiment, and will be explained in conjunction with the steps shown:

[0182] S601. In response to user requests, a first request is sent to the downstream platform; wherein the first request includes: upstream identity information.

[0183] In this embodiment, the upstream platform's front-end can provide a login portal for the downstream platform. In response to a user's login request, the upstream platform sends a first request to the downstream platform. This first request includes the upstream platform's corresponding upstream identity information.

[0184] The login entry can be configured with the request address of the corresponding downstream platform, such as the Uniform Resource Locator (URL) of the downstream platform.

[0185] S602. Receive the second request from the downstream platform in response to the first request, and complete the system docking between the upstream and downstream platforms based on the second request; wherein, the second request includes corresponding request data; the upstream platform and the request data are determined by the downstream platform based on the upstream identity information in a preset set; the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0186] In this embodiment, after receiving the first request, the downstream platform can determine the upstream platform corresponding to the second request and the corresponding request data of the upstream platform from a preset set based on the upstream identity information therein. The downstream platform sends the second request to the upstream platform based on the request data. The upstream platform receives the second request fed back by the downstream platform in response to the first request, and completes the system docking between the upstream and downstream platforms based on the second request; wherein, the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0187] The upstream identity information includes at least one of the following: upstream platform identifier, upstream platform name, and upstream environment identifier; the request data includes at least one of the following: request address, client identifier, callback address, and request parameters.

[0188] In this embodiment, in response to user requests, a first request is sent to the downstream platform. This first request includes the upstream platform's corresponding upstream identity information. A second request is received from the downstream platform in response to the first request, and system integration between the upstream and downstream platforms is completed based on the second request. This second request includes corresponding request data, which is determined by the downstream platform from a preset set based on the upstream identity information. The preset set includes the upstream identity information and related data corresponding to each upstream platform. Thus, when multiple upstream platforms log in simultaneously, the downstream platform can obtain the request data corresponding to each upstream platform from the preset set, and then simultaneously send a second request to each upstream platform for login authentication based on the request data. This enables the downstream platform to support a "many-to-one" SSO scenario with multiple upstream platforms.

[0189] Please see Figure 14 This is an optional flowchart illustrating the upstream and downstream platform integration method provided in this application embodiment, and will be explained in conjunction with the steps shown:

[0190] S603. Configure downstream data for the downstream platform system; wherein the downstream data includes at least one of the following: request address, client identifier, callback address, and request parameters.

[0191] In this embodiment, the upstream platform can obtain downstream data from the downstream platform through the downstream platform's interface or a human-interactive device for system integration configuration. The downstream data includes at least one of the following configured by the downstream platform in the upstream platform: request address, client identifier, callback address, and request parameters. Specifically, the downstream request data may include: request address, client_id, and redirect_uri.

[0192] For example, in combination Figure 7 S100B, the menu entry and configuration for SSO to the downstream platform in the upstream platform, can directly or indirectly trigger a request to the "Unified Front-end Integration Module" through the menu entry. This request includes the request address (the unified front-end integration module request address, such as urlB), product and / or environment parameters. Optionally, the parameters may include the downstream platform's client_id and other identity information in A1, as well as the parameters required for OAuth, so as to authenticate the downstream platform's identity in subsequent integration requests.

[0193] In this embodiment, downstream data corresponding to the downstream platform is obtained and configured. Thus, after receiving the second request, the parameters in the second request can be authenticated using the downstream data configured on the upstream platform.

[0194] Please see Figure 15This is a schematic diagram of an optional process for the upstream and downstream platform integration method provided in the embodiments of this application. Figure 13 The S602 shown can also be implemented via S701 to S702, which will be explained in conjunction with the steps shown:

[0195] S701, Receive the second request fed back by the downstream platform in response to the first request.

[0196] In this embodiment of the application, the upstream platform receives a second request from the downstream platform in response to the first request.

[0197] The second request includes at least one of the following: a request address, a client identifier, a callback address, and request parameters.

[0198] S702. Authenticate the second request based on the configured downstream data to complete the connection.

[0199] In this embodiment of the application, the upstream platform can authenticate the request address, the client identifier, the callback address, and the request parameters in the second request based on the downstream data of the pre-configured downstream platform, and complete the login integration.

[0200] In this embodiment, the second request is received from the downstream platform in response to the first request. The downstream platform is authenticated based on the request address, the client identifier, the callback address, and the configured downstream data to complete the login connection. Thus, by configuring downstream data on different upstream platforms, each upstream platform, upon receiving the second request, can match and authenticate the parameters in the second request using the configured downstream data, thereby enabling login connection from multiple upstream platforms to a single downstream platform.

[0201] Please see Figure 16 This is an optional flowchart illustrating the upstream and downstream platform integration method provided in this application embodiment, and will be explained in conjunction with the steps shown:

[0202] S801, respond to the second request and send a third request to the downstream platform.

[0203] In this embodiment of the application, the second request includes a callback address, and the upstream platform sends a third request to the downstream platform based on the callback address and the corresponding upstream identity information.

[0204] The third request includes the upstream identity information and callback address of the corresponding upstream platform.

[0205] Please see Figure 17 This is a schematic diagram of an optional process for the upstream and downstream platform integration method provided in the embodiments of this application. Figure 16S801 may be followed by S802 to S803, which will be explained in conjunction with the steps shown:

[0206] S802, Receive the fourth request from the downstream platform in response to the third request.

[0207] In this embodiment of the application, the downstream platform responds to the third request and sends a fourth request to the upstream platform based on the upstream identity information of the upstream platform.

[0208] The fourth request includes at least one of the following: the request address, client identifier, client password, token interface, user interface, and callback address corresponding to the upstream platform.

[0209] S803. In response to the fourth request, a token is sent back to the downstream platform for the downstream platform to provide business support.

[0210] In this embodiment, the upstream platform responds to the fourth request by sending the token of the currently logged-in user to the downstream platform. The downstream platform can analyze the token to determine the role of the currently logged-in user and provide corresponding resources to the upstream platform based on the role, allowing the upstream platform to load the corresponding services on the front end.

[0211] In this embodiment, the upstream platform responds to the second request and sends a third request back to the downstream platform. It then receives a fourth request from the downstream platform in response to the third request. Finally, it responds to the fourth request and sends a token back to the downstream platform, receiving the service support provided by the token. Thus, after authentication is complete, the corresponding resources can be obtained through the third request to provide services to the user.

[0212] The solution in this application will now be described in detail with reference to an embodiment:

[0213] Upstream platforms: Upstream platforms for the same product in multiple environments: A1 and A2.

[0214] S100: Configuration.

[0215] S100A Integration Configuration: Configure the "Integration Configuration Management Module" in the downstream platform, which includes the upstream identity information (upstream platform name, upstream platform identifier, and upstream environment identifier) ​​of upstream platforms A1 and A2. At this time, the client_id, client_secret, and callback address in the OAuth configuration modules of the two upstream platforms are as shown in Table 4.

[0216]

[0217]

[0218] Table 4

[0219] S100B Menu Configuration:

[0220] In this example, the upstream menu entry is directly configured to connect to the unified front-end service of the downstream platform:

[0221] 1) Menu entry configuration for upstream platform A1 for downstream platform:

[0222] https: / / hdc-alpha.cdcyy.cn / sso?appid=appid_OneHealth&env=xiyun

[0223] 2) Configuration of menu entry point for downstream platform on upstream platform A2:

[0224] https: / / hdc-alpha.cdcyy.cn / sso?appid=appid_OneHealth&env=yidongyun

[0225] S200: Upstream triggers single sign-on to downstream:

[0226] Users click the menu entry in the front end of the upstream platform A1 to execute an SSO request: https: / / hdc-alpha.cdcyy.cn / sso?appid=appid_OneHealth&env=xiyun.

[0227] S 300: The downstream initiates a single sign-on request to the corresponding upstream based on the parameters.

[0228] S 300A: Obtain the corresponding parameters based on the requester.

[0229] The downstream platform's "Unified Front-End Access Module" obtains the corresponding upstream OAuth request parameters based on the requested product environment parameters appid and env: Request address: oh-xy.cdcyy.cn; client_id: cmcc-heath_1; Callback address: hdc-alpha.cdcyy.cn / cb.

[0230] S 300B: Initiate an OAuth request to the corresponding upstream.

[0231] Based on the above OAuth request parameters, the downstream platform's "Unified Front-End Integration Module" initiates an OAuth request to the upstream platform A1 as follows:

[0232] https: / / oh-xy.cdcyy.cn / oauth / authorize?client_id=

[0233] cmcc-heath_1&response_type=code&redirect_uri=hdc-alpha.cdcyy.cn / cb&scope=get_user_info.

[0234] S 400: The upstream sends a callback request carrying product and / or environmental parameters.

[0235] After the upstream platform completes user login authentication via / oauth / authorize, taking the authorization code mode as an example, it generates an authorization code and sends a callback to China Mobile Health.

[0236] https: / / hdc-alpha.cdcyy.cn / cb?code=ig2ce0&appid=appid_OneHealth&env=xiyun

[0237] S 500: OAuth Authorization and Subsequent Processes:

[0238] After receiving the callback request, the downstream platform retrieves the corresponding OAuth request parameters based on the requested product environment parameters: Request address: oh-xy.cdcyy.cn; client_id: cmcc-heath_1; client_secret: cmcc-heath_secret_1; Callback address: hdc-alpha.cdcyy.cn / cb; Token interface: / auth / oauth / token; User interface: / admin / getUserInfo;

[0239] The downstream platform completes the subsequent SSO process, such as:

[0240] 1) Send a POST request (interface request) to the upstream platform, carrying the above parameters:

[0241] MultiValueMap<String,String> map=new LinkedMultiValueMap<>();

[0242] map.add(k:"code",code);

[0243] map.add(k:"client_id",v:"cmcc-heath_1");

[0244] map.add(k:"client_secret",v:"cmcc-heath_secret_1");

[0245] map.add(k:"redirect_uri",v:"hdc-alpha.cdcyy.cn / cb");

[0246] map.add(k:"grant_type",v:"authorization_code");

[0247] map.add(k:"scope",v:"get_user_info");

[0248] Map<String,String> resp=restTemplate.postForObject(url:HOST+" / auth / oauth / token",map,Map.class);

[0249] System.out.println(resp);

[0250] access_token=resp.get("access_token");

[0251] Returns the access_token.

[0252] 2) The downstream platform uses the access_token to request the currently logged-in user information from the upstream platform:

[0253]

[0254] The downstream platform obtains the currently logged-in user as zhangsan and the role as super administrator, and then loads the corresponding services for the upstream platform A1 in the downstream platform based on the username and role.

[0255] The solution in this application will now be described in detail with reference to an embodiment:

[0256] The upstream platforms include: A3 and A4, which are upstream platforms for multiple different products.

[0257] S100: Configuration.

[0258] S100A Integration Configuration: Configure the "Integration Configuration Management Module" on the downstream platform, including upstream product parameters. Environment parameters are optional. At this time, the downstream parameters of the downstream platform in the two upstream platforms are as shown in Table 5: client_id, client_secret, and callback address.

[0259]

[0260] Table 5

[0261] S100B Menu Configuration:

[0262] In this example, the menu entry point of the upstream platform is directly configured to connect to the unified front-end service of the downstream platform:

[0263] 1) Menu entry configuration for upstream platform A3:

[0264] https: / / hdc.gz.com / sso?appid=appid_OneHealth

[0265] 2) Menu entry configuration for upstream platform A4:

[0266] https: / / hdc.gz.com / sso?appid=appid_portal

[0267] S200: Upstream triggers single sign-on to downstream:

[0268] When a user clicks a menu entry on the upstream platform A4's customer portal website, an SSO request is executed: https: / / / hdc.gz.com / sso?appid=appid_portal.

[0269] S 300: The downstream initiates a single sign-on request to the corresponding upstream based on the parameters.

[0270] S 300A: Obtain the corresponding parameters based on the requester.

[0271] The downstream platform's "Unified Front-End Access Module" retrieves the corresponding upstream OAuth request parameters based on the requested product environment parameter appid: Request address: portal.gz.com; client_id: cmcc-heath; Callback address: hdc.gz.com / cb;

[0272] S 300B: Initiate an OAuth request to the corresponding upstream.

[0273] Based on the above OAuth request parameters, the downstream platform's "Unified Front-End Integration Module" initiates an OAuth request to the upstream platform A4 as follows:

[0274] https: / / portal.gz.com / oauth / authorize?client_id=

[0275] cmcc-heath&response_type=code&redirect_uri=hdc.gz.com / cb&scope=get_user_info

[0276] S 400: The upstream provider initiates a callback request, carrying product and / or environmental parameters.

[0277] After the upstream platform completes user login authentication via / oauth / authorize, taking the authorization code mode as an example, it generates an authorization code and sends a callback to China Mobile Health.

[0278] https: / / hdc.gz.com / cb?code=PYUgsT&appid=appid_portal

[0279] S 500: OAuth Authorization and Subsequent Processes:

[0280] After receiving the callback request, the downstream platform retrieves the corresponding OAuth request parameters based on the requested product parameters: Request address: portal.gz.com; client_id: cmcc-heath; client_secret: cmcc-heath_secret_1; Callback address: hdc.gz.com / cb; Token interface: / auth / oauth / token; User interface: / resource / getUserInfo

[0281] The downstream platform completes the subsequent SSO process, such as:

[0282] 1) The downstream platform uses a POST request to send a token, carrying the above parameters:

[0283] URL: https: / / portal.gz.com / auth / oauth / token

[0284] parameter:

[0285] client_id:cmcc-heath

[0286] client_secret:cmcc-heath_secret_1

[0287] redirect_uri: hdc.gz.com / cb

[0288] Returns the access_token.

[0289] 2) The downstream platform uses the access_token to request the currently logged-in user information: it obtains that the currently logged-in user is zhangsan and the role is super administrator, and then loads the corresponding services for the user in the China Mobile Health System.

[0290] Please see Figure 18This is an interactive schematic diagram of the upstream and downstream platform docking method provided in the embodiments of this application.

[0291] S901, The downstream platform receives a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request.

[0292] In this embodiment, the implementation steps in S901 can be referred to S101, and will not be described in detail here.

[0293] S902. The downstream platform responds to the first request and sends a second request; the upstream platform corresponding to the second request, i.e., the requested data, is determined in a preset set based on the upstream identity information, and the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0294] In this embodiment, the implementation steps in S902 can be referred to S102, and will not be described in detail here.

[0295] S903 and the downstream platform finally complete the system docking between the upstream and downstream platforms.

[0296] In this embodiment, the implementation steps in S903 can be referred to S103, and will not be described in detail here.

[0297] Please see Figure 19 This is a schematic diagram of the structure of the upstream and downstream platform docking device provided in the embodiments of this application. Figure 1 .

[0298] This application embodiment also provides an upstream and downstream platform docking device 600, including a first receiving unit 601 and a first sending unit 602.

[0299] The first receiving unit 601 is configured to receive a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request;

[0300] The first sending unit 602 is used to respond to the first request and send a second request; the upstream platform and request data corresponding to the second request are determined in a preset set based on the upstream identity information, and the preset set includes: the upstream identity information and related data corresponding to each upstream platform;

[0301] The first sending unit 602 is used to finally complete the system docking between the upstream and downstream platforms.

[0302] In this embodiment of the application, the upstream and downstream platform docking device 600 is used to configure upstream data for the docking of the upstream platform system; wherein, the upstream data includes at least one of the following corresponding to the upstream platform: the upstream identity information, and relevant data for system docking and subsequent processes.

[0303] In this embodiment, the first sending unit 602 in the upstream and downstream platform docking device 600 is used to respond to the first request, and based on the upstream identity information, determine the upstream platform corresponding to the second request and the corresponding request data from a preset set. The request data includes at least one of the following: request address, client identifier, callback address, and request parameters. The second request is then sent based on the upstream platform and the request data.

[0304] In this embodiment of the application, the first receiving unit 601 in the upstream and downstream platform docking device 600 is used to receive the third request fed back by each of the upstream platforms in response to the second request; wherein, the third request includes the upstream identity information and callback address of the corresponding upstream platform;

[0305] In response to the third request, provide business support to the upstream platform.

[0306] In this embodiment, the first sending unit 602 in the upstream and downstream platform docking device 600 is used to respond to the third request and send a fourth request to each of the upstream platforms; wherein each of the fourth requests includes at least one of the following for each upstream platform: request address, client identifier, client password, token interface, user interface, and callback address; the first receiving unit 601 in the upstream and downstream platform docking device 600 is used to receive the token fed back by each upstream platform in response to the fourth request; determine the login role corresponding to each upstream platform based on the token, and provide business support to the upstream platform based on the login role.

[0307] It should be noted that, in the embodiments of this application, if the above-described item information processing method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an item information processing device (which may be a personal computer, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0308] Correspondingly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in a method on a downstream platform side.

[0309] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0310] It should be noted that, Figure 20 A hardware entity illustration of an electronic device provided in the embodiments of this application. Figure 1 ,like Figure 20 As shown, this application embodiment provides an electronic device 700, including a first memory 702 and a first processor 701. The first memory 702 stores a computer program that can run on the first processor 701. When the first processor 701 executes the program, it implements the steps in the above-described method, wherein;

[0311] The first processor 701 typically controls the overall operation of the electronic device 700.

[0312] The first memory 702 is configured to store instructions and applications executable by the first processor 701, and can also cache data to be processed or already processed by the first processor 701 and various modules in the electronic device 700 (e.g., image data, audio data, voice communication data and video communication data), which can be implemented by flash memory or random access memory (RAM).

[0313] Correspondingly, this application also provides a computer program product, including a computer program that can be executed by the processor 701 of the electronic device 700 to complete the steps in the method of the upstream and downstream platform docking device 600.

[0314] Please see Figure 21 This is a schematic diagram of the structure of the upstream and downstream platform docking device provided in the embodiments of this application. Figure 2 .

[0315] This application embodiment also provides an upstream and downstream platform docking device 800, applied to an upstream platform, including: a second sending unit 801 and a second receiving unit 802.

[0316] The second sending unit 801 is used to respond to user requests and send a first request to the downstream platform; wherein, the first request includes: upstream identity information;

[0317] The second receiving unit 802 is used to receive the second request fed back by the downstream platform in response to the first request, and to complete the system docking of the upstream and downstream platforms based on the second request; wherein, the second request includes corresponding request data; the upstream platform and the request data are determined by the downstream platform based on the upstream identity information in a preset set; the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

[0318] In this embodiment of the application, the second receiving unit 802 in the upstream and downstream platform docking device 800 is used to configure downstream data for docking with the downstream platform system; wherein, the downstream data includes at least one of the following of the downstream platform: request address, client identifier, callback address, and request parameters.

[0319] In this embodiment of the application, the upstream and downstream platform docking device 800 is used to receive the second request fed back by the downstream platform in response to the first request; wherein, the second request includes at least one of the following: request address, client identifier, callback address and request parameters;

[0320] The second request is authenticated based on the configured downstream data, and the connection is completed.

[0321] In this embodiment of the application, the second sending unit 801 in the upstream and downstream platform docking device 800 is used to respond to the second request and send a third request to the downstream platform; wherein, the third request includes the upstream identity information and callback address of the corresponding upstream platform.

[0322] In this embodiment of the application, the second receiving unit 801 in the upstream and downstream platform docking device 800 is used to receive the fourth request fed back by the downstream platform in response to the third request; wherein, the fourth request includes: the request address, client identifier, client password, token interface, user interface and callback address corresponding to the upstream platform; the second sending unit 801 in the upstream and downstream platform docking device 800 is used to respond to the fourth request and send a token back to the downstream platform for the downstream platform to provide business support.

[0323] Correspondingly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in a method on a downstream platform side.

[0324] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0325] It should be noted that, Figure 22 A hardware entity illustration of an electronic device provided in the embodiments of this application. Figure 2 ,like Figure 22 As shown, this application embodiment provides an electronic device 900, including a second memory 902 and a second processor 901. The second memory 902 stores a computer program that can run on the second processor 901. When the second processor 901 executes the program, it implements the steps in the above-described method, wherein;

[0326] The second processor 901 typically controls the overall operation of the electronic device 900.

[0327] The second memory 902 is configured to store instructions and applications executable by the second processor 901, and can also cache data to be processed or already processed by the second processor 901 and various modules in the electronic device 900 (e.g., image data, audio data, voice communication data, and video communication data), which can be implemented by flash memory or random access memory (RAM).

[0328] Correspondingly, this application embodiment also provides a computer program product, including a computer program that can be executed by the processor 901 of the electronic device 900 to complete the steps in the method of the upstream and downstream platform docking device 800.

[0329] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0330] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0331] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the apparatus or units can be electrical, mechanical, or other forms.

[0332] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0333] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0334] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0335] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0336] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for connecting upstream and downstream platforms, characterized in that, Applied to downstream platforms, including: Receive a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request; In response to the first request, a second request is sent; the upstream platform and request data corresponding to the second request are determined in a preset set based on the upstream identity information, the preset set including: upstream identity information and related data corresponding to each upstream platform; Finally, the system integration between the upstream and downstream platforms was completed.

2. The upstream and downstream platform docking method according to claim 1, characterized in that, Before responding to the first request and sending the second request, the method further includes: Configure upstream data for the upstream platform system integration; wherein, the upstream data includes at least one of the following corresponding to the upstream platform: the upstream identity information, and relevant data for system integration and subsequent processes.

3. The upstream and downstream platform docking method according to claim 1, characterized in that, The response to the first request, sending the second request, includes: In response to the first request, based on the upstream identity information in the preset set, the upstream platform corresponding to the second request and the corresponding request data are determined; wherein, the request data includes at least one of the following: request address, client identifier, callback address, and request parameters; The second request is sent based on the upstream platform and the request data.

4. The upstream and downstream platform docking method according to any one of claims 1 to 3, characterized in that, After responding to the first request and sending the second request, the method further includes: The system receives a third request in response to the second request from the upstream platform; wherein the third request includes: the upstream identity information and a callback address; In response to the third request, provide business support to the upstream platform.

5. The upstream and downstream platform docking method according to claim 4, characterized in that, The response to the third request, providing business support to the upstream platform, includes: In response to the third request, a fourth request is sent to the upstream platform; wherein the fourth request includes at least one of the following corresponding to the upstream platform: request address, client identifier, client password, token interface, user interface, and callback address; Receive the token returned by the upstream platform in response to the fourth request; The login role corresponding to the upstream platform is determined based on the token, and business support is provided to the upstream platform based on the login role.

6. A method for connecting upstream and downstream platforms, characterized in that, Applied to upstream platforms, including: In response to user requests, a first request is sent to the downstream platform; wherein, the first request includes: upstream identity information; The system receives a second request from the downstream platform in response to the first request, and completes the system connection between the upstream and downstream platforms based on the second request; wherein the second request includes corresponding request data; the upstream platform and the request data are determined by the downstream platform based on the upstream identity information in a preset set; the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

7. The upstream and downstream platform docking method according to claim 6, characterized in that, Before responding to user requests and sending a first request to the downstream platform, the method further includes: Configure downstream data for the downstream platform system; wherein the downstream data includes at least one of the following of the downstream platform: request address, client identifier, callback address, and request parameters.

8. The method for docking the upper and lower sections with the platform according to claim 6, characterized in that, The step of receiving the second request from the downstream platform in response to the first request, and completing the system integration between the upstream and downstream platforms based on the second request, includes: The system receives the second request from the downstream platform in response to the first request; wherein the second request includes at least one of the following: request address, client identifier, callback address, and request parameters; The second request is authenticated based on the configured downstream data, and the connection is completed.

9. The upstream and downstream platform docking method according to any one of claims 6 to 8, characterized in that, After receiving the second request from the downstream platform in response to the first request, the method further includes: In response to the second request, a third request is sent to the downstream platform; wherein the third request includes: the upstream identity information and the callback address.

10. The upstream and downstream platform docking method according to claim 9, characterized in that, After responding to the second request and sending a third request to the downstream platform, the method further includes: Receive a fourth request from the downstream platform in response to the third request; wherein the fourth request includes at least one of the following from the upstream platform: request address, client identifier, client password, token interface, user interface, and callback address; In response to the fourth request, a token is sent back to the downstream platform for the downstream platform to provide business support.

11. A docking device for upstream and downstream platforms, characterized in that, Applied to downstream platforms, including: A first receiving unit is configured to receive a first request; wherein the first request includes: upstream identity information; the upstream identity information is used to indicate the source of the request; The first sending unit is used to send a second request in response to the first request; the upstream platform and request data corresponding to the second request are determined in a preset set based on the upstream identity information, and the preset set includes: the upstream identity information and related data corresponding to each upstream platform; The first sending unit is used to finally complete the system docking between the upstream and downstream platforms.

12. A docking device for upstream and downstream platforms, characterized in that, Applied to upstream platforms, including: The second sending unit is used to respond to user requests and send a first request to the downstream platform; wherein, the first request includes: upstream identity information; The second receiving unit is used to receive the second request fed back by the downstream platform in response to the first request, and to complete the system docking between the upstream and downstream platforms based on the second request; wherein, the second request includes corresponding request data; the upstream platform and the request data are determined by the downstream platform based on the upstream identity information in a preset set; the preset set includes: the upstream identity information and related data corresponding to each upstream platform.

13. An electronic device, characterized in that, The method includes a memory and a processor, the memory storing a computer program executable on the processor, the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 5, or the steps of the method according to any one of claims 6 to 10.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5, or the steps of the method according to any one of claims 6 to 10.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5, or the steps of the method according to any one of claims 6 to 10.

Images