Cross-domain Cors method (jsonp,document.domain,document.name) and IFRAME properties

The JS cross-domain refers to the data transfer or communication between different domains via JS, such as using AJAX to request data from a different domain, or by JS to get the frames (IFRAME) of the different domains in the page. As long as the protocol, domain name, and port are any different, are considered to be different domains.

The following table shows the results of relative http://store.company.com/dir/page.html homology detection:

To resolve cross-domain issues, we can use the following methods:

1. Cross-domain "solve Ajax across domains" through JSONP

In JS, it is not possible for us to request data from different domains directly with XMLHttpRequest. However, it is possible to introduce JS script files on different domains on the page, and JSONP is using this feature to achieve this.

For example, there is a a.html page, the code inside it needs to use Ajax to obtain a different domain JSON data, assuming that the JSON data address is http://example.com/data.php, then the code in a.html can do this:

We see that the address that gets the data is followed by a callback parameter, which, by convention, is the name of the parameter, but you use the other as well. Of course, if the JSONP address page that gets the data is not in your own control, it has to be done in the prescribed format of the party that provided the data.

Because it is introduced as a JS file, so the http://example.com/data.php return must be an executable JS file, so the PHP code of this page may be this:

The result of the final page output is:

So the JS file obtained by http://example.com/data.php?callback=dosomething is the dosomething function we defined earlier, and its parameters are the JSON data we need, So we get the data we need across the domain.

So the principle of jsonp is very clear, through the script tag to introduce a JS file, this JS file loading success will execute our function specified in the URL parameters, and we will need to pass the JSON data as parameters. So JSONP is the server side of the page to do the corresponding match.

Knowing the principle of Jsonp cross-domain, we can use JS to dynamically generate script tags for cross-domain operations, instead of deliberately manually writing those script tags. If your page uses jquery, it is easy to jsonp with the method it encapsulates.

The principle is the same, except that we do not need to manually insert the script tag and define the rollback function. jquery automatically generates a global function to replace the question mark in callback=, which is then automatically destroyed after the data is obtained, in effect, as a temporary proxy function. The $.getjson method automatically determines whether a cross-domain, non-cross-domain, calls a normal Ajax method, or cross-domain, invokes the JSONP callback function in the form of an asynchronously loaded JS file.

extended reading : Ajax cross-domain: JSONP principle Analysis

2. "Resolve IFRAME cross-domain" across subdomains by modifying document.domain

