What is cross-domain

Cross-domain: Pages belonging to different domains cannot access each other due to the same origin policy of the browser.

Development project in the background, and the first thing we need to make a local service run up, a page such as http://localhost:8000/scg/show, and then, when we need to conduct network interaction, often using relative domain name, such as/SCG/search. Json? PageNo =1, assuming the agent configuration for the project is as follows

So when requesting/SCG /search.json? PageNo = 1, proxy forwarded request is http://ottscg.alibaba.net/scg/search.json?pageNo=1, localhost to the contents of the request ottscg.alibaba.net, then the cross-domain.

CORS sends cookies across domains

When the browser sends a CORS request through a proxy, it adds an Origin field to the header information to indicate 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. 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, and knows that something is wrong, throwing an error that is caught by XMLHttpRequest’s onError callback.

If Origin is within the permitted domain name, the server will return a response with several additional header fields beginning with “Access-Control”. In order to send a cross-domain request with cookies, Access-control-allow-origin and access-Control-allow-credentials are the first things we need to care about:

Access-Control-Allow-Origin

This header is the one that must be returned when CORS is allowed, and its value is either the Origin field value at the time of the request, or an *, indicating acceptance of any domain name request.

Access-Control-Allow-Credentials

By default, browsers do not carry cookies for cross-domain requests, but because of their importance for things like authentication, CORS recommends using additional response header fields to allow cross-domain Cookie sending. This is an optional header that must be returned if a request with cookies is sent and is set to true to indicate that the server allows the client to send cookies. Access-control-allow-origin: access-Control-allow-origin: access-Control-allow-origin: access-Control-allow-origin: access-Control-allow-origin: access-Control-allow-origin: access-Control-allow-origin: access-Control-allow-origin

To sum up, the correct posture of CORS sending cookies is:

  • The client configures the credentials item for the fetch: credentials: ‘include’;
  • The responseHeader returned by the server carries the following two header fields 
    Access - Control - Allow - Origin: the Origin; Access-Control-Allow-Credentials :true
Copy the code

The include part tells Chrome that you want to send a CORS request to the server which sends along the cookies properly

How do I do this in Chrome

By understanding how CORS works, we know that a server that does not support CORS will return a normal HTTP response, but the browser will intercept the response because there is no ACEess-Control-related response header. By using the Chrome. WebRequest API, onHeadersReceived can be listened to, and every time the HTTP(S) response header is received, the required header fields can be added to make the browser think that these headers are returned by the server, so as to bypass the CORS restriction.

//Breaking the CORS Limitation
chrome.webRequest.onHeadersReceived.addListener(details=>window.onHeadersReceivedCallback(details), {
  urls: ['<all_urls>'[]},"blocking"."responseHeaders"]);
Copy the code

Simple and complex requests

Setting just two fields, access-Control-Allow-Origin and Access-Control-Allow-Crendentials, does not cover all scenarios. For example, when we use Antd’s Upload component to Upload an image, Chrome will report the following error:

Preflight

Access-control-allow-origin response header fields can Allow cross-domain AJAX, but for non-simple requests, CORS cross-domain preflight (an OPTIONS request, indicating that the request is for a query) is performed first.

A simple request

An HTTP request with a simple method and a simple header. In particular,

  • Simple methods include GET, HEAD, and POST.
  • Simple heads include: Accept, Accept – Language, the Content – Language, And content-Type headers with values of Application/X-www-form-urlencoded, multipart/form-data, text/plain. For non-simple requests the browser will first send an OPTIONS request (called preflight)

Access-Control-Request-Headers

Access-control-request-headers is a header field used in a Preflight Request to identify which Headers will be included in the actual Request. For example, if the value of the ACCESS-Control-request-HEADERS field in the following Request is x-requested-with, the server is told that the actual Request will carry this custom Request header field. The server then decides whether the actual request is allowed, and if so, the server should include this field in the corresponding Access-Control-allow-HEADERS response header. Otherwise, even returning 200 preFlight will fail.

Looking at the source code of Antd Upload component, we can see that x-requesd-with request header is added when uploading pictures, thus triggering non-simple request, and Option inquiry will be made first in CORS

In summary, in order to handle CORS that are not simple requests, in addition to access-Control-Allow-Origin and Access-Control-allow-Crendentials, we also need to add the following configuration to Header hijacking

Access-Control-Allow-Methods:"*",
Access-Control-Allow-Headers:"Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"
Copy the code