This article focuses on cross-domain knowledge.

Before we talk about cross-domain, the same-origin policy is a convention that almost all modern browsers follow. It is also a security policy that ensures that non-same-origin requests cannot be arbitrarily requested, thus ensuring the security of a website. Homology requires that the protocol, domain name, and port are all the same. If one of them is different, they are not homologous. Although the same-origin policy ensures security, there are times when non-same-origin access is needed, such as in a project where the front-end and back-end addresses are https://xwchris.me and https://api.xwchris.me, respectively. Cross-domain access between non-homologies requires CORS cross-domain approach. CORS stands for Cross Origin Resource Sharing, that is, cross-domain Resource Sharing.

CORS cross-domain correlation headers

Here are a few cross-domain related headers and a brief introduction.

  • Access-control-allow-headers (request Headers, response Headers, pre-request Headers)
  • Access-control-allow-methods (request headers, response headers, pre-requests)
  • Access-control-allow-origin (response header, pre-request/normal request) (cannot be * with cookies)
  • Access-control-allow-credentials (response headers, pre-requests/normal requests) (Set to true with cookies)
  • Access-control-max-age (response header, pre-request) (unit s)

Simple request CORS

A simple request must meet the following conditions:

  1. The request method must beGET,HEADandPOSTOne of them
  2. HTTP information cannot exceed the following fieldsAccept,Accept-Language,Content-Language,Last-Event-IDandContent-TypeandContent-TypeThe value ofapplication/x-www-form-urlencoded,multipart/form-dataandtext/plain.

When a browser sends a simple request, it automatically adds the Origin field in the request header to represent the source.

To support CORS Access, the server must add access-Control-allow-Origin to the response header. You can use * to indicate that all domains are allowed cross-domain Access.

CORS that are not simple requests

The biggest difference between a non-simple request and a simple request is that it has a preflight request. A normal request can be sent only after the request is verified.

Advance request

A pre-request is an OPTIONS request. The browser automatically adds access-Control-allow-headers and access-Control-allow-methods.

The response Headers returned by the server include access-Control-allow-headers, access-Control-allow-methods, and access-Control-Allow-Origin.

Access-control-allow-origin specifies the Origin header. Access-control-allow-origin specifies the Origin header. Access-control-allow-origin specifies the Origin header. Access-control-allow-origin specifies the Origin header. Chris, then the server just needs to add access-Control-allow-headers to the response header. Each response header can use the * wildcard character to indicate all.

Normal request

After the pre-request is complete, a normal request can be sent. The steps of a normal request are the same as those of a simple request, and the access-Control-Allow-Origin response header needs to be added.

Reduce the number of pre-requests

The number of pre-requests can be reduced by setting access-Control-max-aage, which needs to be included in the response header of the pre-request, specifying that the pre-request validation is valid within this time and does not need to be pre-requested every time. It is in seconds. For example, access-Control-max-age: 1728000 indicates that the validity period is 20 days.

A request carrying a Cookie

By default, cross-domain requests do not carry cookies. To carry cookies for cross-domain requests requires the support of both the requester and the receiver. To support carrying cookies, the request object xhr.withCredentials=true needs to be manually specified by the developer at request time. The server response header must contain access-Control-allow-credentials: true. For non-simple requests, this header is also required for pre-requests.

It is important to note that the value of all required response headers in this case cannot be * and should be specified explicitly if necessary.

Other cross-domain methods

In addition to CORS, we can also use JSONP technology for cross-domains, which is an old Hack. We all know that the Script tag can access scripts in any domain, so we can use this approach to cross domains, which requires the server to cooperate. For example 🌰 :

<script type="text/javascript">
	function getName(name) {
		console.log(name);
	}
</script>
<script src="http://api.xxx.com?callback=getName"></script>
Copy the code

After requesting the server, the server needs to retrieve the value of the callback field, and then convert the returned value into JSON and put it into getName. The final return value x looks something like this; GetName ({“name”: “Chris “}), so that getName can get the corresponding value.

JSONP can only do GET requests compared to CORS, but it is more compatible. However, most modern browsers support CORS requests and are safe to eat. Original address: Portal