Web development often requires facing cross-domain problems. The root cause of cross-domain problems is the same-original strategy in browser security. For example, for http://www.a.com/1.html:
1. http://www.a.com/2.html is homologous;
2. https://www.a.com/2.html is from different sources, because the protocol is different;
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 from different sources because the hosts are different.
In the browser, the tags <script>, <img>, <iframe> and <link> can load cross-domain (non-homologous) resources, and the loading method is actually equivalent to an ordinary GET request. The only difference is that for the sake of security, the browser does not allow read and write operations on the loaded resources in this way, but 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 the cross-domain access problem of Ajax. By default, cross-domain URLs cannot be accessed through Ajax. Here I record what I have learned about cross-domain methods:
1. Server-side proxy , there is nothing to say. The disadvantage is that by default, the server that receives Ajax requests cannot obtain the IP and UA of the client.
2. iframe , using iframe is actually equivalent to opening a new web page. The specific cross-domain method is roughly the parent page opened by domain A nests an iframe pointing to domain B, and then submits the data. After completion, B's server can:
●Return a 302 redirection response and point the result back to domain A;
●Nest an iframe pointing to the A domain inside this iframe.
Both of these finally implement cross-domain calls. This method is more functionally stronger than the JSONP introduced below, because after cross-domain completion, there is no problem with DOM operations and JavaScript calls between each other, but there are some restrictions, such as the result being passed in URL parameters, which means that when the result data is large, it needs to be passed in segmentation, which is very troublesome; there is another trouble that is caused by the iframe itself, and the interaction between the parent page and the iframe itself has security restrictions.
3. Use script tags to cross-domain , this method is also very common. script tags can load foreign JavaScript and execute them. The pre-set callback function can realize interaction with the parent page. It has a big name called JSONP Cross-domain, which is an abbreviation for JSON with Padding. It is an unofficial protocol, which is obviously loading script, so why is it related to JSON? It turns out that it is this callback function. There is a typical way to use it, which is to pass parameters through JSON, that is, fill the JSON data into the callback function. This is the meaning of JSONP's JSON+Padding.
There are many JSONP services on the Internet to provide data. In essence, they are cross-domain requests and specify callbacks in the request URL, such as callback=result. After obtaining this data, the result function will be automatically called and the data will be passed 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 and write it as:
The code copy 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 approach is that it can only use GET requests and 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:
The code copy is as follows:
<cross-domain-policy>
<allow-access-from domain="xxx.xxx.com" />
</cross-domain-policy>
5. The img tag can also be used , which is also a very common method. It has a weaker function and can only send a get request without any callbacks. This is how Google's click count is determined.
6. window.PostMessage, which is a newly added mechanism for cross-domain communication, is supported only by Firefox 3, Safari 4, IE8 and later versions. The call to use it to send messages to other windows is as follows:
The code copy is as follows:
otherWindow.postMessage(message, targetOrigin);
In the receiving window, an event handler needs to be set to receive the sent messages:
The code copy is as follows:
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event){
if (event.orgin !== "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 it will cause XSS vulnerabilities.
7. Access Control
Some browsers support response headers like Access-Control-Allow-Origin, such as:
The code copy is as follows:
header("Access-Control-Allow-Origin: http://www.a.com");
This specifies that cross-domain access to www.a.com is allowed.
8. window.name
This thing was actually used as a means to hack XSS. The essence is that when the window location changes, the page will be reloaded, but interestingly, the window.name does not change, so you can use it to pass the value. With the iframe, change the window object of the iframe several times, and practical cross-domain data transfer is completed.
9. document.domain
This method is suitable for cross-domain communication such as a.example.com and b.example.com, because the two have a common domain called example.com. Just set document.domain to example.com, but if you want to communicate 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 iframes. Fragment Identitier is the part that is often used for anchor positioning after the URL's pound mark (#). Changes in this part will not cause page refresh. The female window can access the iframe's URL at will, and the iframe can also access the URL of the female window. Then the communication can be achieved by changing the Fragmement Identitier. The disadvantage is that the changes in Fragmement Identitier will generate unnecessary history and have length restrictions; in addition, some browsers do not support the onhashchange event.
11. Cross Frame (CF)
This method is a variant of the above FIM method. The essence of CF and FIM is actually introduced in my article "GWT First Experience" (it is just used to implement history and backward functions). It will dynamically create an invisible iframe, 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, while the browser's URL has no changes.
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 recommendation standard released by W3C, aiming to provide privacy protection for Internet users who surf the Internet. Set the path of the cookie to "/", that is, there is no domain restriction. At this time, some browsers allow pages of other URLs to be read, while others do not. In this case, the P3P header needs to be set on the head of the parent page response:
The code copy is as follows:
P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"