Front-end cross-domain methodology

preface

In the spirit of learning and summarizing the attitude of writing the technical output, there are any mistakes and problems, please point out. For more technical output, check out my Github blog.

Sorted out some front-end learning resources, hoping to help people in need, address: learning resources summary.

Cross domain

Cross-domain means that resources with different protocols, host names, and port numbers attempt to communicate with each other. However, due to the restriction of the same origin policy of the browser, the inter-domain communication fails.

The most common actual scenario is that resources in other domains of the third party will be requested during project development. For example, when map API is used, the white list needs to be set when the key is set so that map API can be used normally.

When AJAX is used to request data resources of a third party in different domains, HTTP requests cannot be successfully sent if cross-domain problems are not handled, and the browser will issue an error warning.

The same-origin policy

MDN explains: The same origin policy restricts how documents or scripts loaded from the same source can interact with resources from another source. This is an important security mechanism for isolating potentially malicious files.

The purpose of the same origin policy of the browser is to prevent malicious attacks such as XSS and CSRF.

There are three interaction modes for the same origin policy:

Cross-domain writes are generally allowed, such as linking, redirecting, and so on.
It is generally possible to nest resources across domains, such as IMG, script tags, and so on.
Cross-domain read operations are generally not allowed.

Cross-domain scenario

Only the protocols, domain names and port numbers of resources are the same source.

The following is a cross-domain description of homology and between different sources.

URL	instructions	Whether to allow communication
www.demo.com/a.html www.demo.com/b.html www.demo.com/c.html	The same domain name	allow
www.demo.com/news/a.html www.demo.com/center/b.ht… www.demo.com/server/c.ht…	Different folders under the same domain name	allow
www.demo.com/a.html www.demo.com:80/b.html	Different port numbers	Don’t allow
www.demo.com/a.html www.demo.com/b.html	Different protocols	Don’t allow
www.demo.com/a.html www.test.com/b.html	Different domain name	Don’t allow
www.demo.com/a.html test.demo.com/b.html	The primary domain is the same, but the subdomain is different	Don’t allow

Cross-domain solutions

1. JSONP

Because the browser’s same-origin policy allows cross-domain resources such as script tags to be nested, resources of script tags are not restricted by the same-origin policy.

JSONP’s solution is to make cross-domain requests through script tags.

The front end sets up the callback function as a parameter to carry with the request URL.
After receiving the request, the back end returns the name of the callback function and the required data.
After the back end responds and returns data, the returned data is passed into the callback function and executed.

<! -- using script tags natively --><script>
    function jsonpCallback(data) {
        alert('Got the data. Open the console.');
        console.log(data);
    }
</script>
<script src="Http://127.0.0.1:3000? callback=jsonpCallback"></script>
Copy the code

You can also use AJAX GET requests to make cross-domain requests (axiOS GET cross-domain requests are the same).

<! -- AJAX GET request --><script>
    function jsonpCallback(data) {
        alert('Got the data. Open the console.');
        console.log(data);
    }
    $.ajax({
        type: 'GET'.// It must be a GET request
        url: 'http://127.0.0.1:3000'.dataType: 'jsonp'.// Set it to jSONp type
        jsonpCallback: 'jsonpCallback' // Set the callback function
    })
</script>
Copy the code

The advantages and disadvantages:

Compatibility is good, and earlier versions of IE also support this approach.
Only HTTP requests in GET mode are supported.
Only HTTP requests such as data communication between the front and back ends cannot solve the problem of data interaction and communication between pages in different domains.

2. CORS

CORS cross-domain resource sharing allows cross-domain communication after related Settings are performed on the server.

If the CORS cross-domain field is not set on the server, the server rejects the request and prompts an error warning.

The access-Control-allow-Origin field is set on the server. The value can be a domain name or an ‘*’ wildcard. After the field is set, the cross-domain request is allowed.

<script> $. Ajax ({type: 'post', url: 'http://127.0.0.1:3000', success: function(res) {alert(' get data, open console '); console.log(res); } }) </script>Copy the code

How do servers set cross-domain fields? The backend language Settings are inconsistent across domains. For details, refer to the API of the backend language.

Set the Node end

res.writeHead(200, {
    'Access-Control-Allow-Origin': The '*'
});

// Or use a framework like Express
res.header("Access-Control-Allow-Origin"."*");
Copy the code

For details on CORS, refer to this note, CORS cross-domain resource sharing.

3. Server Proxy

The way of proxy request through the server is also a solution to the browser cross domain problem. The same origin policy is a security policy for browsers, and the server is not restricted by the same origin policy. Therefore, cross-domain problems do not exist. The specific steps are as follows:

The front-end normally requests the interface provided by the server. For example, request interface: http://localhost:3000.
Through the server set up the proxy to send requests, requests to the data and then the required data back to the front end. For example, set the proxy request interface to cnodejs.org/api/v1/topi… The server agent requests the data back and returns the data http://localhost:3000 interface to the front end.

// The server proxy requests the code
// The server simply proxies the interface data through a normal HTTP request
// You can also use the proxy module to proxy, as for how to use the proxy module, to be studied and perfected
var url = 'https://cnodejs.org/api/v1/topics';        
https.get(url, (resp) => {
    let data = "";
    resp.on('data', chunk => {
        data += chunk;
    });
    resp.on('end', () => {
        res.writeHead(200, {
            'Access-Control-Allow-Origin': The '*'.'Content-Type': 'application/json; charset=utf-8'
        });
        res.end(data);
    });
})
Copy the code