Browsers have a single origin policy, one of the limitations of which is that the first method we say cannot be used in Ajax to request documents from different sources. The second limitation is that there is no interaction between the frames of different domains in the browser. It is important to note that different frameworks (parent-child or peer) are able to get to each other's window objects, but the pain is that you can't use the properties and methods of the retrieved window object (the PostMessage method in HTML5 is an exception, Some browsers, such as IE6, can also use a few properties such as top, parent, etc., in short, you can only get to a Window object that is almost useless. For example, there is a page, its address is http://www.example.com/a.html, in this page there is an IFRAME, its src is http://example.com/b.html, it is clear that This page is different from the IFRAME frame inside it, so we can't get the contents of the IFRAME by writing the JS code in the page:

This time, document.domain can come in handy, we just put http://www.example.com/a.html and http://example.com/ B.html the two pages of the document.domain are set to the same domain name can be. Note, however, that the document.domain setting is limited, and we can only set Document.domain to the parent domain of itself or higher, and the primary domain must be the same. For example: The document.domain of a document in a.b.example.com can be set to either a.b.example.com, b.example.com, or example.com, but cannot be set to C.a.b.example.com, because this is a subdomain of the current domain and cannot be set to baidu.com because the primary domain is already different.

Set document.domain in page http://www.example.com/a.html:

In the page http://example.com/b.html also set Document.domain, and this is also necessary, although this document's domain is example.com, However, you must also display the value of the setting Document.domain:

This allows us to access various properties and objects in the IFRAME via JS.

However, if you want to request the http://example.com/b.html page directly via Ajax in the Http://www.example.com/a.html page, Even if you set the same document.domain is still not working, so the method of modifying Document.domain only applies to the interaction between the frameworks of different subdomains. If you want to use AJAX methods to interact with different subdomains of the page, in addition to using the Jsonp method, you can also use a hidden iframe to do a proxy. The idea is to have this iframe load a page in the same domain as the target page you want to get data from Ajax, so the page in this IFRAME can use Ajax to get the data you want, Then it is through the method we have just said to modify document.domain, so that we can fully control the IFRAME through JS, so that we can let the IFRAME to send AJAX requests, and then receive the data we can get.

3. Use Window.name to cross-domain "resolve iframe cross-domain"

The Window object has a Name property that has a feature: that is, within the lifetime of a window, All the pages loaded in the window are shared by a window.name, each page has read and write permissions to Window.name, Window.name is persisted on all pages loaded by a window and will not be reset due to the loading of the new page.

For example: There is a page a.html, it has such code:

Then look at the code for the b.html page:

A.html page loading 3 seconds, jump to the b.html page, the result is:

We see that on the b.html page, we successfully obtained the value of the previous page a.html to Window.name set. If the window.name is not modified by all the loaded pages after that, then all of the window.name values obtained by these pages are the values a.html the page settings. Of course, if necessary, any one of these pages can modify the value of Window.name. Note that the value of the window.name can only be in the form of a string, the maximum size of the string can allow 2M or even a larger capacity, depending on the browser, but generally enough.

In the above example, the pages a.html and b.html are in the same domain, but even if a.html and b.html are in different domains, the same conclusion applies, and this is the principle of cross-domain using Window.name.

Here's a look at how to get data across domains through Window.name. or an example.

For example, there is a www.example.com/a.html page, you need to a.html the page JS to get another page located in different fields www.php-note.com/data.html data.

The code in the Data.html page is very simple, which is to set the current window.name to the data value that the A.html page wants to get. The code in data.html:

So in the A.html page, how do we load the data.html page into it? Obviously we can't load the data.html page directly on the a.html page by changing the window.location, because we want to get the data in data.html even if the a.html page doesn't jump. The answer is to use a hidden iframe in the a.html page to act as a man-in-the-middle character, to get data.html data from the IFRAME, and then a.html to get the data that the IFRAME gets.

An IFRAME that acts as a middleman wants to get to Data.html's data through Window.name, just set the SRC to www.php-note.com/data.html. Then a.html want to get the data obtained by the IFRAME, that is, want to get the window.name of the IFRAME value, you must also set the IFRAME src to the same domain as the a.html page, otherwise, according to the same homologous strategy, a.html is not accessible to the IFRAME of the Window.name property. This is the entire cross-domain process.

Look at the code for the a.html page:

The above code is just the simplest principle of the demo code, you can use the JS package above the process, such as the dynamic creation of the IFRAME, dynamic registration of various events and so on, of course, for security, after obtaining data, you can also destroy the IFRAME as a proxy. There are a lot of similar out-of-the-box code on the Internet, which is interesting to look for.

Cross-domain through Window.name, that's it.

4. Use the newly introduced Window.postmessage method in HTML5 to transfer data across domains "resolve iframe cross-domain" "can not consider this solution"

The Window.postmessage (Message,targetorigin) method is a newly introduced feature of HTML5 that can be used to send messages to other window objects, regardless of whether the window object belongs to the same origin or different source, currently ie8+, Browsers such as FireFox, Chrome, and opera already support the Window.postmessage method.

The Window object that invokes the PostMessage method refers to the window object that receives the message, the first parameter of the method is the message to be sent, and the type can only be a string The second parameter, Targetorigin, is used to qualify the domain of the Window object that receives the message, and if you do not want to qualify the domain, you can use the wildcard character *.

The window object that needs to receive the message, but receives the message by listening to its own message event, which is stored in the event object's Data property.

As mentioned above, sending a message to another window object is actually a case where a page has several frames, because each frame has a window object. In discussing the second approach, we have said that the frames of different domains can be obtained from each other's window object, and you can also use the Window.postmessage method. Let's look at a simple example with two pages

The results we get when we run a page:

We see the B page successfully received the message.

The use of PostMessage to transfer data across domains is more intuitive and convenient, but the disadvantage is IE6, IE7, IE8 does not support, so do not have to depend on the actual need to decide.

Conclusion:

In addition to the above several methods, there are flash, on the server set proxy page, such as cross-domain mode, here do not introduce.

The above four methods, according to the actual situation of the project to choose the application, the individual think Window.name method is not complex, but also compatible to almost all browsers, this is a very good cross-domain approach.

Reprint: http://www.cnblogs.com/52php/p/5677699.html

Cross-domain Cors method (jsonp,document.domain,document.name) and IFRAME properties