WO2023024057A1 - 跨域授权处理方法及跨域调用处理方法 - Google Patents

跨域授权处理方法及跨域调用处理方法 Download PDF

Info

Publication number
WO2023024057A1
WO2023024057A1 PCT/CN2021/114923 CN2021114923W WO2023024057A1 WO 2023024057 A1 WO2023024057 A1 WO 2023024057A1 CN 2021114923 W CN2021114923 W CN 2021114923W WO 2023024057 A1 WO2023024057 A1 WO 2023024057A1
Authority
WO
WIPO (PCT)
Prior art keywords
cross
domain
target application
call
policy
Prior art date
Application number
PCT/CN2021/114923
Other languages
English (en)
French (fr)
Inventor
李大维
汤亚文
吕欢
窦丽莎
徐浩
岳占秋
Original Assignee
京东方科技集团股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东方科技集团股份有限公司 filed Critical 京东方科技集团股份有限公司
Priority to US17/758,126 priority Critical patent/US20240193249A1/en
Priority to PCT/CN2021/114923 priority patent/WO2023024057A1/zh
Priority to CN202180002298.8A priority patent/CN116034361A/zh
Publication of WO2023024057A1 publication Critical patent/WO2023024057A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication

Definitions

  • the present disclosure relates to the technical field of the Internet, and relates to a cross-domain authorization processing method, a cross-domain call processing method, a cross-domain control processing platform, a cross-domain call realization system, an electronic device, a computer-readable storage medium, and a computer program product.
  • the product development or business system of some projects adopts the technical architecture of front-end and back-end separation.
  • this technical architecture mode it is easy for different terminals or application servers to call services across domains.
  • the rationality and timeliness of cross-domain authorization policies formulated for shared resources affect the security of cross-domain call services.
  • the disclosure provides a cross-domain authorization processing method, a cross-domain call processing method, a cross-domain control processing platform, a cross-domain call realization system, an electronic device, a computer-readable storage medium, and a computer program product.
  • a method for processing cross-domain authorization comprising: in response to a received policy deployment request, displaying at least one cross-domain authorization option associated with a target application, wherein the target application is the policy Deploying the application indicated by the request to be configured with cross-domain authorization; acquiring policy description data input by the user for the at least one cross-domain authorization option; generating a cross-domain authorization policy for the target application based on the policy description data; and Associating the cross-domain authorization policy with the application programming interface API object of the target application, so as to make a cross-domain call for the target application based on the associated API object and the cross-domain authorization policy.
  • a cross-domain call processing method comprising: receiving a cross-domain call request from a requester, the cross-domain call request indicating a target application that the requester requests to call, wherein the The requester and the target application belong to different network domains; obtain a preset cross-domain authorization policy associated with the API object of the target application, wherein the API object is used to provide cross-domain call services for the target application interface object; based on the cross-domain authorization policy and the cross-domain call request, determine whether the requester has the cross-domain call authority for the target application; In the case of the cross-domain call permission, establish a cross-domain route between the requester and the target application, so that the target application obtains and responds to the cross-domain call request based on the cross-domain route.
  • a cross-domain control processing platform includes: a display module, configured to display at least one cross-domain authorization option associated with a target application in response to a received policy deployment request, wherein the The target application is the application indicated by the policy deployment request to be configured with cross-domain authorization; the first acquisition module is configured to acquire the policy description data input by the user for the at least one cross-domain authorization option; the first processing module is configured to Based on the policy description data, generate a cross-domain authorization policy for the target application; and a second processing module, configured to associate the cross-domain authorization policy with the application program interface API object of the target application, so as to base the The associated API objects and cross-domain authorization policies are used to make cross-domain calls for the target application.
  • a cross-domain control processing platform includes: a receiving module, configured to receive a cross-domain call request from a requester, the cross-domain call request indicating the target of the requester request call application, wherein the requester and the target application belong to different network domains; the second acquisition module is configured to acquire a preset cross-domain authorization policy associated with the API object of the target application, wherein the API object An interface object for the target application to provide a cross-domain call service; a third processing module, based on the cross-domain authorization policy and the cross-domain call request, determines whether the requester has an authorization for the target application a cross-domain calling authority; and a fourth processing module, configured to establish a cross-domain route between the requesting party and the target application when it is determined that the requesting party has the cross-domain calling authority for the target application, making the target application obtain and respond to the cross-domain call request based on the cross-domain route.
  • a cross-domain call implementation system includes: a cross-domain control processing platform provided according to the present disclosure, and an application server for providing a cross-domain call service.
  • an electronic device comprising: at least one processor; and a memory communicatively connected to at least one processor; wherein, the memory stores instructions executable by at least one processor, and the instructions are processed by at least one The processor is executed, so that at least one processor can execute the method provided according to the present disclosure.
  • a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method according to the present disclosure.
  • a computer program product comprising a computer program which, when executed by a processor, implements the method provided according to the present disclosure.
  • FIG. 1 schematically shows an exemplary business framework of a cross-domain call processing method and device according to an embodiment of the present disclosure
  • FIG. 2 schematically shows a flow chart of a method for processing cross-domain authorization according to an embodiment of the present disclosure
  • Fig. 3 schematically shows a schematic diagram of cross-domain authorization options according to an embodiment of the present disclosure
  • Fig. 4 schematically shows a schematic diagram of associating a cross-domain authorization policy with an API object of a target application according to an embodiment of the present disclosure
  • Fig. 5 schematically shows a cross-domain call processing method according to an embodiment of the present disclosure
  • FIG. 6 schematically shows a schematic diagram of a cross-domain call implementation process according to an embodiment of the present disclosure
  • Fig. 7 schematically shows a schematic diagram of a cross-domain call implementation system according to an embodiment of the present disclosure
  • Fig. 8 schematically shows a schematic diagram of a cross-domain control processing platform according to an embodiment of the present disclosure
  • Fig. 9 schematically shows a schematic diagram of another cross-domain control processing platform according to an embodiment of the present disclosure.
  • Fig. 10 schematically shows a schematic block diagram of an electronic device according to an embodiment of the present disclosure.
  • the product development or business system of some projects adopts the technical architecture of front-end and back-end separation.
  • this technical architecture mode cross-domain service calls are prone to occur between different terminals or application servers.
  • the XML Http Request initiated by the front end is prone to cross-domain call services.
  • the request URL Uniform Resource Locator, Uniform Resource Locator
  • the request is a cross-domain request relative to the target application.
  • the address of the target webpage is http://www.example.com/dir/page.html
  • http://www.example.com:81/dir/page.html is a non-same-origin webpage with a different port from the target webpage.
  • Cross-Origin Resource Sharing belongs to a browser technical specification, which is used to allow the browser of the current network domain to receive the XML Http Request request sent by the cross-domain server. It is a resource that allows the current network domain A communication mechanism for shared access by applications in other network domains. Developing cross-domain authorization policies for shared resources (that is, resources that are allowed to be accessed by other domains in each domain) can effectively block malicious cross-domain calls and ensure the safety of cross-domain calls. The rationality and timeliness of cross-domain authorization policy formulation affect the security of cross-domain call services.
  • this disclosure proposes a cross-domain authorization processing method, a cross-domain call processing method, a cross-domain control processing platform, A cross-domain call implementation system, an electronic device, a non-transitory computer-readable storage medium storing computer instructions, and a computer program product.
  • FIG. 1 schematically shows an exemplary business framework of a cross-domain call processing method and apparatus according to an embodiment of the present disclosure. It should be noted that FIG. 1 is only an example of a business system architecture to which the embodiments of the present disclosure can be applied, so as to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiments of the present disclosure cannot be used in Other equipment, systems, environments or scenarios.
  • the service framework 100 of this embodiment may include a requester 101 , a cross-domain control processing platform 102 , an application server 103 and a network 104 .
  • the network 104 is a medium for providing a communication link between the requester 101 , the cross-domain control processing platform 102 and the application server 103 .
  • Network 104 may include various connection types, such as wires, wireless communication links, or fiber optic cables, among others.
  • the application server 103 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud computing, network services, and middleware services. .
  • the cross-domain control processing platform 102 receives a cross-domain call request from a requester (such as the requester 101 in FIG. implemented applications).
  • the requester and the target application may belong to different network domains, that is, the requester 101 and the application server 103 may belong to different network domains.
  • the cross-domain control processing platform 102 acquires a preset cross-domain authorization policy associated with an API (Application Programming Interface, Application Programming Interface) object of the target application, and the API object is an interface object used for providing cross-domain calling services for the target application.
  • the cross-domain control processing platform 102 determines whether the requester has the cross-domain call authority for the target application based on the cross-domain authorization policy and the cross-domain call request. When it is determined that the requester has the cross-domain call authority for the target application, a cross-domain route between the requester and the target application is established, so that the target application obtains and responds to the cross-domain call request based on the cross-domain route.
  • Fig. 2 schematically shows a flowchart of a cross-domain authorization processing method according to an embodiment of the present disclosure.
  • the cross-domain authorization processing method 200 may include operation S210 to operation S240.
  • At least one cross-domain authorization option associated with the target application is displayed in response to the received policy deployment request, wherein the target application is an application indicated by the policy deployment request to be configured for cross-domain authorization.
  • a cross-domain authorization policy for the target application is generated based on the policy description data.
  • operation S240 associate the cross-domain authorization policy with the API object of the target application, so as to make a cross-domain call for the target application based on the associated API object and the cross-domain authorization policy.
  • At least one cross-domain authorization option associated with the target application is displayed in response to the received policy deployment request, wherein the target application is an application indicated by the policy deployment request to be configured for cross-domain authorization.
  • a policy deployment request from a requester is received, and the policy deployment request indicates a target application to be configured with cross-domain authorization.
  • the policy deployment request indicates that the requester requests to deploy a cross-domain authorization policy for the target application, and the cross-domain authorization policy describes the call authorization rules when applications in other network domains call shared resource information in the target application across domains.
  • the requester who initiates the policy deployment request can be the API management user of the API object associated with the target application.
  • the API object is an application programming interface object used to provide cross-domain call services for the target application.
  • the API object encapsulates the underlying API functions with function.
  • API objects include calling API objects and called API objects. Different API objects can be used to implement different functions, such as remote procedure call, file transfer, information coupling, standard language query and other functions. Therefore, the target application may correspond to more than an API object. Based on the preset API object function and API object call relationship, the target application can provide cross-domain call services to applications in other network domains based on at least one API object.
  • FIG. 3 schematically shows a schematic diagram of cross-domain authorization options according to an embodiment of the present disclosure. As shown in FIG. Source, allowed request method, allowed request header, exposed request header, preflight time, etc.
  • the cross-domain policy is optional, and it is used to indicate the role of the cross-domain authorization policy.
  • the cross-domain transfer option indicates whether the cross-domain calling service needs to transfer the cookie content.
  • the cookie is the data that the website uses to identify the user's identity and track the session (time domain) and store it in the user's local terminal.
  • An example of the cookie format is as follows:
  • Name indicates the unique cookie name
  • value is the string value stored in the cookie
  • domain indicates the domain object where the cookie takes effect, that is, the request sent to the domain needs to include this cookie
  • path indicates the path of the cookie, browse
  • the server can send a cookie message to the specified domain based on the action path; expires indicates the expiration time of the cookie; secure constitutes the security symbol of the cookie.
  • the allowed request source indicates the cross-domain call request source that the target application is allowed to access;
  • the allowed request method indicates the HTTP request type supported by the cross-domain call service provided by the target application;
  • the allowed request header indicates that it is allowed to be passed by the API object The request header information to the target application;
  • the exposed request header indicates the request header information that is allowed to be passed to the API object by the target application, and further passed to the requester by the API object;
  • the preflight time indicates that the received cross-domain call request is passed to the target application Time period information for security authentication.
  • the cross-domain control processing platform integrates default configuration information.
  • the default configuration information is the default basic information that is not exposed to users, such as the default allowed request header information and the default exposed request header information. .
  • the policy description data input by the user for at least one cross-domain authorization option is obtained, that is, the policy description data input by the API management user for each cross-domain authorization option is obtained.
  • the policy description data is used to generate the Metadata for cross-domain authorization policies.
  • the network domain to which the target application belongs is www.qcloud.com
  • the policy description data entered by the API management user for the "Allow Request Source” option is apigw.qcloud.com, that is, the permission originates from the "apigw.qcloud.com” network domain
  • the HTTP request of the "www.qcloud.com” domain invokes resources across domains from the target application.
  • API management users can configure policy description data for different cross-domain authorization options, and can complete the configuration policy description data by submitting a form.
  • this design is conducive to realizing the autonomy and flexibility of cross-domain authorization policy configuration, and is conducive to ensuring cross-domain call resources on the basis of meeting the custom requirements of resource management.
  • Information Security is conducive to realizing the autonomy and flexibility of cross-domain authorization policy configuration, and is conducive to ensuring cross-domain call resources on the basis of meeting the custom requirements of resource management.
  • a cross-domain authorization policy for the target application is generated based on the policy description data.
  • a cross-domain authorization policy for the target application is generated, and the generated cross-domain authorization policy supports modification and deletion operations.
  • the physical form of the cross-domain authorization policy can be a cross-domain authorization policy file in the form of an xml document, for example, it can be a crossdomain.xml file, which contains the cross-domain-policy root element, and the root element is the The policy definition container.
  • operation S240 associate the cross-domain authorization policy with the API object of the target application, so as to make a cross-domain call for the target application based on the associated API object and the cross-domain authorization policy.
  • FIG. 4 schematically shows a schematic diagram of associating the cross-domain authorization policy with the API object of the target application according to an embodiment of the present disclosure, associating the cross-domain authorization policy with the API object of the target application to realize Manage cross-domain authorization policies for target applications based on the API object level.
  • this design can effectively reduce the granularity of cross-domain authorization policy management and improve the refinement of cross-domain call control.
  • the cross-domain control processing platform can provide an API scanning function, which can display API objects associated with a target application according to scanning conditions set by a user.
  • the cross-domain authorization policy associated with the target application can be managed in the form of a plug-in.
  • the cross-domain authorization policy can be bound to the specific API object of the target application according to the actual cross-domain call needs, so as to This implementation is aimed at the association management between the cross-domain authorization policy and the API object of the target application.
  • there is no functional coupling between the cross-domain authorization policy and the API object there is no functional coupling between the cross-domain authorization policy and the API object, and the underlying data of the two may not be merged.
  • Microservice application is an implementation form of developing a single application by building multiple independent functional units (ie services). Each functional unit can run independently in its own process, and data interaction between different functional units is carried out through lightweight communication. Microservice applications have the advantages of good scalability, high reliability, and low maintenance costs.
  • the API object associated with the target application is set with preset call attributes, which may include, for example, authentication method, access protocol type, allowed request method type, request format, service interface address and other information. Since both the cross-domain authorization policy and the preset call attribute may contain call parameter information for the API object, there may be a policy conflict between the cross-domain authorization policy and the preset call attribute of the API object.
  • At least one API object associated with the target application may contain some API objects whose preset call attributes do not have a policy conflict with the cross-domain authorization policy, and may also contain some API objects whose preset call attributes have a policy conflict with the cross-domain authorization policy object. Some of the API objects whose preset invocation attributes conflict with the cross-domain authorization policy may also include API objects capable of conflict resolution. For the convenience of expression, some API objects with no policy conflicts between preset call attributes and cross-domain authorization policies are expressed as the first API objects, and some API objects with policy conflicts between preset call attributes and cross-domain authorization policies are expressed as second The API object expresses the API object after the conflict elimination process in the second API object as the third API object.
  • the conflict resolution process may include: in the case of determining that there is a policy conflict between the cross-domain authorization policy and the preset call attribute of any API object, the preset call of the API object may be re-formulated according to business requirements and API object functions attribute to achieve policy conflict elimination.
  • conflict resolution may be implemented in other manners, which are not limited in the embodiments of the present disclosure.
  • the cross-domain authorization policy for the target application supports modification and deletion operations, and in response to the received policy change request for the target application, at least one cross-domain authorization configured item associated with the target application is displayed. Then, acquire policy change data entered by the user for at least one cross-domain authorization configured item, and update the cross-domain authorization policy for the target application based on the policy change data.
  • the updated cross-domain authorization policy is associated with the API object of the target application, so as to make a cross-domain call for the target application based on the associated API object and the updated cross-domain authorization policy.
  • this design can effectively reduce the update cost of cross-domain authorization policies, improve the convenience of revision of cross-domain authorization policies, and effectively ensure The real-time and rationality of cross-domain authorization policy configuration.
  • the flow control parameter indicates the cross-domain call request threshold that the API object is allowed to access within a unit duration
  • the flow control parameter includes, for example, the limit of external calls (unit times/second) and the limit of internal calls (unit times/second).
  • cross-domain enabling parameters associated with the API object can also be configured, so that cross-domain calls for the target application can be made based on the cross-domain enabling parameters and cross-domain authorization policies, wherein the cross-domain enabling parameters indicate whether the API object allows enabling cross-domain calls Serve.
  • At least one cross-domain authorization option associated with the target application is displayed in response to the received policy deployment request, wherein the target application is an application indicated by the policy deployment request to be configured for cross-domain authorization;
  • a cross-domain authorization option input policy description data; based on the policy description data, generate a cross-domain authorization policy for the target application; and associate the cross-domain authorization policy with the application program interface API object of the target application, so that based on the associated API Objects and cross-domain authorization policies to make cross-domain calls to target applications.
  • Fig. 5 schematically shows a cross-domain call processing method according to an embodiment of the present disclosure.
  • the cross-domain call processing method 500 may include operation S510 to operation S540.
  • a cross-domain call request is received from the requester, and the cross-domain call request indicates a target application that the requester requests to call, wherein the requester and the target application belong to different network domains.
  • a preset cross-domain authorization policy associated with the API object of the target application is acquired, wherein the API object is an interface object for the target application to provide a cross-domain calling service.
  • operation S530 based on the cross-domain authorization policy and the cross-domain call request, it is determined whether the requester has the cross-domain call permission for the target application.
  • operation S540 if it is determined that the requester has the cross-domain call authority for the target application, establish a cross-domain route between the requester and the target application, so that the target application obtains the cross-domain call request based on the cross-domain route and response.
  • a cross-domain call request is received from the requester, and the cross-domain call request indicates a target application that the requester requests to call, wherein the requester and the target application belong to different network domains.
  • a cross-domain call request from a requester is received, and the cross-domain call request indicates a target application for which the requester requests a cross-domain call.
  • the cross-domain call request from the requester may be a simple cross-domain request or a non-simple cross-domain request.
  • the request method in a simple cross-domain request is one of the HEAD, GET, or POST methods, and the request method in a non-simple cross-domain request Include the OPTIONS method.
  • the OPTIONS method is used to pre-check whether the actual request for subsequent cross-domain calls can be sent safely by adding an HTTP request before formal communication.
  • the cross-domain call request may contain an Origin field, and the Origin field is used to indicate the origin of the cross-domain call request.
  • the cross-domain call request includes a field Host: qcloud.com, and a field Origin: http://apigw.qcloud.com, and the cross-domain call request indicates that apigw.qcloud.com requests to call resources in qcloud.com.
  • the requester and target application associated with the cross-domain call request may be browsers belonging to different network domains, and the API object associated with the target application may be encapsulated in a browser plug-in or browser component, or built into the browser middle.
  • a preset cross-domain authorization policy associated with the API object of the target application is acquired, wherein the API object is an interface object for the target application to provide a cross-domain call service.
  • the target application obtain cross-domain enabling parameters associated with each API object, and determine whether the corresponding API object allows cross-domain enabling according to the cross-domain enabling parameters associated with each API object Invoking the service; and for at least one API object that allows cross-domain invocation of the service, obtaining a cross-domain authorization policy associated with each API object.
  • obtain the cross-domain authorization policy associated with each API object from the API database, save the cross-domain authorization policy to the Redis (Remote Dictionary Server, remote dictionary service) cache, and set a preset life for the cached data cycle time.
  • the requester needs to subscribe to the cross-domain call service in the management platform in advance according to the requirements, so that the management platform can generate a system token for the requester, and/or AK (Access Key, access key)/SK (Secret Key, security key ) authentication key.
  • the service contract data associated with the target application can also be obtained, based on the service contract data, it is determined whether the target application has registered the cross-domain call service associated with the cross-domain call request, and when it is determined that the target application has registered and the cross-domain call request In the case of calling services across domains, execute the operation of obtaining cross-domain authorization policies.
  • the target application needs to register the cross-domain call service it provides in the management platform in advance according to the requirements, otherwise the cross-domain call service cannot be realized based on the API call.
  • This design eliminates the need for the cross-domain call service provider to repeatedly apply for the cross-domain call service, and does not require the provider to independently perform the cumbersome operations of cross-domain call load balancing, which is conducive to improving the convenience of cross-domain call service API calls.
  • operation S530 based on the cross-domain authorization policy and the cross-domain call request, it is determined whether the requester has the cross-domain call permission for the target application.
  • the cross-domain call request includes call interface information and call type information associated with the requester.
  • the call interface information may be, for example, the address information of the call interface indicated by the Origin field, and the call type information may be, for example, a cross-domain call request.
  • the request method type information the request method may include, for example, POST, GET, PUT, DELETE and other method types.
  • the requester When determining whether the requester has the cross-domain call permission for the target application based on the cross-domain authorization policy and the cross-domain call request, it can be based on the cross-domain authorization policy associated with the API object and the call interface information in the cross-domain call request and call type information to determine whether the requester has the request permission for the cross-domain call to the target application, and determine whether the target application has the response permission for the cross-domain call to the requester. In a case where it is determined that the requester has the request permission for the cross-domain call to the target application and the target application has the response permission for the cross-domain call to the requester, it is determined that the requester has the permission to call the target application across the domain through the API object.
  • the cross-domain call request and according to the allowed request source, allowed request method, and allowed request header information in the cross-domain authorization policy, it can be determined whether the requester has the cross-domain call request permission for the target application; according to the cross-domain authorization policy
  • the exposed request header information in determines whether the target application has the permission to respond to cross-domain calls to the requester.
  • the non-simple cross-domain request needs to be sent to the target application in the form of a preflight request for preflight verification, and if the preflight verification passes , send the non-simple cross-domain request to the target application in the form of a formal request for response processing.
  • the pre-check verification is passed, according to the time period indicated by the pre-check time feature in the cross-domain authorization policy, the non-simple cross-domain request received from the same requester within the corresponding time period is regarded as a simple cross-domain request. Requests are processed directly.
  • the requester after determining that the requester has the permission to call the target application across domains through the API object, it can also determine whether to pass the cross-domain call request through the API according to the preflight time characteristics in the cross-domain authorization policy.
  • the object is passed to the target application, so that the target application determines whether to allow the cross-domain call based on the cross-domain call request.
  • operation S540 if it is determined that the requester has the cross-domain call authority for the target application, establish a cross-domain route between the requester and the target application, so that the target application obtains the cross-domain call request based on the cross-domain route and response.
  • the requester when it is determined that the requester has the authority to call the target application across domains through M API objects, when establishing a cross-domain route between the requester and the target application, it can be determined that the requester and the M API objects
  • the network performance information of the M cross-domain routes formed by each API object in the API object indicates the network performance of the corresponding cross-domain route, and then, the cross-domain route with the best network performance among the M cross-domain routes is selected as The cross-domain routing between the requester and the target application, wherein M is an integer greater than 1, and the network performance information includes network delay information and/or network bandwidth information.
  • the network performance of the cross-domain routing composed of the requester and the API object can be indicated by network delay information and/or network bandwidth information. It is related to factors such as the size of the data flow to be processed by the object and the data flow rate.
  • N is an integer not less than 1.
  • the target application obtains and responds to the cross-domain call request based on the cross-domain route.
  • the cross-domain call request obtained from the requester is passed to the target application through the API object, and/or the cross-domain call response information obtained from the API object is passed to the requester.
  • the cross-domain call response information is The target application is obtained based on the response of the cross-domain call request.
  • the cross-domain authorization policy associated with the API object can be added to the request header of the cross-domain call request to obtain the processed cross-domain call request. Then, pass the processed cross-domain call request to the target application through the API object, so that the target application extracts the cross-domain authorization policy in the request header, and decides whether to allow the cross-domain call based on the cross-domain authorization policy.
  • the flow control parameters associated with the API object of the target application it is also possible to obtain the flow control parameters associated with the API object of the target application, and add the flow control parameters and cross-domain authorization policy to the request header of the cross-domain call request to obtain the processed cross-domain call ask. Then, pass the processed cross-domain call request to the target application through the API object, so that the target application can determine whether to allow this cross-domain call based on the processed cross-domain call request, for example, so that the target application extracts the Flow control parameters and cross-domain authorization policy, according to the cross-domain authorization policy and the internal call restriction information and external call restriction information in the flow control parameters, determine whether to allow this cross-domain call through the corresponding API object.
  • a cross-domain call request from a requester is received, and the cross-domain call request indicates the target application that the requester requests to call, wherein, the requester and the target application belong to different network domains; and the API object associated with the target application is acquired
  • the preset cross-domain authorization policy wherein the API object is an interface object for the target application to provide cross-domain call services; based on the cross-domain authorization policy and the cross-domain call request, determine whether the requester has a cross-domain call for the target application authority; and in the case of determining that the requester has the cross-domain call permission for the target application, establishing a cross-domain route between the requester and the target application, so that the target application obtains and responds to the cross-domain call request based on the cross-domain route.
  • the cross-domain call control operation between the requester and the target application can be executed, and the cross-domain call control can be improved while meeting the business needs according to the custom resource management requirements.
  • the degree of refinement ensures the security of information calls between different network domains, which is conducive to the realization of resource sharing among multiple network domains and the unified and flexible management of shared resources in different network domains.
  • Fig. 6 schematically shows a schematic diagram of a cross-domain call implementation process according to an embodiment of the present disclosure.
  • the cross-domain call implementation process may include operation S601 to operation S615.
  • the cross-domain call implementation process is executed by the cross-domain call control platform.
  • the cross-domain call implementation process may include a cross-domain policy configuration process and a cross-domain call processing process.
  • the cross-domain call control platform may include a micro-service application platform and a micro-service gateway.
  • the cross-domain policy configuration process is executed by the microservice application platform, and the cross-domain policy configuration process may include operation S601 to operation S610.
  • the cross-domain call processing flow is executed by the microservice gateway, and the cross-domain call processing flow may include operation S601 to operation S615.
  • an event of creating a cross-domain authorization policy is triggered in response to the received policy deployment request.
  • At least one cross-domain authorization option associated with the target application is displayed, and policy description data input by the user for the at least one cross-domain authorization option is acquired.
  • the target application is the application indicated by the policy deployment request to be configured with cross-domain authorization.
  • operation S602 check whether the obtained policy description data contains the Origin (source) field, if so, continue to perform operation S603, and if not, return the policy description data to the client for modification, wherein the Origin field indicates that the field is allowed The source of the cross-origin call request.
  • operation S603 check whether the obtained policy description data contains the Credentials (qualification certificate) field, if so, continue to perform operation S604, and if not, return the policy description data to the client for modification, wherein the Credentials field indicates Whether the cross-domain call service needs to pass the cookie content.
  • the preflight (preflight time) is modified, wherein the preflight time indicates time period information for delivering the received cross-domain call request to the target application for security authentication.
  • a default value of the Request Header field (required header field) is added, wherein the Request Header field indicates the request header information contained in the cross-domain call request.
  • operation S607 it is determined whether the cross-domain authorization policy has been associated with the API object of the target application, if yes, perform operation S608; and if not, perform operation S608'.
  • route matching between the requester and the target application is performed to determine an API object that can be used to implement the cross-domain call service, wherein the cross-domain call request indicates that the requester The target application for the request call.
  • operation S614 according to the received cross-domain call request, and according to the cross-domain authorization policy associated with the API object, determine whether to allow the current cross-domain call of the requesting party, if yes, perform operation S615, if not, request The party returns a prompt message that the request failed.
  • Fig. 7 schematically shows a schematic diagram of a system for implementing a cross-domain call according to an embodiment of the present disclosure.
  • cross-domain calls to implement system cross-domain may include cross-domain control processing platform 701 , message service cluster 702 , cache server 703 , storage server 704 , monitoring server 705 and failover server 706 .
  • the cross-domain control processing platform 701 includes various component application clusters of the microservice platform, which are used for cross-domain authorization policy configuration and cross-domain call service transfer.
  • the cross-domain control processing platform 701 includes a gateway 7011, a registration center 7012, and an authentication center 7013 , microservice application 7014 and configuration center 7015.
  • the requester Since the cross-domain call service is a service that is not directly exposed to the requester, the requester needs to initiate a cross-domain call request to the gateway 7011, and the gateway 7011 records the detailed information of the cross-domain call request, such as recording the request header and Request body information.
  • the gateway 7011 obtains the cross-domain authorization policy associated with the API object of the target application through a custom plug-in, and determines whether to allow this cross-domain call of the requester based on the obtained cross-domain authorization policy and the cross-domain call request.
  • the gateway 7011 transmits the cross-domain call request to the target application in the form of a transfer platform, receives the cross-domain call response information from the target application, and records the response in the cross-domain call response information header and response body information.
  • the registration center 7012 is used for the target application to register the cross-domain call service it provides.
  • the authentication center 7013 is used to identify whether the requester has subscribed to the cross-domain call service associated with the target application according to the user attribute certificate of the requester.
  • the microservice application 7014 is used to implement cross-domain authorization policy configuration, and the policy configuration function can be completed through the form submitted by the user.
  • the configuration center 7015 is used to provide the default basic information of cross-domain authorization policy configuration. Users can easily import the default basic information into their own service configuration, which can save most of the repetitive configuration content, making the policy configuration function online transparent and easy. maintain.
  • the message service cluster 702 is configured to collect and store log records during cross-domain calls.
  • the cache server 703 which may be a Redis server, is used to cache some infrequently changed data during cross-domain calls, for example, to temporarily cache the cross-domain authorization policy after obtaining the cross-domain authorization policy associated with the API object.
  • the storage server 704 may be a MySQL (relational database management system) server, and is used for persistently storing data during a cross-domain call.
  • MySQL relational database management system
  • the monitoring server 705 may be a Zabbix monitoring server, which is used to monitor the virtual machine status of the entire platform and give an abnormal alarm.
  • the failover server 706, which may be an MHA server, is used as a MySQL management tool to maintain a high-availability architecture supporting MySQL.
  • Fig. 8 schematically shows a schematic diagram of a cross-domain control processing platform according to an embodiment of the present disclosure.
  • the cross-domain control processing platform includes a display module 801 , a first acquisition module 802 , a first processing module 803 and a second processing module 804 .
  • the display module 801 is configured to display at least one cross-domain authorization option associated with the target application in response to the received policy deployment request, wherein the target application is an application indicated by the policy deployment request to be configured for cross-domain authorization.
  • the first obtaining module 802 is configured to obtain policy description data input by the user for at least one cross-domain authorization option.
  • the first processing module 803 is configured to generate a cross-domain authorization policy for the target application based on the policy description data.
  • the second processing module 804 is configured to associate the cross-domain authorization policy with the application program interface API object of the target application, so as to make a cross-domain call for the target application based on the associated API object and the cross-domain authorization policy.
  • At least one cross-domain authorization option associated with the target application is displayed in response to the received policy deployment request, wherein the target application is an application indicated by the policy deployment request to be configured for cross-domain authorization;
  • a cross-domain authorization option input policy description data; based on the policy description data, generate a cross-domain authorization policy for the target application; and associate the cross-domain authorization policy with the application program interface API object of the target application, so that based on the associated API Objects and cross-domain authorization policies to make cross-domain calls to target applications.
  • the second processing module includes: a first processing submodule, configured to determine the cross-domain authorization policy and preset It is set whether there is a policy conflict between the calling attributes; the second processing submodule is used for performing an association operation between a cross-domain authorization policy and each first API object for at least one first API object that does not have a policy conflict.
  • the second processing module further includes: a third processing submodule, configured to determine whether the conflict can be performed for the preset invocation attributes of each second API object for at least one second API object with a policy conflict Elimination processing; and a fourth processing submodule, configured to perform an association operation between the cross-domain authorization policy and each third API object for at least one third API object after conflict elimination processing.
  • the cross-domain control processing platform further includes: a fifth processing module, configured to display at least one cross-domain authorization configured item associated with the target application in response to the received policy change request for the target application; obtain The policy change data entered by the user for at least one cross-domain authorization configured item; based on the policy change data, update the cross-domain authorization policy for the target application; associate the updated cross-domain authorization policy with the API object of the target application, so as to The associated API object and the updated cross-domain authorization policy are used to make cross-domain calls for the target application.
  • a fifth processing module configured to display at least one cross-domain authorization configured item associated with the target application in response to the received policy change request for the target application; obtain The policy change data entered by the user for at least one cross-domain authorization configured item; based on the policy change data, update the cross-domain authorization policy for the target application; associate the updated cross-domain authorization policy with the API object of the target application, so as to The associated API object and the updated cross-domain authorization policy are used to make cross-domain calls for the target application.
  • the cross-domain control processing platform also includes: a sixth processing module, configured to configure flow control parameters associated with the API object, so as to perform cross-domain calls for target applications based on flow control parameters and cross-domain authorization policies , where the flow control parameter indicates the threshold of cross-domain call requests allowed by the API object within a unit duration.
  • the cross-domain control processing platform also includes: a seventh processing module, configured to configure the cross-domain enabling parameters associated with the API object, so as to perform cross-domain authorization for the target application based on the cross-domain enabling parameters and the cross-domain authorization policy.
  • Domain call wherein, the cross-domain enabled parameter indicates whether the API object allows enabling cross-domain call services.
  • Fig. 9 schematically shows a schematic diagram of another cross-domain control processing platform according to an embodiment of the present disclosure.
  • the cross-domain control processing platform includes a receiving module 901 , a second acquiring module 902 , a third processing module 903 and a fourth processing module 904 .
  • the receiving module 901 is configured to receive a cross-domain call request from a requester, where the cross-domain call request indicates a target application that the requester requests to call, wherein the requester and the target application belong to different network domains.
  • the second obtaining module 902 is configured to obtain a preset cross-domain authorization policy associated with an API object of the target application, wherein the API object is an interface object for the target application to provide cross-domain calling services.
  • the fourth processing module 904 is configured to establish a cross-domain route between the requester and the target application when it is determined that the requester has the cross-domain call authority for the target application, so that the target application obtains the cross-domain call request based on the cross-domain route and respond.
  • a cross-domain call request from a requester is received, and the cross-domain call request indicates the target application that the requester requests to call, wherein, the requester and the target application belong to different network domains; and the API object associated with the target application is acquired
  • the preset cross-domain authorization policy wherein the API object is an interface object for the target application to provide cross-domain call services; based on the cross-domain authorization policy and the cross-domain call request, determine whether the requester has a cross-domain call for the target application authority; and in the case of determining that the requester has the cross-domain call permission for the target application, establishing a cross-domain route between the requester and the target application, so that the target application obtains and responds to the cross-domain call request based on the cross-domain route.
  • the cross-domain call control operation between the requester and the target application can be executed, and the cross-domain call control can be improved while meeting the business needs according to the custom resource management requirements.
  • the degree of refinement ensures the security of information calls between different network domains, which is conducive to the realization of resource sharing among multiple network domains and the unified and flexible management of shared resources in different network domains.
  • the second obtaining module includes: a first obtaining submodule, configured to obtain cross-domain enabling parameters associated with each API object for at least one API object associated with the target application; a fifth processing submodule, It is used to determine whether the corresponding API object allows cross-domain call services to be enabled according to the cross-domain enablement parameters associated with each API object; The cross-domain authorization policy associated with each API object.
  • the cross-domain call request includes call interface information and call type information associated with the requester;
  • the third processing module includes: a seventh processing sub-module, which is used for according to the cross-domain authorization policy associated with the API object, The call interface information and call type information in the cross-domain call request, determine whether the requester has the request permission for the cross-domain call to the target application, and determine whether the target application has the cross-domain call response permission for the requester; and the eighth processing sub- A module configured to determine that the requester has the permission to call the target application across domains through the API object when it is determined that the requester has the request permission for the cross-domain call to the target application and the target application has the response permission for the cross-domain call to the requester.
  • the fourth processing module includes: a ninth processing submodule, configured to determine that the requester is compatible with the M API objects
  • the network performance information of the M cross-domain routes formed by the API objects in the API object indicates the network performance of the corresponding cross-domain routes; the tenth processing sub-module is used to select the best network performance among the M cross-domain routes
  • the cross-domain route of is used as the cross-domain route between the requester and the target application, where M is an integer greater than 1, and the network performance information includes network delay information and/or network bandwidth information.
  • the fourth processing module also includes: an eleventh processing sub-module, used to pass the cross-domain call request to the target application through the API object; a twelfth processing sub-module, used to obtain the request from the API object
  • the cross-domain call response information is transmitted to the requester, wherein the cross-domain call response information is obtained by the target application based on the cross-domain call request response.
  • the eleventh processing submodule includes: a first processing unit, configured to add the cross-domain authorization policy associated with the API object to the request header of the cross-domain call request, and obtain the processed cross-domain call request; the second processing unit is configured to pass the processed cross-domain call request to the target application through the API object, so that the target application determines whether to allow the cross-domain call based on the processed cross-domain call request.
  • the eleventh processing sub-module further includes: a third processing unit, configured to acquire the flow control parameters associated with the API object of the target application, and combine the cross-domain authorization policy and flow control parameters associated with the API object Added to the request header of the cross-domain call request to obtain the processed cross-domain call request; the fourth processing unit is used to transfer the processed cross-domain call request to the target application through the API object, so that the target application The cross-domain call request determines whether to allow this cross-domain call.
  • the cross-domain control processing platform also includes: an eighth processing module, configured to: obtain the user attribute certificate associated with the requester; determine whether the requester has subscribed to the cross-domain Invoking the service; and in the case of determining that the requester has subscribed to the cross-domain invoking service for the target application, triggering the second acquiring module to execute the operation of acquiring the cross-domain authorization policy.
  • the cross-domain control processing platform also includes: a ninth processing module, configured to: obtain service contract data associated with the target application; determine whether the target application has been registered and associated with the cross-domain call request based on the service contract data The cross-domain call service; and when it is determined that the target application has registered the cross-domain call service associated with the cross-domain call request, trigger the second acquisition module to execute the operation of acquiring the cross-domain authorization policy.
  • a ninth processing module configured to: obtain service contract data associated with the target application; determine whether the target application has been registered and associated with the cross-domain call request based on the service contract data The cross-domain call service; and when it is determined that the target application has registered the cross-domain call service associated with the cross-domain call request, trigger the second acquisition module to execute the operation of acquiring the cross-domain authorization policy.
  • the cross-domain control processing platform also includes: a tenth processing module, configured to: determine whether to pass the cross-domain call request to the target application through the API object according to the pre-check time feature in the cross-domain authorization policy , so that the target application determines whether to allow the cross-domain call based on the cross-domain call request.
  • a tenth processing module configured to: determine whether to pass the cross-domain call request to the target application through the API object according to the pre-check time feature in the cross-domain authorization policy , so that the target application determines whether to allow the cross-domain call based on the cross-domain call request.
  • the requester and the target application are browsers belonging to different network domains;
  • the API object is encapsulated in a browser plug-in or browser component, or built into the browser.
  • Fig. 10 schematically shows a schematic block diagram of an electronic device according to an embodiment of the present disclosure.
  • Electronic device is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers.
  • Electronic devices may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smart phones, wearable devices, and other similar computing devices.
  • the components shown herein, their connections and relationships, and their functions, are by way of example only, and are not intended to limit implementations of the disclosure described and/or claimed herein.
  • the device 1000 includes a computing unit 1001 that can be executed according to a computer program stored in a read-only memory (ROM) 1002 or loaded from a storage unit 1008 into a random-access memory (RAM) 1003. Various appropriate actions and treatments. In the RAM 1003, various programs and data necessary for the operation of the device 1000 can also be stored.
  • the computing unit 1001, ROM 1002, and RAM 1003 are connected to each other through a bus 1004.
  • An input/output (I/O) interface 1005 is also connected to the bus 1004 .
  • the I/O interface 1005 includes: an input unit 1006, such as a keyboard, a mouse, etc.; an output unit 1007, such as various types of displays, speakers, etc.; a storage unit 1008, such as a magnetic disk, an optical disk, etc. ; and a communication unit 1009, such as a network card, a modem, a wireless communication transceiver, and the like.
  • the communication unit 1009 allows the device 1000 to exchange information/data with other devices through a computer network such as the Internet and/or various telecommunication networks.
  • the computing unit 1001 may be various general-purpose and/or special-purpose processing components having processing and computing capabilities. Some examples of computing units 1001 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processing processor (DSP), and any suitable processor, controller, microcontroller, etc.
  • the computing unit 1001 executes various methods and processes described above, such as a cross-domain authorization processing method and a cross-domain call processing method.
  • the cross-domain authorization processing method and the cross-domain call processing method may be implemented as computer software programs tangibly embodied in a machine-readable medium, such as the storage unit 1008 .
  • part or all of the computer program may be loaded and/or installed on the device 1000 via the ROM 1002 and/or the communication unit 1009.
  • the computer program When the computer program is loaded into RAM 1003 and executed by computing unit 1001, one or more steps of the above-described cross-domain authorization processing method and cross-domain call processing method can be executed.
  • the computing unit 1001 may be configured to execute the cross-domain authorization processing method and the cross-domain call processing method in any other appropriate manner (for example, by means of firmware).
  • Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips Implemented in a system of systems (SOC), load programmable logic device (CPLD), computer hardware, firmware, software, and/or combinations thereof.
  • FPGAs field programmable gate arrays
  • ASICs application specific integrated circuits
  • ASSPs application specific standard products
  • SOC system of systems
  • CPLD load programmable logic device
  • computer hardware firmware, software, and/or combinations thereof.
  • programmable processor can be special-purpose or general-purpose programmable processor, can receive data and instruction from storage system, at least one input device, and at least one output device, and transmit data and instruction to this storage system, this at least one input device, and this at least one output device an output device.
  • Program codes for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special purpose computer, or other programmable data processing devices, so that the program codes, when executed by the processor or controller, make the functions/functions specified in the flow diagrams and/or block diagrams Action is implemented.
  • the program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.
  • a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.
  • a machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium.
  • a machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing.
  • machine-readable storage media would include one or more wire-based electrical connections, portable computer discs, hard drives, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber, compact disk read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination of the foregoing.
  • RAM random access memory
  • ROM read only memory
  • EPROM or flash memory erasable programmable read only memory
  • CD-ROM compact disk read only memory
  • magnetic storage or any suitable combination of the foregoing.
  • the systems and techniques described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user. ); and a keyboard and pointing device (eg, a mouse or a trackball) through which a user can provide input to the computer.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • a keyboard and pointing device eg, a mouse or a trackball
  • Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and can be in any form (including Acoustic input, speech input or, tactile input) to receive input from the user.
  • the systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., as a a user computer having a graphical user interface or web browser through which a user can interact with embodiments of the systems and techniques described herein), or including such backend components, middleware components, Or any combination of front-end components in a computing system.
  • the components of the system can be interconnected by any form or medium of digital data communication, eg, a communication network. Examples of communication networks include: Local Area Network (LAN), Wide Area Network (WAN) and the Internet.
  • a computer system may include clients and servers.
  • Clients and servers are generally remote from each other and typically interact through a communication network.
  • the relationship of client and server arises by computer programs running on the respective computers and having a client-server relationship to each other.
  • steps may be reordered, added or deleted using the various forms of flow shown above.
  • each step described in the present disclosure may be executed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in the present disclosure can be achieved, no limitation is imposed herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Stored Programmes (AREA)