4. location.hash + iframe

The implementation of location.hash + iframe cross-domain communication looks like this:

Pages A in different domains communicate with pages B, embed the IFrame in page A into page B, and add a hash value to the SRC of the IFrame.
After page B receives the hash value, it determines that page A is trying to communicate with itself and then passes the data to the hash value of page A by modifying the value of parent. Location.
However, since child pages are not allowed to directly modify the parent page’s hash value under IE and Chrmoe, a proxy page is required to pass data through c page, which is in the same domain as PAGE A.
Similarly, embed the IFrame into the C page in the B page, and the data to be transmitted will be transmitted to the C page through the hash value of the SRC link of the IFrame. Since page A and page C are in the same domain, You can modify the hash value of page A on page C or invoke the global function on page A.

The general process is:

A Page code

<script> var iframe = document.createElement('iframe'); iframe.style.display = 'none'; iframe.src = "http://localhost:8081/b.html#data"; document.body.appendChild(iframe); function checkHash() { try { var data = location.hash ? location.hash.substring(1) : ''; Console. log(' Obtained data is: ', data); }catch(e) {}} window.addEventListener('hashchange', function(e) {console.log(' listen for hash changes: ', location.hash.substring(1)); }) </script>Copy the code

B Page code

<script>
     switch(location.hash) {
         case '#data':
         callback();
         break;
     }
    function callback() {
        var data = "testHash"
        try {
            parent.location.hash = data;
        }catch(e) {
            var ifrproxy = document.createElement('iframe');
            ifrproxy.style.display = 'none';
            ifrproxy.src = 'http://localhost:8080/c.html#' + data;
            document.body.appendChild(ifrproxy);
        }
    }
 </script>  
Copy the code

C page code

<script>
    // Change the hash value of page A
    parent.parent.location.hash = self.location.hash.substring(1);
    // Call the global function of page A
    parent.parent.checkHash();
</script>
Copy the code

The advantages and disadvantages:

There is a limited amount of data that hash passes.
The data is directly exposed in the URL.

5. document.domain + iframe

This solution is limited to cross-domain resource solutions with the same primary domain and different sub-domains.

Actual application scenarios:

The previous project development, often encountered such cross-domain problems, roughly similar to the development of new products in the product page, before the official launch, are generally uploaded to the internal test environment, such as the domain name of the test environment is test.admin.com/xxx/xxx, and the project… For example, consumer-test.admin.com/xxx/xxx, the product page is deployed online separately and nested into the project via iframe. During internal testing, the product page test environment and the project test environment have the same primary domain but different sub-domains, and the global public resources defined in the project need to be used in the product page. Due to cross-domain problems, these public resources cannot be obtained.

The cross-domain solution to this scenario is to utilize document.domain Settings. Cross-domain can be achieved by setting document.domain to the same domain in the product page and project, and the nested product page can access the common resources of the parent page. One thing to note is that document.domain Settings are limited to their own or higher parent fields, and the primary fields must be the same.

Project page

<iframe src="test.admin.com/xxx/xxx"></iframe>
<script>
    document.domain = 'admin.com';
</script>
Copy the code

Product page

<script>
    // Public resources defined in the project page are available
    document.domain = 'admin.com';
</script>
Copy the code

6. window.name + iframe

Window.name refers to the name of the current browser window. By default, it is an empty string. Each window’s window.name is independent. The nested iframe page also has its own window object, which is a child of top Window and also has the window.name attribute.

The unique thing about window.name is that when you set the value of window.name on a page, you set the name of the window, and then load other pages (even pages of different domains) in that window, the value of window.name remains (if it is not reset, the value will not change). And the window.name value supports large storage (2MB).

For example, open the console on a random page and set the name of the current window.

window.name = 'test-name';
Copy the code

After setting, you can jump to other pages in this window

window.location = 'https://www.baidu.com';
Copy the code

The page jumps to baidu home page, but the value of window.name is still the same as the value set before, because the page is jumped in a window, and the window name will not be changed.

The cross-domain solution is as follows.

http://localhost:8080/a.html and http://localhost:8081/b.html cross-domain communication, a page by nested iframe page b, b in the page setup window. The value of the name, is due to different domains, Page A cannot directly access the window.name value set on page B, and an intermediate page in the same domain as page A is required to act as a proxy for the communication between page A and page B.

a.html

<script> var data = null; var state = 0; var iframe = document.createElement('iframe'); iframe.src = "http://localhost:8081/b.html"; iframe.style.display = 'none'; document.body.appendChild(iframe); // set the value of c. HTML as window.name. // set the value of C. HTML as window.name. A.h HTML can pass the iframe. ContentWindow. Name get b.h windoa in HTML. The name of the value of the iframe. Onload = function () {if (state = = = 0) { iframe.src = "http://localhost:8080/c.html"; state = 1; }else if(state === 1) { data = iframe.contentWindow.name; Console. log(' Received data :', data); } } </script>Copy the code

b.html

<script>
    window.name = 'This is the data that's passed.';
</script>
Copy the code

Intermediate proxy pages, just need to keep to a page with domain, for example: http://localhost:8080/c.html.

7. window.postMessage

PostMessage is a new feature in HTML5 for cross-domain communication between pages.

The postMessage method takes two necessary arguments:

Message: data to be passed.
TargetOrigin: The target window domain name for data transfer. The value can be a specific domain name or the ‘*’ wildcard.