Reprint: Cross-domain method rollup

Web development often needs to face cross-domain issues, the root cause of cross-domain issues is browser security in the same-origin policy, for example, for http://www.a.com/1.html:

• The http://www.a.com/2.html is homologous;
• Https://www.a.com/2.html are different sources, because the agreement is different;
• Http://www.a.com:8080/2.html are different sources, because the ports are different;
• Http://sub.a.com/2.html are different sources because the host is different.

In the browser,<script>, , <iframe>, and <link> these tags are the ones that can load cross-domain (non-homologous) resources, and load in a way that is equivalent to a normal GET request, The only difference is that, for security reasons, the browser does not allow read and write operations to the loaded resources in this way, but only the capabilities that the tag itself should have (such as script execution, style application, and so on).

The most common cross-domain problem is Ajax cross-domain access, and by default, cross-domain URLs cannot be accessed through Ajax. Here I'm documenting the cross-domain approach I've learned:

1. Server-side proxy, there is nothing to say, the disadvantage is that by default, the service side that receives the AJAX request is unreachable to the client's IP and UA.

2. IFrame, using an IFRAME is actually the equivalent of opening a new Web page, the specific cross-domain method is roughly, domain A open the parent page nested a point to the domain B iframe, and then submit the data, after completion, B's server can:

• Returns a 302 redirect response, returning the result back to domain A;
• An IFRAME that points to a domain is nested inside this iframe.

Both end up with cross-domain invocation, which is functionally more powerful than the JSONP described below, because DOM operations and JavaScript calls between each other are fine after the cross-domain, but there are some limitations, such as the result to be passed as a URL parameter. This means that it is troublesome to divide and pass when the amount of data is large, and that the IFRAME itself brings the interaction of the parent page and the IFRAME itself to a security limit.

3. Using the script tag across domains is also common, and the script tag can be loaded with exotic JavaScript and executed by pre-programmed callback functions to interact with the parent page. It has a name called Jsonp cross-domain, and JSONP is a JSON with padding merchants. It's an unofficial protocol, obviously loading script, why is it related to JSON? This is the callback function, the use of it has a typical way, is through the JSON to pass the parameter, the JSON data is filled into the callback function, this is the meaning of Jsonp json+padding.

There are many JSONP services on the Internet to provide data, essentially cross-domain requests, and in the request URL to specify a good callback, such as Callback=result, then after acquiring the data, it will automatically call the result function, And this data is transmitted in JSON form, for example (search "Football"):

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

Using jquery to Invoke is written as:

123	$.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 only get requests can be used, and the problem of how to make JavaScript calls between two pages in different domains cannot be resolved.

4. Flash cross-domain:

It accesses the Crossdomain.xml file under the root directory of the target Web site to determine whether this cross-domain access is allowed, based on the contents of the file:

123	<cross-domain-policy>    <allow-access-fromdomain="xxx.xxx.com"/></cross-domain-policy>

5. IMG Tags can also be used, which is also a very common method, the function is weak, can only send a GET request, there is no callback, Google's click Count is determined by this.

6. Window. PostMessage, this is the HTML5 new addition to the cross-domain communication to consider the mechanism, only Firefox 3, Safari 4 and IE8 and later version support. The way you use it to send messages to other Windows is as follows:

1	otherWindow.postMessage(message, targetOrigin);

In the received window, you need to set an event handler function to receive the message sent:

12345

window.addEventListener("message", receiveMessage, false);functionreceiveMessage(event){    if(event.origin !== "http://example.org:8080")        return;}

Note that it is necessary to use the origin and source properties of the message to verify the identity of the sender, otherwise it will cause an XSS vulnerability.

7. Access Control

Some browsers support access-control-allow-origin such as the response header, such as:

1	header("Access-Control-Allow-Origin: http://www.a.com");

The Allow cross-domain access to www.a.com is specified.

8. Window.name

This is actually used as a means of hacker XSS, the essence is that when the window location changes, the page will reload, but interestingly, this window.name actually does not change, then you can use it to pass the value. With the IFRAME, change several times the IFrame window object, completed the practical cross-domain data transfer.

9. Document.domain

This approach applies to cross-domain communication between a.example.com and b.example.com because there is a common domain called example.com, as long as the document.domain is set to example.com, but if a.example1.co There is no way to communicate between M and b.example2.com.

Fragment identitier Messaging (FIM)

This method is very interesting, also need the IFRAME's cooperation. Fragment identitier is the URL of the pound (#) is often used for anchor location, this part of the change will not cause the page to refresh, the parent window can access the URL of the IFRAME, and the IFRAME can also casually access the URL of the parent window, Then the communication can be achieved by changing the fragmement identitier. The disadvantage is that changes in fragmement identitier produce unnecessary historical records, and there is a length limit; In addition, some browsers do not support Onhashchange events.

Cross Frame (CF)

This method is a variant of the FIM method described above, the nature of CF and FIM is actually introduced in my "GWT experience" article (just used to implement the history and fallback function), it will dynamically create an invisible iframe, pointing to the exotic, after processing, The fragment identitier in the URL of this iframe contains the processing results for the parent page to access, and the URL of the browser does not change.

COOKIE+P3P protocol

It is also an odd trick to use the feature of cross-domain access cookie under P3P protocol to realize cross-domain access. P3P is a recommended standard for privacy protection published by the Web, designed to provide privacy protection for Internet users who surf the internet. The path of the cookie is set to "/", that is, there is no domain limit, this time some browsers allow other URLs to read the page, and some do not allow, in this case, you need to set the P3P header on the head of the parent page response:

1	P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"

Reprint: Cross-domain method rollup