Abstract

本公开提供了一种跨域授权处理方法，涉及互联网技术领域，本方法包括：响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，所述目标应用为所述策略部署请求指示的待进行跨域授权配置的应用；获取用户针对所述至少一个跨域授权选项输入的策略描述数据；基于所述策略描述数据，生成针对所述目标应用的跨域授权策略；以及将所述跨域授权策略与所述目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对所述目标应用的跨域调用。本公开还提供了一种跨域调用处理方法、一种跨域控制处理平台、一种跨域调用实现系统、一种电子设备、一种计算机可读存储介质和一种计算机程序产品。

Description

跨域授权处理方法及跨域调用处理方法 技术领域
本公开涉及互联网技术领域，涉及一种跨域授权处理方法、跨域调用处理方法、跨域控制处理平台、跨域调用实现系统、电子设备、计算机可读存储介质和计算机程序产品。
背景技术
目前一些项目的产品研发或业务体系采用了前后端分离的技术架构。在该种技术架构模式下，不同终端或应用服务器间容易出现跨域调用服务的现象。针对共享资源制定的跨域授权策略的合理性和时效性，影响了跨域调用服务的安全性。
发明内容
本公开提供了一种跨域授权处理方法、跨域调用处理方法、跨域控制处理平台、跨域调用实现系统、电子设备、计算机可读存储介质和计算机程序产品。
根据第一方面，提供了一种跨域授权处理方法，该方法包括：响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，所述目标应用为所述策略部署请求指示的待进行跨域授权配置的应用；获取用户针对所述至少一个跨域授权选项输入的策略描述数据；基于所述策略描述数据，生成针对所述目标应用的跨域授权策略；以及将所述跨域授权策略与所述目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对所述目标应用的跨域调用。
根据第二方面，提供了一种跨域调用处理方法，该方法包括：接收来自请求方的跨域调用请求，所述跨域调用请求指示所述请求方请求调用的目标应用，其中，所述请求方和所述目标应用归属于不同网络域；获取与所述目标应用的API对象关联的预设跨域授权策略，其中，所述API对象为用于供所述目标应用提供跨域调用服务的接口对象；基于所述跨域授权策略和所述跨域调用请求，确定所述请求方是否具有针对所述目标应用的跨域调用权限；以及在确定所述请求方具有针对所述目标应用的跨域调用权限的情况下，建立所述请求方与所述目标应用间的跨域路由，以使所述目标应用基于所述跨域路由获取所述跨域调用请求并响应。
根据第三方面，提供了一种跨域控制处理平台，该处理平台包括：显示模块，用于响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，所述目标应用为所述策略部署请求指示的待进行跨域授权配置的应用；第一获取模块，用于获取用户针对所述至少一个跨域授权选项输入的策略描述数据；第一处理模块，用于基于所述策略描述数据，生成针对所述目标应用的跨域授权策略；以及第二处理模块，用于将所述跨域授权策略与所述目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对所述目标应用的跨域调用。
根据第四方面，提供了一种跨域控制处理平台，该处理平台包括：接收模块，用于接收来自请求方的跨域调用请求，所述跨域调用请求指示所述请求方请求调用的目标应用，其中，所述请求方和所述目标应用归属于不同网络域；第二获取模块，用于获取与所述目标应用的API对象关联的预设跨域授权策略，其中，所述API对象为用于供所述目标应用提供跨域调用服务的接口对象；第三处理模块，基于所述跨域授权策略和所述跨域调用请求，确定所述请求方是否具有针对所述目标应用的跨域调用权限；以及第四处理模块，用于在确定所述请求方具有针对所述目标应用的跨域调用权限的情况下，建立所述请求方与所述目标应用间的跨域路由，以使所述目标应用基于所述跨域路由获取所述跨域调用请求并响应。
根据第五方面，提供了一种跨域调用实现系统，该实现系统包括：根据本公开提供的跨域控制处理平台，和用于提供跨域调用服务的应用服务器。
根据第六方面，提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行根据本公开提供的方法。
根据第七方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行根据本公开提供的方法。
根据第八方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据本公开提供的方法。
应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
附图用于更好地理解本方案，不构成对本公开的限定。其中：
图1示意性示出了根据本公开实施例的跨域调用处理方法和装置的示例性业务框架示意图；
图2示意性示出了根据本公开实施例的一种跨域授权处理方法的流程图；
图3示意性示出了根据本公开实施例的跨域授权选项的示意图；
图4示意性示出了根据本公开实施例的将跨域授权策略与目标应用的API对象进行关联的示意图；
图5示意性示出了根据本公开实施例的一种跨域调用处理方法；
图6示意性示出了根据本公开实施例的一种跨域调用实现流程的示意图；
图7示意性示出了根据本公开实施例的一种跨域调用实现系统的示意图；
图8示意性示出了根据本公开实施例的一种跨域控制处理平台的示意图；
图9示意性示出了根据本公开实施例的另一跨域控制处理平台的示意图；
图10示意性示出了根据本公开实施例的电子设备的示意性框图。
具体实施方式
以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
目前一些项目的产品研发或业务体系采用了前后端分离的技术架构，在该种技术架构模式下，不同终端或应用服务器间容易出现跨域调用服务的现象。例如，在该种技术架构模式下，前端发起的XML Http Request容易出现跨域调用服务的现象。当某一请求URL(Uniform Resource Locator，统一资源定位符)中的协议、域名、端口号的任一项与目标应用URL不同时，该请求相对于目标应用为跨域请求。
示例性地，目标网页地址为http：//www.example.com/dir/page.html，
其协议为http：//，域名为www.example.com，端口为80(默认端口可以省略)。
http：//v2.example.com/dir/page.html为与目标网页域名不同的非同源网页，
http：//www.example.com：81/dir/page.html为与目标网页端口不同的非同源网页。
跨域资源共享(Cross-Origin Resource sharing，CORS)属于一种浏览器技术规范，用于允许当前网络域的浏览器接收跨域服务器发出的XML Http Request请求，是一种允许当前网络域的资源被其他网络域中的应用共享访问的通信机制。针对共享资源(即各个域内允许其他域访问的资源)制定跨域授权策略，可以有效阻隔恶意跨域调用，保证跨域调用安全。跨域授权策略制定的合理性和时效性，影响跨域调用服务的安全性。
针对为实现一种跨域策略部署灵活、跨域调用安全性高的跨域调用服务，本公开提出一种跨域授权处理方法、一种跨域调用处理方法、一种跨域控制处理平台、一种跨域调用实现系统、一种电子设备、一种存储有计算机指令的非瞬时计算机可读存储介质及一种计算机程序产品。
图1示意性示出了根据本公开实施例的跨域调用处理方法和装置的示例性业务框架示意图。需要注意的是，图1所示仅为可以应用本公开实施例的业务系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。
如图1所示，本实施例的业务框架100可以包括请求方101、跨域控制处理平台102、应用服务器103和网络104。网络104为用于在请求方101、跨域控制处理平台102和应用服务器103之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等。应用服务器103可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或分布式系统，还可以是提供云服务、云计算、网络服务、中间件服务等基础云计算服务的云服务器。
跨域控制处理平台102接收来自请求方(如图1中的请求方101)的跨域调用请求，跨域调用请求指示请求方请求调用的目标应用(例如可以是由图1中的应用服务器103实现的应用)。请求方和目标应用可以归属于不同网络域，也即请求方101与应用服务器103可以归属于不同网络域。跨域控制处理平台102获取与目标应用的API(Application Programming Interface，应用程序接口)对象关联的预设跨域授权策略，API对象为用于供目标应用提供跨域调用服务的接口对象。跨域控制处理平台102基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限。在确定请求方具有针对目标应用的跨域调用权限的情况下，建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并进行响应。
图2示意性示出了根据本公开实施例的一种跨域授权处理方法的流程图。
如图2所示，跨域授权处理方法200可以包括操作S210～操作S240。
在操作S210，响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，目标应用为策略部署请求指示的待进行跨域授权配置的应用。
接下来，在操作S220，获取用户针对至少一个跨域授权选项输入的策略描述数据。
接下来，在操作S230，基于策略描述数据，生成针对目标应用的跨域授权策略。
接下来，在操作S240，将跨域授权策略与目标应用的API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对目标应用的跨域调用。
下面详细说明本实施例的跨域授权处理方法的各步骤的示例流程。
在操作S210，响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，目标应用为策略部署请求指示的待进行跨域授权配置的应用。
在本实施例中，接收来自请求方的策略部署请求，策略部署请求指示待进行跨域授权配置的目标应用。策略部署请求表征请求方请求部署针对目标应用的跨域授权策略，跨域授权策略描述了由其他网络域的应用跨域调用目标应用中的共享资源信息时的调用授权规则。发起策略部署请求的请求方可以是与目标应用关联的API对象的API管理用户，API对象为用于供目标应用提供跨域调用服务的应用程序编程接口对象，API对象中封装有底层的API函数与功能。
API对象包括调用类API对象和被调用类API对象，不同API对象可用于实现不同功能，例如可用于实现远程过程调用、文件传输、信息耦合、标准语言查询等功能，因此，目标应用可能对应不止一个API对象。基于预设的API对象功能与API对象调用关系，目标应用可以基于至少一个API对象向其他网络域中的应用提供跨域调用服务。
响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，跨域授权选项用于配置与目标应用关联的跨域调用权限。图3示意性示出了根据本公开实施例的跨域授权选项的示意图，如图3所示，跨域授权选项例如可以包括跨域策略名称、跨域策略描述、跨域传递选项、允许请求来源、允许请求方法、允许请求头、暴露请求头、预检时间等内容。
例如，跨域策略描述为非必填项，其用于指示跨域授权策略的作用。跨域传递选项指示跨域调用服务是否需要传递cookie内容，cookie为网站用于辨别用户身份，进行session(时域)追踪而存储在用户本地终端中的数据，cookie格式示例如下：
Set-cookie:“Name＝value；domain＝.domain.com；path＝/；expires＝time；Http Only；secure”
其中，Name指示唯一确定的cookie名称，value为存储于cookie中的字符串值；domain指示cookie生效的域对象，即向该域发送的请求中需要包含此cookie；path指示cookie的作用路径，浏览器可基于作用路径向指定域发送cookie消息；expires指示cookie的失效时间；secure构成cookie的安全标志。
根据本公开实施例，允许请求来源指示目标应用允许接入的跨域调用请求来源；允许请求方法指示目标应用提供的跨域调用服务所支持的HTTP请求类型；允许请求头指示允许由API对象传递给目标应用的请求头信息；暴露请求头指示允许由目标应用传递给API对象，并进一步由API对象传递给请求方的请求头信息；预检时间指示将接收的跨域调用请求传递给目标应用进行安全认证的时间周期信息。可以根据针对允许请求头选项的策略配置参数，确定请求方是否具有针对目标应用的跨域调用请求权限；根据针对暴露请求头选项的策略配置参数，确定目标应用是否具有针对请求方的跨域调用响应权限。此外，为简化跨域策略配置流程，跨域控制处理平台中集成有默认配置信息，默认配置信息为未对用户暴露的默认基础信息，例如包括默认的允许请求头信息和默认的暴露请求头信息。
接下来，在操作S220，获取用户针对至少一个跨域授权选项输入的策略描述数据。
在本实施例中，获取用户针对至少一个跨域授权选项输入的策略描述数据，即获取API管理用户针对各跨域授权选项输入的策略描述数据，策略描述数据为用于生成与目标应用关联的跨域授权策略的元数据。例如，目标应用所属网络域为www.qcloud.com，API管理用户针对“允许请求来源”选项输入的策略描述数据为apigw.qcloud.com，即允许源自“apigw.qcloud.com”网络域中的HTTP请求从“www.qcloud.com”网络域的目标应用中跨域调用资源。
API管理用户可以针对不同跨域授权选项配置策略描述数据，可以通过提交表单形式完成配置策略描述数据。通过对目标网络域中的资源信息进行统一灵活管理，该种设计有利于实现跨域授权策略配置的自主性与灵活性，有利于在满足资源管理自定义需求的基础上，保证跨域调用资源信息的安全性。
接下来，在操作S230，基于策略描述数据，生成针对目标应用的跨域授权策略。
在本实施例中，基于获取的与各跨域授权选项关联的策略描述数据，生成针对目标 应用的跨域授权策略，生成的跨域授权策略支持修改与删除操作。跨域授权策略的实体形式可以是xml文档形式的跨域授权策略文件，例如可以是crossdomain.xml文件，crossdomain.xml文件中包含cross-domain-policy根元素，根元素为跨域授权策略文件中的策略定义容器。
接下来，在操作S240，将跨域授权策略与目标应用的API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对目标应用的跨域调用。
在本实施例中，图4示意性示出了根据本公开实施例的将跨域授权策略与目标应用的API对象进行关联的示意图，将跨域授权策略与目标应用的API对象进行关联，实现基于API对象级别管理针对目标应用的跨域授权策略。相比于相关技术中的基于应用级别管理跨域授权策略，本设计能够有效减小跨域授权策略管理的颗粒度，提升跨域调用控制的精细化程度。
根据本公开实施例，跨域控制处理平台可以提供API扫描功能，其可以根据用户设定的扫描条件展示与目标应用关联的API对象。与目标应用关联的跨域授权策略能够以插件的形式进行管理，在跨域调用控制过程中，可以根据实际跨域调用需要，将跨域授权策略与目标应用的特定API对象进行绑定，以此实现针对跨域授权策略与目标应用的API对象间的关联管理。在将跨域授权策略与目标应用的API对象进行关联时，跨域授权策略与API对象之间未进行功能耦合，二者底层数据可以不进行合并。跨域授权策略与API对象之间的解耦关联关系，有利于实现精细化程度更高、灵活性更完善的跨域调用控制，能够很好地适用于应用场景丰富的微服务应用环境。微服务应用是通过构建多个独立功能单元(即服务)来开发单个应用的实现形式，每个功能单元可以独立运行于各自进程中，不同功能单元间通过轻量级通信方式进行数据交互。微服务应用具有扩展性良好、可靠性高、维护成本低的优势。
在生成针对目标应用的跨域授权策略之后，执行跨域授权策略与目标应用的API对象间的绑定操作。与目标应用关联的API对象设置有预设调用属性，预设调用属性例如可以包括鉴权方式、接入协议类型、允许请求方法类型、请求格式、服务接口地址等信息。由于跨域授权策略与预设调用属性中都可能包含针对API对象的调用参数信息，因此，跨域授权策略与API对象的预设调用属性之间可能存在策略冲突。
在与目标应用关联的至少一个API对象中，可能包含预设调用属性与跨域授权策略不存在策略冲突的部分API对象，也可能包含预设调用属性与跨域授权策略存在策略冲 突的部分API对象。在预设调用属性与跨域授权策略存在策略冲突的部分API对象中，还可能包含能够进行冲突消除处理的API对象。为表述方便，将预设调用属性与跨域授权策略不存在策略冲突的部分API对象表述为第一API对象，将预设调用属性与跨域授权策略存在策略冲突的部分API对象表述为第二API对象，将第二API对象中进行冲突消除处理后的API对象表述为第三API对象。
如图4所示，在将跨域授权策略与目标应用的API对象进行关联时，针对与目标应用关联的至少一个API对象，根据至少一个API对象中的各API对象的预设调用属性，确定跨域授权策略与各API对象的预设调用属性之间是否存在策略冲突。针对不存在策略冲突的至少一个第一API对象，执行跨域授权策略与各第一API对象的关联操作。针对存在策略冲突的至少一个第二API对象，确定是否能够针对各第二API对象的预设调用属性进行冲突消除处理；以及针对经冲突消除处理后的至少一个第三API对象，执行跨域授权策略与各第三API对象之间的关联操作。例如，冲突消除处理可以包括：在确定跨域授权策略与任一API对象的预设调用属性之间存在策略冲突的情况下，可以根据业务需求与API对象功能，重新制定API对象的预设调用属性，以实现消除策略冲突。本领域技术人员可以理解，可以使用其他方式来实现冲突消除，本公开实施例不对此进行限制。
针对目标应用的跨域授权策略支持修改与删除操作，响应于接收的针对目标应用的策略变更请求，显示与目标应用关联的至少一个跨域授权已配置项。然后，获取用户针对至少一个跨域授权已配置项输入的策略变更数据，以及基于策略变更数据，更新针对目标应用的跨域授权策略。将更新后的跨域授权策略与目标应用的API对象进行关联，以便基于相关联的API对象和已更新跨域授权策略，进行针对目标应用的跨域调用。相较于相关技术中的通过配置模板化代码的形式维护针对共享资源的跨域授权策略，本设计能够有效减少跨域授权策略的更新成本，改善跨域授权策略的修订便捷性，能够有效保证跨域授权策略配置的实时性与合理性。
可选地，为实现精细化控制跨域调用服务，配置与API对象关联的流量控制参数，以便基于流量控制参数和跨域授权策略进行针对目标应用的跨域调用。流量控制参数指示API对象允许在单位时长内接入的跨域调用请求阈值，流量控制参数例如包括对外调用限制(单位次/秒)和对内调用限制(单位次/秒)。另外，还可以配置与API对象关联的跨域启用参数，以便基于跨域启用参数和跨域授权策略进行针对目标应用的跨域调 用，其中，跨域启用参数指示API对象是否允许启用跨域调用服务。
根据本公开实施例，响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，目标应用为策略部署请求指示的待进行跨域授权配置的应用；获取用户针对至少一个跨域授权选项输入的策略描述数据；基于策略描述数据，生成针对目标应用的跨域授权策略；以及将跨域授权策略与目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对目标应用的跨域调用。通过显示与目标应用关联的至少一个跨域授权选项，获取用户针对至少一个跨域授权选项输入的策略描述数据，根据策略描述数据生成针对目标应用的跨域授权策略，并将跨域授权策略与目标应用的API对象进行关联。本设计能够有效控制跨域授权策略的配置成本与更新代价，提升跨域授权策略的合成效率及修订便捷性，有利于保证跨域授权策略的实时性与合理性。此外，基于API对象级别维护针对目标应用的跨域授权策略，有利于提高跨域调用控制的精细化程度，提高不同网络域间信息资源共享的安全性，有利于实现安全、高效的跨域资源共享机制。
图5示意性示出了根据本公开实施例的一种跨域调用处理方法。
如图5所示，跨域调用处理方法500可以包括操作S510～操作S540。
在操作S510，接收来自请求方的跨域调用请求，跨域调用请求指示请求方请求调用的目标应用，其中，请求方和目标应用归属于不同网络域。
接下来，在操作S520，获取与目标应用的API对象关联的预设跨域授权策略，其中，API对象为用于供目标应用提供跨域调用服务的接口对象。
接下来，在操作S530，基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限。
接下来，在操作S540，在确定请求方具有针对目标应用的跨域调用权限的情况下，建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并响应。
下面详细说明本实施例的跨域调用处理方法的各步骤的示例流程。
在操作S510，接收来自请求方的跨域调用请求，跨域调用请求指示请求方请求调用的目标应用，其中，请求方和目标应用归属于不同网络域。
在本实施例中，接收来自请求方的跨域调用请求，跨域调用请求指示请求方请求跨域调用的目标应用。来自请求方的跨域调用请求可能是简单跨域请求，也可能是非简单 跨域请求，简单跨域请求中的请求方法为HEAD、GET、POST方法之一，非简单跨域请求中的请求方法包括OPTIONS方法。OPTIONS方法用于在正式通信之前，请求通过增加一次HTTP请求，预检后续跨域调用实际请求可否安全送出。简单跨域请求和非简单跨域请求的区分方法可参考现有技术中的相关定义内容，本实施例在此不进行赘述。
跨域调用请求可以包含Origin字段，Origin字段用于指示跨域调用请求来源。示例性地，跨域调用请求中包含字段Host：qcloud.com，以及字段Origin:http://apigw.qcloud.com，跨域调用请求指示apigw.qcloud.com请求调用qcloud.com中的资源。
可选地，与跨域调用请求关联的请求方及目标应用可以是归属于不同网络域的浏览器，与目标应用关联的API对象可以封装在浏览器插件或浏览器组件，或内置于浏览器中。
接下来，在操作S520，获取与目标应用的API对象关联的预设跨域授权策略，其中，API对象为用于供目标应用提供跨域调用服务的接口对象。
在本实施例中，针对与目标应用关联的至少一个API对象，获取与各API对象关联的跨域启用参数，根据与各API对象关联的跨域启用参数，确定对应API对象是否允许启用跨域调用服务；以及针对允许启用跨域调用服务的至少一个API对象，获取与各API对象关联的跨域授权策略。可选地，从API数据库中获取与各API对象关联的跨域授权策略，并将跨域授权策略保存至Redis(Remote Dictionary Server，远程字典服务)缓存中，并针对缓存数据设置预设的生命周期时长。
作为一种可行的方式，在获取与目标应用的API对象关联的跨域授权策略之前，获取与请求方关联的用户属性证书，基于用户属性证书，确定请求方是否已订阅针对目标应用的跨域调用服务，以及在确定请求方已订阅针对目标应用的跨域调用服务的情况下，执行获取跨域授权策略的操作。请求方需要依据要求事先在管理平台中订阅跨域调用服务，以使管理平台生成针对请求方的系统令牌，和/或AK(Access Key，访问密钥)/SK(Secret Key，安全密钥)鉴权密钥。
此外，还可以获取与目标应用关联的服务签约数据，基于服务签约数据，确定目标应用是否已注册与跨域调用请求关联的跨域调用服务，以及在确定目标应用已注册与跨域调用请求关联的跨域调用服务的情况下，执行获取跨域授权策略的操作。目标应用需要依据要求事先在管理平台中注册其所提供的跨域调用服务，否则无法基于API调用实 现跨域调用服务。本设计可以无需跨域调用服务提供方重复申请跨域调用服务，以及无需提供方自主进行跨域调用负载均衡的繁琐操作，有利于改善跨域调用服务API调用的便捷性。
接下来，在操作S530，基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限。
在本实施例中，跨域调用请求包括与请求方关联的调用接口信息和调用类型信息，调用接口信息例如可以是由Origin字段指示的调用接口地址信息，调用类型信息例如可以是跨域调用请求中的请求方法类型信息，请求方法例如可以包括POST、GET、PUT、DELETE等方法类型。
在基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限时，可以根据与API对象关联的跨域授权策略，以及根据跨域调用请求中的调用接口信息和调用类型信息，确定请求方是否具有针对目标应用的跨域调用请求权限，并确定目标应用是否具有针对请求方的跨域调用响应权限。在确定请求方具有针对目标应用的跨域调用请求权限且目标应用具有针对请求方的跨域调用响应权限的情况下，确定请求方具有通过API对象跨域调用目标应用的权限。例如，可以根据跨域调用请求，以及根据跨域授权策略中的允许请求来源、允许请求方法、允许请求头信息，确定请求方是否具有针对目标应用的跨域调用请求权限；根据跨域授权策略中的暴露请求头信息，确定目标应用是否具有针对请求方的跨域调用响应权限。
在接收的跨域调用请求为非简单跨域请求的情况下，需要先将非简单跨域请求以预检请求的形式发送给目标应用进行预检校验，以及预检校验通过的情况下，将非简单跨域请求以正式请求的形式发送给目标应用进行响应处理。此外，在预检校验通过的情况下，根据跨域授权策略中的预检时间特征指示的时间周期，将对应时间周期内接收的来自同一请求方的非简单跨域请求，作为简单跨域请求直接处理。因此，作为一种可行的方式，在确定请求方具有通过API对象跨域调用目标应用的权限后，还可以根据跨域授权策略中的预检时间特征，确定是否要将跨域调用请求通过API对象传递给目标应用，以使目标应用基于跨域调用请求确定是否允许本次跨域调用。
接下来，在操作S540，在确定请求方具有针对目标应用的跨域调用权限的情况下，建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并响应。
在本实施例中，在确定请求方具有可通过M个API对象来跨域调用目标应用的权限的情况下，在建立请求方与目标应用间的跨域路由时，可以确定请求方与M个API对象中的各API对象构成的M个跨域路由的网络性能信息，网络性能信息指示对应跨域路由的网络性能，然后，选取M个跨域路由中网络性能最优的跨域路由，作为请求方与目标应用间的跨域路由，其中，M为大于1的整数，网络性能信息包括网络时延信息和/或网络带宽信息。
请求方与API对象构成的跨域路由的网络性能可由网络时延信息和/或网络带宽信息指示，网络性能与对应API对象的支持网络协议能力、线速转发能力等因素有关，也与对应API对象待处理的数据流大小、数据流量速率等因素有关。在请求方与各API对象构成的M个跨域路由中，选择网络性能最优的N个跨域路由，作为网络域间传输数据的路由路径，N为不小于1的整数。
建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并响应。作为一种可行的方式，将自请求方获取的跨域调用请求通过API对象传递给目标应用，和/或将自API对象获取的跨域调用响应信息传递给请求方，跨域调用响应信息是目标应用基于跨域调用请求响应得到的。
在将跨域调用请求通过API对象传递给目标应用时，可以将与API对象关联的跨域授权策略添加至跨域调用请求的请求头中，得到处理后的跨域调用请求。然后，将处理后的跨域调用请求通过API对象传递给目标应用，以使目标应用提取请求头中的跨域授权策略，并基于跨域授权策略决定是否允许本次跨域调用。
作为一种可行的方式，还可以获取与目标应用的API对象关联的流量控制参数，并将流量控制参数和跨域授权策略添加至跨域调用请求的请求头中，得到处理后的跨域调用请求。然后，将处理后的跨域调用请求通过API对象传递给目标应用，以使目标应用基于处理后的跨域调用请求确定是否允许本次跨域调用，例如，以使目标应用提取请求头中的流量控制参数和跨域授权策略，根据跨域授权策略以及根据流量控制参数中的对内调用限制信息和对外调用限制信息，决定是否允许通过对应API对象进行本次跨域调用。
根据本公开实施例，接收来自请求方的跨域调用请求，跨域调用请求指示请求方请求调用的目标应用，其中，请求方和目标应用归属于不同网络域；获取与目标应用的API对象关联的预设跨域授权策略，其中，API对象为用于供目标应用提供跨域调用服 务的接口对象；基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限；以及在确定请求方具有针对目标应用的跨域调用权限的情况下，建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并响应。根据与目标应用的API对象关联的跨域授权策略，执行针对请求方与目标应用间的跨域调用控制操作，可以实现根据自定义资源管理需求，在满足业务需求的同时，提升跨域调用控制的精细化程度，保证不同网络域之间信息调用的安全性，有利于实现多网络域之间的资源共享，有利于实现针对不同网络域中的共享资源的统一灵活管理。
图6示意性示出了根据本公开实施例的一种跨域调用实现流程的示意图。
如图6所示，该跨域调用实现流程可以包括操作S601～操作S615。
由跨域调用控制平台执行跨域调用实现流程，跨域调用实现流程可以包括跨域策略配置流程和跨域调用处理流程，跨域调用控制平台可以包括微服务应用平台和微服务网关。由微服务应用平台执行跨域策略配置流程，跨域策略配置流程可以包括操作S601～操作S610。由微服务网关执行跨域调用处理流程，跨域调用处理流程可以包括操作S601～操作S615。
在跨域策略配置流程中，可以执行包括：
在操作S601，响应于接收的策略部署请求，触发跨域授权策略的创建事件。
在一个示例中，响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，并获取用户针对至少一个跨域授权选项输入的策略描述数据。目标应用为策略部署请求指示的待进行跨域授权配置的应用。
接下来，在操作S602，校验获取的策略描述数据中是否包含Origin(来源)字段，若是，继续执行操作S603，以及若否，将策略描述数据返回用户端进行修改，其中，Origin字段指示允许的跨域调用请求来源。
接下来，在操作S603，校验获取的策略描述数据中是否包含Credentials(资格证书)字段，若是，继续执行操作S604，以及若否，将策略描述数据返回用户端进行修改，其中，Credentials字段指示跨域调用服务是否需要传递cookie内容。
接下来，在操作S604，preflight(预检时间)修正，其中，预检时间指示将接收的跨域调用请求传递给目标应用进行安全认证的时间周期信息。
接下来，在操作S605，追加Request Header字段(要求头字段)默认值，其中，Request Header字段指示要求跨域调用请求中包含的请求头信息。
接下来，在操作S606，基于获取的策略描述数据生成跨域授权策略。
接下来，在操作S607，判断是否已将跨域授权策略与目标应用的API对象进行关联，若是，执行操作S608；以及若否，执行操作S608’。
在操作S608，查询与跨域授权策略关联的所有API对象。
在操作S608’，手动将跨域授权策略与目标应用的API对象进行关联。
在操作S608及操作S608’之后，执行操作S609，发布API对象信息。
接下来，在操作S610，将与API对象关联的跨域授权策略进行持久化保存。
在跨域调用处理流程中，可以执行包括：
在操作S611，响应于接收的来自请求方的跨域调用请求，进行针对请求方与目标应用间的路由匹配，确定可用于实现跨域调用服务的API对象，其中，跨域调用请求指示请求方请求调用的目标应用。
接下来，在操作S612，查询API对象配置信息，获取与API对象关联的跨域授权策略。
接下来，在操作S613，解析与API对象关联的跨域授权策略。
接下来，在操作S614，根据接收的跨域调用请求，以及根据与API对象关联的跨域授权策略，确定是否允许请求方的本次跨域调用，若是，执行操作S615，若否，向请求方返回请求失败的提示信息。
接下来，在操作S615，建立请求方与目标应用之间的跨域路由，以使目标应用基于跨域路由提供跨域调用服务。
图7示意性示出了根据本公开实施例的一种跨域调用实现系统的示意图。
如图7所示，跨域调用实现系统跨域可以包括为跨域控制处理平台701、消息服务集群702、缓存服务器703、存储服务器704、监控服务器705和故障切换服务器706。
跨域控制处理平台701包括微服务平台的各组件应用集群，其用于进行跨域授权策略配置和跨域调用服务中转，跨域控制处理平台701包括网关7011、注册中心7012、鉴权中心7013、微服务应用7014和配置中心7015。
由于跨域调用服务为未对请求方进行直接暴露的服务，请求方需要向网关7011发起跨域调用请求，网关7011记录跨域调用请求的详细信息，例如记录跨域调用请求中的请求头和请求体信息。网关7011通过自定义插件获取与目标应用的API对象关联的跨域授权策略，基于获取的跨域授权策略和跨域调用请求，确定是否允许请求方的本次 跨域调用。在确定允许本次跨域调用的情况下，网关7011以中转平台的形式向目标应用传递跨域调用请求，和接收来自目标应用的跨域调用响应信息，并记录跨域调用响应信息中的响应头和响应体信息。
注册中心7012用于供目标应用注册其所提供的跨域调用服务。
鉴权中心7013用于根据请求方的用户属性证书，鉴定请求方是否已订阅与目标应用关联的跨域调用服务。
微服务应用7014用于实现跨域授权策略配置，策略配置功能可通过用户提交表单的形式完成。
配置中心7015用于提供跨域授权策略配置的默认基础信息，用户可方便将默认基础信息引入自身服务配置中，其可以免去大部分重复性的配置内容，使得策略配置功能线上透明且易维护。
消息服务集群702，用于采集并存储跨域调用过程中的日志记录。
缓存服务器703，可以是Redis服务器，用于缓存跨域调用过程中的部分不经常变化的数据，例如用于在获取与API对象关联的跨域授权策略后，将跨域授权策略进行暂时缓存。
存储服务器704，可以是MySQL(关系型数据库管理系统)服务器，用于持久化存储跨域调用过程中的数据。
监控服务器705，可以是Zabbix监控服务器，用于监控整个平台的虚机状态并进行异常告警。
故障切换服务器706，可以是MHA服务器，作为MySQL管理工具，用于维护支持MySQL的高可用架构。
图8示意性示出了根据本公开实施例的一种跨域控制处理平台的示意图。
如图8所示，跨域控制处理平台包括显示模块801、第一获取模块802、第一处理模块803以及第二处理模块804。
显示模块801，用于响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，目标应用为策略部署请求指示的待进行跨域授权配置的应用。第一获取模块802，用于获取用户针对至少一个跨域授权选项输入的策略描述数据。第一处理模块803，用于基于策略描述数据，生成针对目标应用的跨域授权策略。第二处理模块804，用于将跨域授权策略与目标应用的应用程序接口API对象进行关联，以便基 于相关联的API对象和跨域授权策略，进行针对目标应用的跨域调用。
根据本公开实施例，响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，目标应用为策略部署请求指示的待进行跨域授权配置的应用；获取用户针对至少一个跨域授权选项输入的策略描述数据；基于策略描述数据，生成针对目标应用的跨域授权策略；以及将跨域授权策略与目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对目标应用的跨域调用。通过显示与目标应用关联的至少一个跨域授权选项，获取用户针对至少一个跨域授权选项输入的策略描述数据，根据策略描述数据生成针对目标应用的跨域授权策略，并将跨域授权策略与目标应用的API对象进行关联。本设计能够有效控制跨域授权策略的配置成本与更新代价，提升跨域授权策略的修订便捷性，有利于保证跨域授权策略的实时性与合理性。此外，基于API对象级别维护针对目标应用的跨域授权策略，有利于提高跨域调用控制的精细化程度，提高不同网络域间信息资源共享的安全性。
作为一种可行的方式，第二处理模块包括：第一处理子模块，用于针对与目标应用关联的至少一个API对象，根据至少一个API对象的预设调用属性，确定跨域授权策略与预设调用属性之间是否存在策略冲突；第二处理子模块，用于针对不存在策略冲突的至少一个第一API对象，执行跨域授权策略与各第一API对象的关联操作。
作为一种可行的方式，第二处理模块还包括：第三处理子模块，用于针对存在策略冲突的至少一个第二API对象，确定是否能够针对各第二API对象的预设调用属性进行冲突消除处理；以及第四处理子模块，用于针对经冲突消除处理后的至少一个第三API对象，执行跨域授权策略与各第三API对象之间的关联操作。
作为一种可行的方式，跨域控制处理平台还包括：第五处理模块，用于响应于接收的针对目标应用的策略变更请求，显示与目标应用关联的至少一个跨域授权已配置项；获取用户针对至少一个跨域授权已配置项输入的策略变更数据；基于策略变更数据，更新针对目标应用的跨域授权策略；将更新后的跨域授权策略与目标应用的API对象进行关联，以便基于相关联的API对象和已更新跨域授权策略，进行针对目标应用的跨域调用。
作为一种可行的方式，跨域控制处理平台还包括：第六处理模块，用于配置与API对象关联的流量控制参数，以便基于流量控制参数和跨域授权策略进行针对目标应用的跨域调用，其中，流量控制参数指示API对象允许在单位时长内接入的跨域调用请求阈 值。
作为一种可行的方式，跨域控制处理平台还包括：第七处理模块，用于配置与API对象关联的跨域启用参数，以便基于跨域启用参数和跨域授权策略进行针对目标应用的跨域调用，其中，跨域启用参数指示API对象是否允许启用跨域调用服务。
图9示意性示出了根据本公开实施例的另一跨域控制处理平台的示意图。
如图9所示，跨域控制处理平台包括接收模块901、第二获取模块902、第三处理模块903以及第四处理模块904。
接收模块901，用于接收来自请求方的跨域调用请求，跨域调用请求指示请求方请求调用的目标应用，其中，请求方和目标应用归属于不同网络域。第二获取模块902，用于获取与目标应用的API对象关联的预设跨域授权策略，其中，API对象为用于供目标应用提供跨域调用服务的接口对象。第三处理模块903，基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限。第四处理模块904，用于在确定请求方具有针对目标应用的跨域调用权限的情况下，建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并响应。
根据本公开实施例，接收来自请求方的跨域调用请求，跨域调用请求指示请求方请求调用的目标应用，其中，请求方和目标应用归属于不同网络域；获取与目标应用的API对象关联的预设跨域授权策略，其中，API对象为用于供目标应用提供跨域调用服务的接口对象；基于跨域授权策略和跨域调用请求，确定请求方是否具有针对目标应用的跨域调用权限；以及在确定请求方具有针对目标应用的跨域调用权限的情况下，建立请求方与目标应用间的跨域路由，以使目标应用基于跨域路由获取跨域调用请求并响应。根据与目标应用的API对象关联的跨域授权策略，执行针对请求方与目标应用间的跨域调用控制操作，可以实现根据自定义资源管理需求，在满足业务需求的同时，提升跨域调用控制的精细化程度，保证不同网络域之间信息调用的安全性，有利于实现多网络域之间的资源共享，有利于实现针对不同网络域中的共享资源的统一灵活管理。
作为一种可行的方式，第二获取模块包括：第一获取子模块，用于针对与目标应用关联的至少一个API对象，获取与各API对象关联的跨域启用参数；第五处理子模块，用于根据与各API对象关联的跨域启用参数，确定对应API对象是否允许启用跨域调用服务；以及第六处理子模块，用于针对允许启用跨域调用服务的至少一个API对象，获取与各API对象关联的跨域授权策略。
作为一种可行的方式，跨域调用请求包括与请求方关联的调用接口信息和调用类型信息；第三处理模块包括：第七处理子模块，用于根据与API对象关联的跨域授权策略、跨域调用请求中的调用接口信息和调用类型信息，确定请求方是否具有针对目标应用的跨域调用请求权限，并确定目标应用是否具有针对请求方的跨域调用响应权限；以及第八处理子模块，用于在确定请求方具有针对目标应用的跨域调用请求权限且目标应用具有针对请求方的跨域调用响应权限的情况下，确定请求方具有通过API对象跨域调用目标应用的权限。
作为一种可行的方式，在确定请求方具有可通过M个API对象来跨域调用目标应用的权限的情况下，第四处理模块包括：第九处理子模块，用于确定请求方与M个API对象中的各API对象构成的M个跨域路由的网络性能信息，网络性能信息指示对应跨域路由的网络性能；第十处理子模块，用于选取M个跨域路由中网络性能最优的跨域路由，作为请求方与目标应用间的跨域路由，其中，M为大于1的整数，网络性能信息包括网络时延信息和/或网络带宽信息。
作为一种可行的方式，第四处理模块还包括：第十一处理子模块，用于将跨域调用请求通过API对象传递给目标应用；第十二处理子模块，用于将自API对象获取的跨域调用响应信息传递给请求方，其中，跨域调用响应信息是目标应用基于跨域调用请求响应得到的。
作为一种可行的方式，第十一处理子模块包括：第一处理单元，用于将与API对象关联的跨域授权策略添加至跨域调用请求的请求头中，得到处理后的跨域调用请求；第二处理单元，用于将处理后的跨域调用请求通过API对象传递给目标应用，以使目标应用基于处理后的跨域调用请求确定是否允许本次跨域调用。
作为一种可行的方式，第十一处理子模块还包括：第三处理单元，用于获取与目标应用的API对象关联的流量控制参数，将与API对象关联的跨域授权策略和流量控制参数添加至跨域调用请求的请求头中，得到处理后的跨域调用请求；第四处理单元，用于将处理后的跨域调用请求通过API对象传递给目标应用，以使目标应用基于处理后的跨域调用请求确定是否允许本次跨域调用。
作为一种可行的方式，跨域控制处理平台还包括：第八处理模块，用于：获取与请求方关联的用户属性证书；基于用户属性证书，确定请求方是否已订阅针对目标应用的跨域调用服务；以及在确定请求方已订阅针对目标应用的跨域调用服务的情况下，触发 第二获取模块执行获取跨域授权策略的操作。
作为一种可行的方式，跨域控制处理平台还包括：第九处理模块，用于：获取与目标应用关联的服务签约数据；基于服务签约数据，确定目标应用是否已注册与跨域调用请求关联的跨域调用服务；以及在确定目标应用已注册与跨域调用请求关联的跨域调用服务的情况下，触发第二获取模块执行获取跨域授权策略的操作。
作为一种可行的方式，跨域控制处理平台还包括：第十处理模块，用于：根据跨域授权策略中的预检时间特征，确定是否要将跨域调用请求通过API对象传递给目标应用，以使目标应用基于跨域调用请求确定是否允许本次跨域调用。
作为一种可行的方式，请求方和目标应用为归属于不同网络域的浏览器；API对象封装在浏览器插件或浏览器组件，或内置于浏览器中。
图10示意性示出了根据本公开实施例的电子设备的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图10所示，设备1000包括计算单元1001，其可以根据存储在只读存储器(ROM)1002中的计算机程序或者从存储单元1008加载到随机访问存储器(RAM)1003中的计算机程序，来执行各种适当的动作和处理。在RAM 1003中，还可存储设备1000操作所需的各种程序和数据。计算单元1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。
设备1000中的多个部件连接至I/O接口1005，包括：输入单元1006，例如键盘、鼠标等；输出单元1007，例如各种类型的显示器、扬声器等；存储单元1008，例如磁盘、光盘等；以及通信单元1009，例如网卡、调制解调器、无线通信收发机等。通信单元1009允许设备1000通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元1001可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1001的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号 处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1001执行上文所描述的各个方法和处理，例如跨域授权处理方法和跨域调用处理方法。例如，在一些实施例中，跨域授权处理方法和跨域调用处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1008。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1002和/或通信单元1009而被载入和/或安装到设备1000上。当计算机程序加载到RAM 1003并由计算单元1001执行时，可以执行上文描述的跨域授权处理方法和跨域调用处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1001可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行跨域授权处理方法和跨域调用处理方法。
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可 擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (23)

  1. 一种跨域授权处理方法，包括：
    响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，所述目标应用为所述策略部署请求指示的待进行跨域授权配置的应用；
    获取用户针对所述至少一个跨域授权选项输入的策略描述数据；
    基于所述策略描述数据，生成针对所述目标应用的跨域授权策略；以及
    将所述跨域授权策略与所述目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对所述目标应用的跨域调用。
  2. 根据权利要求1所述的方法，其中，所述将所述跨域授权策略与所述目标应用的API对象进行关联，包括：
    针对与所述目标应用关联的至少一个API对象，根据所述至少一个API对象的预设调用属性，确定所述跨域授权策略与所述预设调用属性之间是否存在策略冲突；
    针对不存在策略冲突的至少一个第一API对象，执行所述跨域授权策略与各所述第一API对象的关联操作。
  3. 根据权利要求2所述的方法，还包括：
    针对存在策略冲突的至少一个第二API对象，确定是否能够针对各所述第二API对象的预设调用属性进行冲突消除处理；以及
    针对经冲突消除处理后的至少一个第三API对象，执行所述跨域授权策略与各所述第三API对象之间的关联操作。
  4. 根据权利要求1至3中任一项所述的方法，还包括：
    响应于接收的针对所述目标应用的策略变更请求，显示与所述目标应用关联的至少一个跨域授权已配置项；
    获取用户针对所述至少一个跨域授权已配置项输入的策略变更数据；
    基于所述策略变更数据，更新针对所述目标应用的跨域授权策略；
    将更新后的跨域授权策略与所述目标应用的API对象进行关联，以便基于相关联的API对象和已更新跨域授权策略，进行针对所述目标应用的跨域调用。
  5. 根据权利要求1所述的方法，还包括：
    配置与所述API对象关联的流量控制参数，以便基于所述流量控制参数和所述跨 域授权策略进行针对所述目标应用的跨域调用，
    其中，所述流量控制参数指示所述API对象允许在单位时长内接入的跨域调用请求阈值。
  6. 根据权利要求1所述的方法，还包括：
    配置与所述API对象关联的跨域启用参数，以便基于所述跨域启用参数和所述跨域授权策略进行针对所述目标应用的跨域调用，
    其中，所述跨域启用参数指示所述API对象是否允许启用跨域调用服务。
  7. 一种跨域调用处理方法，包括：
    接收来自请求方的跨域调用请求，所述跨域调用请求指示所述请求方请求调用的目标应用，其中，所述请求方和所述目标应用归属于不同网络域；
    获取与所述目标应用的API对象关联的预设跨域授权策略，其中，所述API对象为用于供所述目标应用提供跨域调用服务的接口对象；
    基于所述跨域授权策略和所述跨域调用请求，确定所述请求方是否具有针对所述目标应用的跨域调用权限；以及
    在确定所述请求方具有针对所述目标应用的跨域调用权限的情况下，建立所述请求方与所述目标应用间的跨域路由，以使所述目标应用基于所述跨域路由获取所述跨域调用请求并响应。
  8. 根据权利要求7所述的方法，其中，所述获取与所述目标应用的API对象关联的预设跨域授权策略，包括：
    针对与所述目标应用关联的至少一个API对象，获取与各所述API对象关联的跨域启用参数；
    根据与各所述API对象关联的跨域启用参数，确定对应API对象是否允许启用跨域调用服务；以及
    针对允许启用跨域调用服务的至少一个API对象，获取与各所述API对象关联的跨域授权策略。
  9. 根据权利要求7所述的方法，其中，
    所述跨域调用请求包括与所述请求方关联的调用接口信息和调用类型信息；
    所述基于所述跨域授权策略和所述跨域调用请求，确定所述请求方是否具有针对所述目标应用的跨域调用权限，包括：
    根据与所述API对象关联的跨域授权策略、所述跨域调用请求中的调用接口信息和调用类型信息，确定所述请求方是否具有针对所述目标应用的跨域调用请求权限，并确定所述目标应用是否具有针对所述请求方的跨域调用响应权限；以及
    在确定所述请求方具有针对所述目标应用的跨域调用请求权限且所述目标应用具有针对所述请求方的跨域调用响应权限的情况下，确定所述请求方具有通过所述API对象跨域调用所述目标应用的权限。
  10. 根据权利要求9所述的方法，其中，
    在确定所述请求方具有可通过M个API对象来跨域调用所述目标应用的权限的情况下，所述建立所述请求方与所述目标应用间的跨域路由，包括：
    确定所述请求方与所述M个API对象中的各API对象构成的M个跨域路由的网络性能信息，所述网络性能信息指示对应跨域路由的网络性能；
    选取所述M个跨域路由中网络性能最优的跨域路由，作为所述请求方与所述目标应用间的跨域路由，
    其中，M为大于1的整数，所述网络性能信息包括网络时延信息和/或网络带宽信息。
  11. 根据权利要求10所述的方法，其中，所述以使所述目标应用基于所述跨域路由获取所述跨域调用请求并响应，包括：
    将所述跨域调用请求通过所述API对象传递给所述目标应用；和/或
    将自所述API对象获取的跨域调用响应信息传递给所述请求方，其中，所述跨域调用响应信息是所述目标应用基于所述跨域调用请求响应得到的。
  12. 根据权利要求11所述的方法，其中，所述将所述跨域调用请求通过所述API对象传递给所述目标应用，包括：
    将与所述API对象关联的跨域授权策略添加至所述跨域调用请求的请求头中，得到处理后的跨域调用请求；
    将所述处理后的跨域调用请求通过所述API对象传递给所述目标应用，以使所述目标应用基于所述处理后的跨域调用请求确定是否允许本次跨域调用。
  13. 根据权利要求11所述的方法，还包括：
    获取与所述目标应用的API对象关联的流量控制参数；
    所述将所述跨域调用请求通过所述API对象传递给所述目标应用，包括：
    将与所述API对象关联的跨域授权策略和流量控制参数添加至所述跨域调用请求的请求头中，得到处理后的跨域调用请求；
    将所述处理后的跨域调用请求通过所述API对象传递给所述目标应用，以使所述目标应用基于所述处理后的跨域调用请求确定是否允许本次跨域调用。
  14. 根据权利要求7所述的方法，其中，在获取与所述目标应用的API对象关联的跨域授权策略之前，还包括：
    获取与所述请求方关联的用户属性证书；
    基于所述用户属性证书，确定所述请求方是否已订阅针对所述目标应用的跨域调用服务；以及
    在确定所述请求方已订阅针对所述目标应用的跨域调用服务的情况下，执行获取所述跨域授权策略的操作。
  15. 根据权利要求7所述的方法，其中，在获取与所述目标应用的API对象关联的跨域授权策略之前，还包括：
    获取与所述目标应用关联的服务签约数据；
    基于所述服务签约数据，确定所述目标应用是否已注册与所述跨域调用请求关联的跨域调用服务；以及
    在确定所述目标应用已注册与所述跨域调用请求关联的跨域调用服务的情况下，执行获取所述跨域授权策略的操作。
  16. 根据权利要求7所述的方法，其中，在建立所述请求方与所述目标应用间的跨域路由之前，还包括：
    根据所述跨域授权策略中的预检时间特征，确定是否要将所述跨域调用请求通过所述API对象传递给所述目标应用，以使所述目标应用基于所述跨域调用请求确定是否允许本次跨域调用。
  17. 根据权利要求7至16中任一项所述的方法，其中，所述请求方和所述目标应用为归属于不同网络域的浏览器；所述API对象封装在浏览器插件或浏览器组件，或内置于浏览器中。
  18. 一种跨域控制处理平台，包括：
    显示模块，用于响应于接收的策略部署请求，显示与目标应用关联的至少一个跨域授权选项，其中，所述目标应用为所述策略部署请求指示的待进行跨域授权配置的 应用；
    第一获取模块，用于获取用户针对所述至少一个跨域授权选项输入的策略描述数据；
    第一处理模块，用于基于所述策略描述数据，生成针对所述目标应用的跨域授权策略；以及
    第二处理模块，用于将所述跨域授权策略与所述目标应用的应用程序接口API对象进行关联，以便基于相关联的API对象和跨域授权策略，进行针对所述目标应用的跨域调用。
  19. 一种跨域控制处理平台，包括：
    接收模块，用于接收来自请求方的跨域调用请求，所述跨域调用请求指示所述请求方请求调用的目标应用，其中，所述请求方和所述目标应用归属于不同网络域；
    第二获取模块，用于获取与所述目标应用的API对象关联的预设跨域授权策略，其中，所述API对象为用于供所述目标应用提供跨域调用服务的接口对象；
    第三处理模块，基于所述跨域授权策略和所述跨域调用请求，确定所述请求方是否具有针对所述目标应用的跨域调用权限；以及
    第四处理模块，用于在确定所述请求方具有针对所述目标应用的跨域调用权限的情况下，建立所述请求方与所述目标应用间的跨域路由，以使所述目标应用基于所述跨域路由获取所述跨域调用请求并响应。
  20. 一种跨域调用实现系统，包括：权利要求18或19所述的跨域控制处理平台，和用于提供跨域调用服务的应用服务器。
  21. 一种电子设备，包括：
    至少一个处理器；
    以及与所述至少一个处理器通信连接的存储器；
    其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1至6中任一项所述的方法，或实现权利要求7至17中任一项所述的方法。
  22. 一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器实现权利要求1至6中任一项所述的方法，或实现权利要求7至17中任一项所述的方法。
  23. 一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法，或实现权利要求7至17中任一项所述的方法。
