Summary of JavaScript cross-domain methods_javascript skills

Doing web development often requires you to face cross-domain problems. The root cause of cross-domain problems is the same-origin policy in browser security. For example, for http://www.a.com/1.html:

1.http://www.a.com/2.html is of the same origin; 2. https://www.a.com/2.html is from a different source because of different protocols; 3. http://www.a.com:8080/2.html is from different sources because the ports are different; 4. http://sub.a.com/2.html is of different origins because the hosts are different.

In the browser, the tags , , and can load cross-domain (non-original) resources, and the loading method is actually It is equivalent to an ordinary GET request. The only difference is that for security reasons, the browser does not allow reading and writing operations on the loaded resources in this way, and can only use the capabilities that the tag itself should have (such as script execution, style application, etc.).

The most common cross-domain problem is Ajax cross-domain access. By default, cross-domain URLs cannot be accessed through Ajax. Here I record the cross-domain methods I learned:

1. Server-side proxy , there is nothing to say about this. The disadvantage is that by default, the server that receives the Ajax request cannot obtain the client's IP and UA.

2. iframe , using iframe is actually equivalent to opening a new web page. The specific cross-domain method is roughly that the parent page opened by domain A nests an iframe pointing to domain B, and then submits Data, after completion, B’s server can:

●Return a 302 redirect response and redirect the result back to domain A; ●An iframe pointing to domain A is nested inside this iframe.

Both of them finally realized cross-domain calls. This method is more functional than JSONP introduced below, because after the cross-domain is completed, there is no problem with DOM operations and JavaScript calls between each other, but There are also some restrictions. For example, the results must be passed in URL parameters, which means that when the result data is large, it needs to be split and passed, which is very troublesome. Another trouble is caused by the iframe itself, the interaction between the parent page and the iframe itself. There are inherent security limitations.

3. Use script tags to cross domains . This method is also very common. The script tag can load foreign JavaScript and execute it, and interact with the parent page through a preset callback function. . It has a big name, called JSONP cross-domain. JSONP is the abbreviation of JSON with Padding. It is an unofficial protocol. It is obviously loading script. Why is it related to JSON? It turns out that this is the callback function, and a typical way to use it is to pass parameters through JSON, that is, fill the JSON data into the callback function. This is the meaning of JSON Padding of JSONP.

There are many JSONP services on the Internet to provide data, which is essentially a cross-domain request. If the callback is specified in the request URL, such as callback=result, then after obtaining the data, the result function will be automatically called. , and pass the data in in the form of JSON, for example (search for "football"):

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=result

Use JQuery to call it as:

Copy code The code is as follows: $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=?",function(data){ //... }); In general, the limitation of JSONP's cross-domain method is that it can only use GET requests, and it cannot solve the problem of how to make JavaScript calls between two pages in different domains.

4. Flash cross-domain:

It will access the crossdomain.xml file under the root directory of the target website and determine whether to allow this cross-domain access based on the content in the file:

Copy code The code is as follows: 5. The img tag can also use , which is also a very common method. The function is a little weaker. It can only send a get request and there is no callback. This is how Google’s click count is determined. .

6. window.PostMessage, this is a new mechanism added to HTML5 for cross-domain communication. It is only supported by Firefox 3, Safari 4, IE8 and later versions. The calling method to use it to send messages to other windows is as follows:

Copy code The code is as follows: otherWindow.postMessage(message, targetOrigin); In the receiving window, you need to set up an event processing function to receive the sent message: Copy code The code is as follows: window.addEventListener("message", receiveMessage, false); function receiveMessage(event){ If (event.origin !== "http://example.org:8080") return; } Note that the origin and source attributes of the message must be used to verify the identity of the sender, otherwise an XSS vulnerability will occur. 7. Access Control

Some browsers support response headers such as Access-Control-Allow-Origin, such as:

Copy code The code is as follows: header("Access-Control-Allow-Origin: http://www.a.com"); It specifies that cross-domain access to www.a.com is allowed. 8. window.name

This thing has actually been used as a means of hacker XSS before. Its essence is that when the location of the window changes, the page will be reloaded, but what is interesting is that the window.name does not change, so you can use It comes to pass value. Cooperate with iframe and change the iframe's window object several times to complete practical cross-domain data transfer.

9. document.domain

This method is suitable for cross-domain communication between a.example.com and b.example.com, because they have a common domain called example.com. Just set document.domain to example.com. , but if there is communication between a.example1.com and b.example2.com, it has no choice.

10. Fragment Identitier Messaging (FIM)

This method is very interesting and requires the cooperation of iframe. Fragment Identitier is the part after the pound sign (#) of the URL that is often used for anchor positioning. Changes in this part will not cause the page to refresh. The parent window can access the URL of the iframe at will, and the iframe can also access the URL of the parent window at will. , then communication between the two can be achieved by changing the Fragmement Identitier. The disadvantage is that the change of Fragmement Identitier will generate unnecessary historical records, and there is also a length limit; in addition, some browsers do not support the onhashchange event.

11. Cross Frame (CF)

This method is a variant of the above-mentioned FIM method. The essence of CF and FIM is actually introduced in my "First Experience with GWT" article (it is just used to implement the history and back functions). An invisible iframe will be dynamically created, pointing to a foreign domain. After processing, the Fragment Identitier in the URL of this iframe contains the processing results for the parent page to access, and the browser's URL will not change.

12. Cookie P3P Protocol

Using the characteristics of cross-domain access cookies under the P3P protocol to achieve cross-domain access is also a strange trick. P3P is a privacy protection recommended standard published by W3C, aiming to provide privacy protection for Internet users surfing the Internet. Set the cookie path to "/", that is, there is no domain restriction. At this time, some browsers allow pages with other URLs to be read, while others do not. In this case, you need to respond on the parent page. Set the P3P header on the header:

Copy code The code is as follows: P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"