First of all, if you want to implement cross-domain, you need to understand what cross-domain is. So cross-domain is based on the same origin policy of the browser, making requests to different sources. Okay

The same origin policy is an important security policy that restricts how an Origin document or the scripts it loads can interact with resources from another source. It can help block malicious documents and reduce the number of vectors that can be attacked.

The two cross-domain approaches that are currently popular beyond JSONP, which only allows cross-domain GET requests, are

1 cors

CORS (Cross-Origin Resource Sharing) is a system that consists of a series of transmitted HTTP headers that determine whether the browser prevents front-end JavaScript code from getting a response to a cross-domain request.

That is, the server is running cross-domain requests, because the cORS identifier on the server is usually used for cross-domain operations on the server

2 proxy Because scripts cannot request resources from different sources, simply place scripts and resource servers on the same source.

Cors related methods

By default, the same-origin security policy prevents cross-domain access to resources. But CORS gives Web servers the option to allow cross-domain requests to access their resources.

So since it is the server to choose open resources can be accessed. Therefore, the basic principle is to add an identifier indicating accessible resources to the server’s response.

1 Back-end Response Interception Add the CORS flag

For example, each major Node framework generally has its own cross-domain plug-in, such as egg-cors, koa-cors and so on. Of course, you can also write your own plug-in to intercept response.

'use strict';
module.exports = () = > {
  return async (ctx, next) => {
    // Process the OPTIONS request
    if (ctx.method === 'OPTIONS') {
      ctx.body = ' ';
    }
    ctx.set('Access-Control-Allow-Origin'.The '*');
    // Sets the allowed HTTP request methods
    ctx.set('Access-Control-Allow-Methods'.'OPTIONS, GET, PUT, POST, DELETE');
    // The field is required. It is also a comma-separated string indicating all header information fields supported by the server.
    ctx.set('Access-Control-Allow-Headers'.The '*');
    await next();
  };
};


  // add your middleware config here
  config.middleware = [ 'httpError'.'cors' ];

Copy the code

2 Add the CORS identifier to the Response through the third-party server

Take nginx as an example, using nginx proxy resource server. Then nginx intercepts the response to add the identifier, and then requests the resource through the proxy server. Nginx will automatically add the CORS identifier to the resource request

nginx.conf

 server {
        listen       9000;
        server_name  localhost;
		location / {		
			proxy_pass  http://localhost:8010; # proxy resource server
			add_header 'Access-Control-Allow-Origin'$http_origin; * add_header is not supported for requests with cookies'Access-Control-Allow-Credentials' 'true'; # fortrueCookie add_header can be included'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; Allow the request method add_header'Access-Control-Allow-Headers'$http_access_control_request_headers; * add_header * add_header'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
	
		if ($request_method = 'OPTIONS') {
			add_header 'Access-Control-Max-Age' 1728000; # OPTIONS Specifies the validity period of the request, during which another precheck request add_header will not be issued'Content-Type' 'text/plain; charset=utf-8';
			add_header 'Content-Length' 0;
			return 204;                  # 200}}}Copy the code

The agent

In the development environment, our page resources are usually mounted on the development server, so we just need to configure the proxy on the development server, such as

Proxy Settings for webpack-dev-server

You can also use it directly

express + http-proxy-middleware

The purpose is to use the page server to make requests to the resource server instead of the script resource, because there is no same-origin policy between the servers to achieve cross-domain purposes.

Another method is to configure cross-domain third-party services. That is, the script server and resource server are configured on the third-party server to identify access through different identifiers of the same domain name. This makes them look like resources under the same domain name to the browser. Nignx, for example

	server {
        listen       9001; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; {proxy_pass HTTP://localhost:3000;} # interface service location ^~/apis/ {
		rewrite ^/apis/$/ $(. *)1 break;
		proxy_pass http://localhost:8010;}}Copy the code