PCT/CN2021/114923 2021-08-27 2021-08-27 跨域授权处理方法及跨域调用处理方法 WO2023024057A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/758,126 US20240193249A1 (en) 2021-08-27 2021-08-27 Method of processing cross-domain authorization and method of processing cross-domain call
PCT/CN2021/114923 WO2023024057A1 (zh) 2021-08-27 2021-08-27 跨域授权处理方法及跨域调用处理方法
CN202180002298.8A CN116034361A (zh) 2021-08-27 2021-08-27 跨域授权处理方法及跨域调用处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/114923 WO2023024057A1 (zh) 2021-08-27 2021-08-27 跨域授权处理方法及跨域调用处理方法

Publications (1)

Publication Number Publication Date
WO2023024057A1 true WO2023024057A1 (zh) 2023-03-02

Family

ID=85322395

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/114923 WO2023024057A1 (zh) 2021-08-27 2021-08-27 跨域授权处理方法及跨域调用处理方法

Country Status (3)

Country Link
US (1) US20240193249A1 (zh)
CN (1) CN116034361A (zh)
WO (1) WO2023024057A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116566805B (zh) * 2023-07-10 2023-09-26 中国人民解放军国防科技大学 一种面向体系容灾抗毁的节点跨域调度方法、装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101262474A (zh) * 2008-04-22 2008-09-10 武汉理工大学 一种基于跨域授权中介实现角色和组映射的跨域访问控制系统
US20100250653A1 (en) * 2009-01-29 2010-09-30 Brandon Hudgeons Method and system for providing cross-domain communication
CN105830477A (zh) * 2013-08-12 2016-08-03 哥莱菲特软件公司 集成操作系统的域管理
US20170331832A1 (en) * 2016-05-11 2017-11-16 Oracle International Corporation Identity cloud service authorization model
CN112580006A (zh) * 2020-12-24 2021-03-30 中国建设银行股份有限公司 一种多云系统的访问权限控制方法、装置及认证服务器

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101262474A (zh) * 2008-04-22 2008-09-10 武汉理工大学 一种基于跨域授权中介实现角色和组映射的跨域访问控制系统
US20100250653A1 (en) * 2009-01-29 2010-09-30 Brandon Hudgeons Method and system for providing cross-domain communication
CN105830477A (zh) * 2013-08-12 2016-08-03 哥莱菲特软件公司 集成操作系统的域管理
US20170331832A1 (en) * 2016-05-11 2017-11-16 Oracle International Corporation Identity cloud service authorization model
CN112580006A (zh) * 2020-12-24 2021-03-30 中国建设银行股份有限公司 一种多云系统的访问权限控制方法、装置及认证服务器

