Principles of nine cross-domain implementation methods (full version)

[Original article from 51CTO.com] Cross-domain requests are often encountered in front-end and back-end data interaction. What is cross-domain and what are the cross-domain methods? This article will discuss this.

Please check the GitHub blog for the complete source code of this article.

1. What is cross-domain?

1. What is the same-origin policy and what are its restrictions?

The same-origin policy is a convention. It is the most core and basic security function of the browser. If the same-origin policy is missing, the browser is very vulnerable to attacks such as XSS and CSFR. The so-called same-origin refers to the same "protocol + domain name + port". Even if two different domain names point to the same IP address, they are not of the same origin.

The same-origin policy restricts the following:

• Storage contents such as Cookies, LocalStorage, IndexedDB, etc.
• DOM Nodes
• AJAX request could not be sent

However, there are three tags that allow cross-domain loading of resources:

 < img src = XXX >
 < link href = XXX >
 < script src = XXX >

2. Common cross-domain scenarios

When any of the protocols, subdomains, primary domains, and port numbers are different, they are considered different domains. When different domains request resources from each other, it is considered "cross-domain". Common cross-domain scenarios are shown in the following figure:

Two points in particular:

• First: If it is a cross-domain problem caused by the protocol and port, the "front desk" is powerless.
• Second: In the cross-domain issue, it is only identified by the "URL header" and not by whether the IP address corresponding to the domain name is the same. The "URL header" can be understood as "the protocol, domain name and port must match".

You may have a question here: if the request is cross-domain, is the request sent out?

Cross-domain does not mean that the request cannot be sent. The request can be sent, the server can receive the request and return the result normally, but the result is blocked by the browser. You may wonder why Ajax can't initiate a cross-domain request when a form can initiate a cross-domain request? Because in the final analysis, cross-domain is to prevent users from reading content under another domain name. Ajax can get the response, and the browser thinks this is unsafe, so it intercepts the response. However, the form will not get new content, so a cross-domain request can be initiated. It also shows that cross-domain cannot completely prevent CSRF, because the request is sent after all.

2. Cross-domain solutions

1. JSONP

(1) JSONP principle

By taking advantage of the fact that the <script> tag has no cross-domain restriction, a web page can obtain JSON data dynamically generated from other sources. JSONP requests must be supported by the other party's server.

(2) Comparison between JSONP and AJAX

JSONP and AJAX are the same, both are ways for the client to send requests to the server and get data from the server. However, AJAX belongs to the same-origin policy, while JSONP belongs to the non-same-origin policy (cross-domain request)

(3) Advantages and disadvantages of JSONP

The advantage of JSONP is that it is simple and compatible, and can be used to solve the cross-domain data access problem of mainstream browsers. The disadvantage is that it only supports the get method, which is limited and unsafe and may be subject to XSS attacks.

(4) JSONP implementation process

