Troubleshoot cross-domain issues

What is a homologous policy ?

The same-origin strategy is one of the most basic and mandatory security policies for browsers. The existence of the same-origin policy restricts the "source" from a script to operate only the DOM of the "Same origin" page, and the "cross-origin" operation from page B will be rejected. The so-called "homologous", must require the corresponding URI in the following 3 aspects are the same.

1. Host name (Domain/sub-domain or IP address)
2. Port number
3. Network protocol (Scheme, two URIs using the "http" and "https" protocols respectively are considered non-homologous

For a JavaScript script, its "source" is independent of the address it stores, depending on which page the script is loaded in. For example, in a page, the <script> tag refers to two JavaScript scripts from different places, all of which are identical to the current page.

<src= "Http://www.a.com/scripts/a.js"></script  >
<src= "Http://www.b.me/scripts/b.js"></Script  >

In addition to the <script> tag other tags with src attributes (such as ), they all have the ability to load resources across domains, so the same-origin policy does not restrict them.

The same-origin policy mainly restricts AJAX requests implemented through XMLHttpRequest, and if the request is a "heterogeneous" address, the browser will not be allowed to read the returned content.

Jsonp Implementing cross-domain resource sharing

JavaScript script loaded via the SRC attribute of the <script> tag

 <  script  type  = "Text/javascript"   src  = "Http://localhost:8080/api/test?callback=test"  ></ script  >  <  script  type  = "Text/javascript"  >  function   Test (ARG) {}  </ script  >  

JSONP is a programming technique, not an official protocol, that takes advantage of a script loaded with the SRC tag of <script> that is not constrained by the same-origin policy. Because the HTML tag with the SRC attribute loads the target resource in a http-get manner, JSONP only applies to http-get requests.

We can use jquery to send JSONP Ajax cross-domain requests, call the $.ajax method, and set the datatype parameter to "JSONP"

<type= "Text/javascript">    $ (function  ()    {        $.ajax ({             "jsonp"        });    }); </ Script >

CORS (cross-origin Resource sharing)

Web-based resource sharing involves two basic roles, namely, the provider and the consumer of resources. That is, a Web page that is displayed in the browser gets the resources it needs by invoking the Web API, the resource provider for the Web API itself, and the JavaScript program that calls the Web API by sending AJAX requests to the consumer of the resource.

Cors is designed to define a specification that enables a browser to determine whether the resource should be distributed to consumers for further processing when it receives resources from the provider. Cros uses the explicit authorization of the resource provider to determine whether the target resource should be shared with the consumer. The browser needs to be authorized by the provider before distributing the resources it provides to the consumer.

If the browser itself provides support for Cros, the request sent by it carries a header named "Origin" indicating the site where the requested page resides.

After a resource acquisition request is received by the provider, it can determine to whom the resource provided needs to be shared, based on the header. The authorization of the resource provider is hosted by a response header called "Access-control-allow-origin", whose header value represents the site being authorized. In general, if the provider of the resource endorses the site carried by the "Origin" header of the current request, it will use that site as the value of the "Access-control-allow-origin" response header.

When the browser receives a response containing a resource, it extracts the value of this "Access-control-allow-origin" response header. If this value is "*" or contains a source list containing the source of the previous request (that is, the "origin" header value of the request), it means that the resource's consumers have access to the provider to obtain and manipulate the resource, so the browser allows the JavaScript program to manipulate the acquired resources. If this response header does not exist or its value is "null", the client-side JavaScript program will be denied operations against the resource.

Simple (HTTP) method ", simple (Request) header" and "Custom Request Header" (Author requests Header/custom request header)

The Cors specification treats the three HTTP methods of and post as simple HTTP Methods, while the request header is Accept, Accept-language, Content-language and header Content-type with the following three media types are called "Simple request Headers"

1. application/x-www-form-urlencoded
2. Multipart/form-data
3. Text/plain

Headers added by the JavaScript program themselves (such as the setRequestHeader method that calls XMLHttpRequest can add arbitrary headers for the generated AJAX request) are called "Custom Headers".

Simple request/non-simple cross-domain resource request

The Cors specification divides cross-domain resource requests that serve the following criteria into simple requests: The request takes a simple HTTP method, and its custom request header is empty or all custom request headers are simple request headers.

For simple cross-domain resource requests, the browser takes two steps (authorization and resource acquisition) into one. If the process for the request involves a change in resources, there is a problem. According to the Cors specification, browsers should use a mechanism called "preflight" to complete non-trivial cross-domain resource requests.

The so-called preflight mechanism means that the browser sends a preflight request before sending a real cross-domain resource request. The preflight request is a request that takes the Http-options method, which is a request that does not contain a principal, and the header associated with the user credential is also rejected. Some of the secondary authorization information based on a real resource request is included in the corresponding header of this preflight request. In addition to representing the "Origin" header of the site where the request page is located, the following is a two typical request header.

1. Access-control-request-method: The HTTP method used for True cross-domain resource requests.
2. Access-control-request-headers: A list of custom headers that are carried by real cross-domain resource requests.

After receiving a preflight request, the resource's provider verifies the authorization based on the relevant header it provides, including determining whether the requesting site is trustworthy, and whether the request takes the HTTP method and the custom header is allowed. If the preflight request does not pass authorization verification, the resource provider typically returns a response with a status of "Reuqest". Instead, a response is returned with a status of "OK", and the authorization information is included in the response header. In addition to the "Access-control-allow-origin" header described above, the response of the preflight request also has the following 3 typical headers.

1. Access-control-allow-methods: Cross-domain resource request allows a list of HTTP methods to be used.
2. Access-control-allow-headers: A list of custom headers that are allowed to be carried by cross-domain resource requests.
3. Access-control-max-age: The time that the browser can cache the response results.

After the browser receives the preflight response, it determines whether the actual cross-domain resource request for subsequent sends is accepted, based on the response header, including the HTTP method and the custom request header (using the response header) for the server-side allowed site. Access-control-allow-methods "and" Access-control-allow-headers "). The specific test logic is as follows

1. The source site represented by the requested "Origin" header must exist in the list of sites identified by the "Access-control-allow-origin" response header.
2. The response header "Access-control-allow-methods" does not exist, or the "Access-control-request-method" header of the preflight request represents the request method within its list.
3. The header name of the "Access-control-request-headers" header store for the preflight request is within the list of headers represented by the response header "Access-control-allow-headers".

The browser sends a true cross-domain resource request only if it is determined that the server is bound to accept it. The results of the preflight response will be cached by the browser, and the cached results will be verified by the browser user during the time set in the "Access-control-max-age" header, so no preflight requests will be sent during this period.

User credentials

By default, Ajax requests sent with Xmlhttpreuqest do not carry sensitive information about user credentials, and the types of user credentials here include cookies, Http-authentication header and client-side certificate (TLS/SSL with support for client certificates). If you need user credentials to attach to an AJAX request, you need to set the Withcredentials property of Xmlhttpreuqest to True.

Cors specification, the server uses the response header "Access-control-allow-credentials" to indicate whether it supports user credentials.

The JavaScript program sends a cross-domain resource request with a Withcredentials property of true Xmlhttpreuqest, but the browser does not have a response header with a value of "true" in the response Access-control-allow-credentials ", it will be rejected by the browser for the operation to get the resource.

PS: This article refers to the abstract "ASP. NET Web API 2 Framework Revelation" book

Troubleshoot cross-domain issues