Also Published As

Publication number Publication date
US20240193249A1 (en) 2024-06-13
CN116034361A (zh) 2023-04-28

Similar Documents

Publication Publication Date Title
CN110679131B (zh) 多租户身份云服务的数据复制冲突检测和解决方案
CN112088373B (zh) 用于多租户身份云服务的声明性第三方身份提供者集成
CN109314704B (zh) 用于多租户身份和数据安全管理云服务的单点登录和单点注销功能
CN110557975B (zh) 用于多租户身份云服务的租户数据比较
CN110622484B (zh) 多租户身份云服务的本地写入
CN108701182B (zh) 多租户身份云服务的数据管理
CN107852417B (zh) 多租户身份和数据安全性管理云服务
CN108306877B (zh) 基于node js的用户身份信息的验证方法、装置和存储介质
CN112913208B (zh) 具有内部部署的认证集成和桥接器高可用性的多租户身份云服务
US9043886B2 (en) Relying party platform/framework for access management infrastructures
US10778603B2 (en) Systems and methods for controlling access to broker resources
US10812324B2 (en) Technologies for managing application configurations and associated credentials
CN110603802A (zh) 多租户身份云服务的跨区域信任
CN110521182B (zh) 用于协议级身份映射的方法和系统
EP4120109A1 (en) Cluster access method and apparatus, electronic device, and medium
CN112805699A (zh) 具有内部部署的认证集成的多租户身份云服务
US10742636B2 (en) OAuth2 SAML token service
US20200111487A1 (en) Voice capable api gateway
WO2023024057A1 (zh) 跨域授权处理方法及跨域调用处理方法
WO2020224241A1 (zh) 一种云通信方法及装置、用户设备、网络设备
JP2013182302A (ja) ネットワークシステム、認証連携装置、認証連携方法、及びプログラム
US11570182B1 (en) Compute-less authorization
CN108347471B (zh) 获取第三方用户信息的方法、装置及系统
US20230376628A1 (en) Privacy Manager for Connected TV and Over-the-Top Applications
CN113128200B (zh) 用于处理信息的方法和装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 17758126

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21954585

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 12.06.2024)