• Declare a callback function with its function name (such as show) as the parameter value to be passed to the server that requests data across domains. The function parameter is the target data to be obtained (data returned by the server).
• Create a <script> tag, assign the cross-domain API data interface address to the script's src, and pass the function name to the server in this address (you can pass the parameter through a question mark: ?callback=show).
• After receiving the request, the server needs to perform special processing: concatenate the passed function name and the data it needs to give you into a string. For example, the passed function name is show, and the data it prepares is show('I don't love you').
• Finally, the server returns the prepared data to the client through the HTTP protocol, and the client then calls the callback function (show) declared before to operate on the returned data.

During development, you may encounter multiple JSONP request callback function names that are the same. In this case, you need to encapsulate a JSONP function yourself.

 // index.html
 function jsonp({ url, params, callback }) {
  return new Promise((resolve, reject) = > {
    let script = document .createElement('script')
    window[callback] = function(data) {
 resolve(data)
      document.body.removeChild(script)
 }
 params = { ...params, callback } // wd = b & callback = show
 let arrs = []
 for (let key in params) {
      arrs.push(`${key}=${params[key]}`)
 }
 script.src = `${url}?${arrs.join('&')}`
    document.body.appendChild(script)
 })
 }
 jsonp({
  url: 'http://localhost:3000/say',
 params: { wd: 'Iloveyou' },
 callback: 'show'
 }).then( data = > {
 console.log(data)
 })

The above code is equivalent to requesting data from the address http://localhost:3000/say?wd=Iloveyou&callback=show, and then the background returns show('I don't love you'), and finally runs the show() function to print out 'I don't love you'

 // server.js
 let express = require ('express')
 let app = express ()
 app.get('/say', function(req, res) {
  let { wd, callback } = req.query
 console.log(wd) // Iloveyou
  console.log(callback) // show
 res.end(`${callback}('I don't love you')`)
 })
 app.listen(3000)

(5) jQuery's JSONP form

JSONP is all GET and asynchronous requests. There are no other request methods or synchronous requests, and jQuery will clear the cache for JSONP requests by default.

 $.ajax({
 url:"http://crossdomain.com/jsonServerResponse",
 dataType:"jsonp",
 type:"get", // can be omitted
 jsonpCallback:"show", //- > Customize the function name passed to the server instead of using jQuery to automatically generate it, can be omitted
 jsonp:"callback", //- > pass the function name as the parameter callback, which can be omitted
 success:function (data){
 console.log(data);}
 });

2. CORS

CORS requires support from both the browser and the backend. IE 8 and 9 need to use XDomainRequest to implement it.

The browser will automatically perform CORS communication. The key to achieving CORS communication is the backend. As long as the backend implements CORS, cross-domain communication is achieved.

CORS can be enabled by setting Access-Control-Allow-Origin on the server. This attribute indicates which domain names can access resources. If a wildcard is set, all websites can access resources.

Although setting CORS has nothing to do with the front end, if the cross-domain problem is solved in this way, two situations will occur when sending requests: simple requests and complex requests.

(1) Simple request

As long as the following two conditions are met at the same time, it is a simple request

Condition 1: Use one of the following methods:

• GET
• HEAD
• POST

Condition 2: The value of Content-Type is limited to one of the following three:

• text/plain
• multipart/form-data
• application/x-www-form-urlencoded

Any XMLHttpRequestUpload objects in the request do not have any event listeners registered; XMLHttpRequestUpload objects can be accessed using the XMLHttpRequest.upload property.

(2) Complex requests

Requests that do not meet the above conditions are definitely complex requests. A CORS request for a complex request will add an HTTP query request before formal communication, called a "pre-check" request. This request is an option method, and is used to determine whether the server allows cross-domain requests.

When we use PUT to request the backend, it is a complex request and the backend needs to be configured as follows:

 // Which method is allowed to access me
 res.setHeader('Access-Control-Allow-Methods', 'PUT')
 // Pre-check survival time
 res.setHeader('Access-Control-Max-Age', 6)
 // No processing is done on the OPTIONS request
 if ( req.method === 'OPTIONS') {
 res.end()
 }
 // Define the content returned by the background
 app.put('/getData', function(req, res) {
 console.log(req.headers)
 res.end('I don't love you')
 })

Next, let's look at an example of a complete complex request and introduce the fields related to the CORS request.

 // index.html
 let xhr = new XMLHttpRequest()
 document.cookie = 'name=xiamen' // Cookies cannot cross domains
 xhr.withCredentials = true // Front-end settings whether to include cookies
 xhr.open('PUT', 'http://localhost:4000/getData', true)
 xhr.setRequestHeader('name', 'xiamen')
 xhr.onreadystatechange = function () {
  if ( xhr. readyState === 4) {
    if ((xhr.status > = 200 && xhr.status < 300 ) || xhr.status === 304) {
      console.log(xhr.response)
 //Get the response header, the backend needs to set Access-Control-Expose-Headers
      console.log(xhr.getResponseHeader('name'))
 }
 }
 }
 xhr.send()

 //server1.js
 let express = require ('express');
 let app = express ();
 app.use(express.static(__dirname));
 app.listen(3000);

 //server2.js
 let express = require ('express')
 let app = express ()
 let whiteList = ['http://localhost:3000'] //Set up the whitelist
 app.use(function(req, res, next) {
  let origin = req .headers.origin
  if (whitList.includes(origin)) {
 // Set which source can access me
    res.setHeader('Access-Control-Allow-Origin', origin)
 // Which header is allowed to access me
    res.setHeader('Access-Control-Allow-Headers', 'name')
 // Which method is allowed to access me
    res.setHeader('Access-Control-Allow-Methods', 'PUT')
 // Allow cookies
    res.setHeader('Access-Control-Allow-Credentials', true)
 // Pre-check survival time
    res.setHeader('Access-Control-Max-Age', 6)
 // Allowed headers to be returned
    res.setHeader('Access-Control-Expose-Headers', 'name')
    if ( req.method === 'OPTIONS') {
 res.end() // No processing is done on the OPTIONS request
 }
 }
 next()
 })
 app.put('/getData', function(req, res) {
 console.log(req.headers)
 res.setHeader('name', 'jw') //Return a response header, which needs to be set in the background
 res.end('I don't love you')
 })
 app.get('/getData', function(req, res) {
 console.log(req.headers)
 res.end('I don't love you')
 })
 app.use(express.static(__dirname))
 app.listen(4000)

The above code makes a cross-domain request from http://localhost:3000/index.html to http://localhost:4000/. As we said above, the backend is the key to implementing CORS communication.

3. postMessage

postMessage is an API in HTML5 XMLHttpRequest Level 2 and is one of the few window attributes that can be operated across domains. It can be used to solve the following problems:

• Data transfer between the page and the new window it opens
• Message passing between multiple windows
• Page and nested iframe messaging
• Cross-domain data transmission in the above three scenarios

The postMessage() method allows scripts from different sources to communicate asynchronously in a limited manner, which can achieve cross-text document, multi-window, and cross-domain message delivery.

• message: data to be sent to other windows.
• targetOrigin: Use the origin property of the window to specify which windows can receive message events. Its value can be a string "*" (indicating no restrictions) or a URI. When sending a message, if any of the target window's protocol, host address, or port does not match the value provided by targetOrigin, the message will not be sent; only if the three completely match, the message will be sent.
• transfer (optional): is a list of Transferable objects that are passed along with the message. The ownership of these objects will be transferred to the recipient of the message, and the sender will no longer retain ownership.

Let's look at an example: The http://localhost:3000/a.html page sends "I love you" to http://localhost:4000/b.html, and the latter sends back "I don't love you".

 // a.html
 < iframe src = "http://localhost:4000/b.html" frameborder = "0" id = "frame" onload = "load()" > </ iframe > //Wait for it to load and then trigger an event
 //Embedded in http://localhost:3000/a.html
 < script >
 function load() {
        let frame = document .getElementById('frame')
 frame.contentWindow.postMessage('I love you', 'http://localhost:4000') //Send data
 window.onmessage = function (e) { //Accept the returned data
 console.log(e.data) //I don't love you
 }
 }
 </ script >

 // b.html
 window.onmessage = function (e) {
 console.log(e.data) //I love you
 e.source.postMessage('I don't love you', e.origin)
 }

4. websocket

Websocket is a persistent protocol of HTML5, which realizes full-duplex communication between browser and server, and is also a cross-domain solution. WebSocket and HTTP are both application layer protocols, both based on TCP protocol. However, WebSocket is a two-way communication protocol. After the connection is established, the server and client of WebSocket can actively send or receive data to each other. At the same time, WebSocket needs to use HTTP protocol when establishing a connection. After the connection is established, the two-way communication between client and server has nothing to do with HTTP.

The native WebSocket API is not very convenient to use, so we use Socket.io, which encapsulates the webSocket interface well, provides a simpler and more flexible interface, and also provides backward compatibility for browsers that do not support webSocket.

Let's take a look at an example: the local file socket.html sends and receives data to localhost:3000.

 //socket.html
 < script >
    let socket = new WebSocket('ws://localhost:3000');
 socket.onopen = function () {
 socket.send('I love you'); //Send data to the server
 }
 socket.onmessage = function (e) {
 console.log(e.data); //Receive data returned by the server
 }
 </ script >

 // server.js
 let express = require ('express');
 let app = express ();
 let WebSocket = require ('ws'); //Remember to install ws
 let wss = new WebSocket.Server({port:3000});
 wss.on('connection',function(ws) {
  ws.on('message', function (data) {
 console.log(data);
 ws.send('I don't love you')
 });
 })

5. Node middleware proxy (two cross-domain)

Implementation principle: The same-origin policy is a standard that browsers need to follow, but if a server requests another server, it does not need to follow the same-origin policy. The proxy server needs to do the following steps:

• Accept client requests.
• Forwards the request to the server.
• Get the server response data.
• Forward the response to the client.

Let's take a look at an example: the local file index.html requests data from the target server http://localhost:4000 through the proxy server http://localhost:3000.

 // index.html(http://127.0.0.1:5500)
 < script src = "https://cdn.bootcss.com/jquery/3.3.1/jquery.min.js" > </ script >
 < script >
 $.ajax({
        url: 'http://localhost:3000',
 type: 'post',
        data: { name: 'xiamen', password: '123456' },
        contentType: 'application/json; charset = utf -8',
        success: function(result) {
          console.log(result) // {"title":"fontend","password":"123456"}
 },
        error: function(msg) {
 console.log(msg)
 }
 })
 </ script >

 // server1.js proxy server (http://localhost:3000)
 const http = require ('http')
 // Step 1: Accept client request
 const server = http .createServer((request, response) = > {
 // The proxy server interacts directly with the browser and needs to set the CORS header field
 response.writeHead(200, {
    'Access-Control-Allow-Origin': '*',
    'Access-Control-Allow-Methods': '*',
    'Access-Control-Allow-Headers': 'Content-Type'
 })
 // Step 2: Forward the request to the server
 const proxyRequest = http
 .request(
 {
 host: '127.0.0.1',
 port: 4000,
 url: '/',
        method: request.method,
        headers: request.headers
 },
 serverResponse = > {
 // Step 3: Receive a response from the server
 var body = ''
        serverResponse.on('data', chunk = > {
 body += chunk
 })
        serverResponse.on('end', () = > {
          console.log('The data is ' + body)
 // Step 4: Forward the response result to the browser
 response.end(body)
 })
 }
 )
 .end()
 })
 server.listen(3000, () = > {
  console.log('The proxyServer is running at http://localhost:3000')
 })

 // server2.js(http://localhost:4000)
 const http = require ('http')
 const data = { title: 'fontend', password: '123456' }
 const server = http .createServer((request, response) = > {
 if ( request.url === '/' ) {
    response.end(JSON.stringify(data))
 }
 })
 server.listen(4000, () = > {
  console.log('The server is running at http://localhost:4000')
 })

The above code goes through two cross-domains. It is worth noting that the browser sends a request to the proxy server and also follows the same-origin policy. Finally, {"title":"fontend","password":"123456"} is printed in the index.html file.

6. nginx reverse proxy

The implementation principle is similar to that of the Node middleware proxy. You need to build a transit nginx server to forward requests.

Using nginx reverse proxy to achieve cross-domain is the simplest way to achieve cross-domain. You only need to modify the nginx configuration to solve the cross-domain problem. It supports all browsers and sessions, does not require any code modification, and does not affect server performance.

Implementation idea: Configure a proxy server (domain name is the same as domain1, but different port) through nginx as a jump server, and use reverse proxy to access the domain2 interface. You can also modify the domain information in the cookie to facilitate writing the current domain cookie and achieve cross-domain login.

Download nginx first, and then modify the nginx.conf in the nginx directory as follows:

 // proxy server
 server {
 listen 81;
    server_name www.domain1.com;
 location / {
 proxy_pass http://www.domain2.com:8080; #Reverse proxy
 proxy_cookie_domain www.domain2.com www.domain1.com; #Modify the domain name in the cookie
        index index.html index.htm;
 # When using webpack-dev-server and other middleware proxy interfaces to access nignx, there is no browser involved, so there is no homology restriction, and the following cross-domain configuration can be disabled
 add_header Access-Control-Allow-Origin http://www.domain1.com; #When the front end only crosses the domain without cookies, it can be *
        add_header Access-Control-Allow-Credentials true;
 }
 }

Finally, start nginx through the command line nginx -s reload:

 // index.html
 var xhr = new XMLHttpRequest();
 // Front-end switch: whether the browser reads and writes cookies
 xhr.withCredentials = true ;
 // Access the proxy server in nginx
 xhr.open('get', 'http://www.domain1.com:81/? user = admin ', true);
 xhr.send();

 // server.js
 var http = require ('http');
 var server = http .createServer();
 var qs = require ('querystring');
 server.on('request', function(req, res) {
    var params = qs .parse(req.url.substring(2));
 // Write cookies to the front desk
 res.writeHead(200, {
 'Set-Cookie': ' l = a123456 ; Path = /; Domain = www .domain2.com; HttpOnly' // HttpOnly: scripts cannot read
 });
    res.write(JSON.stringify(params));
 res.end();
 });
 server.listen('8080');
 console.log('Server is running at port 8080...');

7. window.name + iframe

The uniqueness of the window.name property: the name value persists after loading different pages (even different domain names), and can support very long name values ​​(2MB).

a.html and b.html are in the same domain, both are http://localhost:3000; and c.html is http://localhost:4000.

 // a.html(http://localhost:3000/b.html)
 < iframe src = "http://localhost:4000/c.html" frameborder = "0" onload = "load()" id = "iframe" > </ iframe >
 < script >
 let first = true
 // The onload event will be triggered twice, the first time loading the cross-domain page and saving the data in window.name
 function load() {
 if(first){
 // After the first onload (cross-domain page) succeeds, switch to the same-domain proxy page
       let iframe = document .getElementById('iframe');
 iframe.src = 'http://localhost:3000/b.html' ;
 first = false ;
 }else{
 // After the second onload (b.html page in the same domain) succeeds, read the data in window.name in the same domain
       console.log(iframe.contentWindow.name);
 }
 }
 </ script >

b.html is an intermediate proxy page, which is in the same domain as a.html and has empty content.

 // c.html(http://localhost:4000/c.html)
 < script >
 window.name = 'I don't love you'
 </ script >

Summary: By transferring the src attribute of the iframe from the external domain to the local domain, the cross-domain data is transferred from the external domain to the local domain by the window.name of the iframe. This cleverly bypasses the cross-domain access restrictions of the browser, but at the same time it is a safe operation.

8. location.hash + iframe

Implementation principle: a.html wants to communicate with c.html across domains through the intermediate page b.html. The three pages use the location.hash of iframe to pass values ​​between different domains, and directly access js to communicate between the same domains.

Specific implementation steps: At first, a.html passes a hash value to c.html, and then c.html passes the hash value to b.html after receiving the hash value, and finally b.html puts the result into the hash value of a.html. Similarly, a.html and b.html are in the same domain, both are http://localhost:3000; while c.html is http://localhost:4000.

 // a.html
 < iframe src = "http://localhost:4000/c.html#iloveyou" > </ iframe >
 < script >
 window.onhashchange = function () { //Detect changes in hash
     console.log(location.hash);
 }
 </ script >

 // b.html
 < script >
 window.parent.parent.location.hash = location.hash
 //b.html puts the result into the hash value of a.html, b.html can access the a.html page through parent.parent
 </ script >

 // c.html
 console.log(location.hash);
  let iframe = document .createElement('iframe');
 iframe.src = 'http://localhost:3000/b.html#idontloveyou' ;
  document.body.appendChild(iframe);

9. document.domain + iframe

This method can only be used when the second-level domain names are the same, for example, a.test.com and b.test.com are suitable for this method. You only need to add document.domain = 'test.com' to the page to indicate that the second-level domain names are the same to achieve cross-domain.

Implementation principle: Both pages use js to force document.domain to be the basic primary domain, thus achieving the same domain.

Let's look at an example: page a.zf1.cn:3000/a.html gets the value of a in page b.zf1.cn:3000/b.html.

 // a.html
 < body >
 helloa
 < iframe src = "http://b.zf1.cn:3000/b.html" frameborder = "0" onload = "load()" id = "frame" > </ iframe >
 < script >
 document.domain = 'zf1.cn'
 function load() {
      console.log(frame.contentWindow.a);
 }
 </ script >
 </ body >

 // b.html
 < body >
 hellob
 < script >
 document.domain = 'zf1.cn'
 var a = 100 ;
 </ script >
 </ body >

Conclusion

• CORS supports all types of HTTP requests and is the fundamental solution for cross-domain HTTP requests.
• JSONP only supports GET requests. The advantage of JSONP is that it supports old browsers and can request data from websites that do not support CORS.
• Whether it is Node middleware proxy or nginx reverse proxy, the main purpose is to not restrict the server through the same-origin policy.
• In daily work, the more commonly used cross-domain solutions are cors and nginx reverse proxy

Author: Langlixingzhou, a certified author of MOOC.com, a front-end enthusiast, determined to develop into a full-stack engineer, has been engaged in front-end for more than a year. His current technology stack includes Vue, ES6, and less. He is happy to share. In the past year, he has written fifty or sixty original technical articles, which have received many praises!

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]