First, why cross-domain

Cross-domain behavior is reserved for browser-based same-origin policies.

A same-origin policy is a policy that restricts urls from different sources from accessing cookiestorage, DOM, and Making Ajax requests in the browser.

Same-origin means that the protocol, domain name, and port number of two urls are the same.

Thanks to the browser, real world development often involves communication between domains, so there are a number of cross-domain approaches derived from both artificial and W3C standards.

2. Cross-domain approach

The cross-domain methods I know from before to now are:

1. Document. domain, which is limited to sharing cookies and DOM. Applies to two web pages with the same level 1 domain name but different level 2 domain name. Public cookies can be accessed by setting the same document.domain (level 1 domain) in both web pages.

2. Window.postmessage (), which implements cross-domain communication between parent and child IFrames, but can only transmit strings.

3. Jsonp, which addresses Ajax across domains, but only for GET requests.

Because browsers are not restricted by the same origin policy when requesting static resources, HTTP requests are encapsulated as requests for static resources. The way to do this is to dynamically insert one into the web page

4.Nginx reverse proxy, ajax cross domain solution.

5.Cors communication to solve Ajax cross-domain. Details: www.ruanyifeng.com/blog/2016/0…

Cors is a W3C standard, which is mainly the cooperation between browser and server. It is supported by IE10 or above. The whole CORS communication process is completed automatically by the browser, and there is no need for the front-end side to do anything. As soon as the browser discovers that an Ajax request crosses domains, it automatically adds additional headers, and sometimes an additional request. The server side needs to do some processing for cORS requests.

Browsers classify CORS requests as simple and non-simple.

Simple requests require that two conditions be met:

1) Is one of the three methods of get, head and post.

2) HTTP request headers are not included

  • Access
  • Access-Language
  • Content-Language
  • Last-Event-ID
  • The content-type is limited to application/WWW – form – urlencoded, multipart/form – data, text/plain.

For simple requests, the browser adds an Origin field in the request header. The Origin field indicates the source (protocol + domain name + port) from which the request is sent. Based on this value, the server decides whether to approve the request or not.

1) If Origin does not specify a licensed source, the server will return a normal HTTP response. The browser realizes that the response header does not contain the Access-Control-Allow-Origin field (more on that below), and it throws an error that is caught by XMLHttpRequest’s onError callback. Note that this error cannot be identified by the status code, because the status code for the HTTP response might be 200.

If Origin specifies a domain name within the license, the server will return a response containing several header fields:

  • Access-control-allow-origin: api.bob.com // The domain that allows cross-domain Access
  • Access-control-allow-credentials: true // Indicates whether cookies are allowed. If this parameter is set to true, with withCredentials set to true in the request header can take effect
  • Access-control-expose-headers: FooBar // Optional
  • Content-Type: text/html; charset=utf-8

For non-simple requests, an HTTP query request is added before formal communication, called a “preflight” request.

The browser asks the server if the domain name of the current web page is on the server’s license list, and what HTTP verb and header fields can be used. The browser issues a formal XMLHttpRequest request only if it receives a positive response; otherwise, an error is reported.

The request method for the “precheck” request is OPTIONS, indicating that the request is being queried. In the precheck request header, there are three key fields:

  • Origin:Indicates which source the request came from
  • ** Access-Control-request-method: ** Must list which HTTP methods will be used in the Request
  • ** CCess-Control-request-HEADERS: ** This field is a comma-separated string that specifies the additional header field that the browser CORS Request will send

After receiving the precheck Request, the server checks the Origin, access-Control-request-method, and access-Control-request-headers fields and confirms that cross-source requests are allowed, it can respond.

If the server denies the precheck request, it will return a normal HTTP response, but without any CORS related header fields. At this point, the browser decides that the server did not approve the precheck request, and therefore fires an error that is caught by the ONError callback function of the XMLHttpRequest object.

Once the server passes the “precheck” request, every subsequent normal BROWSER CORS request will have the same Origin header field as a simple request. The server also responds with an Access-Control-Allow-Origin header field.