The following table gives the results of homologous detection relative to http://store.company.com/dir/page.html:
To solve cross-domain problems, we can use the following methods:
1. Cross-domain through jsonp
In js, it is not possible to directly request data on different domains using XMLHttpRequest. However, it is OK to introduce js script files on different domains on the page, and jsonp uses this feature to achieve it.
For example, there is a.html page, and the code in it needs to use ajax to obtain json data on a different domain. Assuming that the json data address is http://example.com/data.php, then the code in a.html That's it:
We see that there is a callback parameter after the address of the data acquisition. According to convention, this parameter name is used, but the same is true for you to use other ones. Of course, if the jsonp address page for obtaining data is not controlled by you, you must operate according to the specified format of the party that provides the data.
Because it is introduced as a js file, the return of http://example.com/data.php must be an executable js file, so the php code of this page may look like this:
The final result of that page output is:
So the js file obtained through http://example.com/data.php?callback=dosomething is the dosomething function we defined before, and its parameters are the json data we need, so we get the cross-domain we need data.
In this way, the principle of jsonp is very clear. A js file is introduced through the script tag. After the js file is loaded successfully, the function we specified in the url parameter will be executed, and the json data we need will be passed in as parameters. Therefore, jsonp requires the server-side page to cooperate accordingly.
After knowing the principle of cross-domain of jsonp, we can use js to dynamically generate script tags for cross-domain operations, without deliberately writing script tags manually. If your page uses jquery, then the encapsulation method can be used to perform jsonp operations very conveniently.
The principle is the same, except that we do not need to manually insert script tags and define the function back. jquery will automatically generate a global function to replace the question mark in callback=?, and then it will automatically destroy the data after obtaining it. In fact, it plays the role of a temporary agent function. The $.getJSON method will automatically determine whether it is cross-domain. If it is not cross-domain, it will call the ordinary ajax method; if it is cross-domain, it will call the jsonp callback function in the form of asynchronous loading of js files.
2. Cross subdomain by modifying document.domain
Browsers have a homologous policy, and one of its limitations is that in the first method we said that documents from different sources cannot be requested through the ajax method. Its second limitation is that the JS interaction cannot be performed between frameworks of different domains in the browser. One thing to note is that different frameworks (father and son or peer generation) can get each other's window objects, but the pain is that you cannot use the properties and methods of the obtained window objects (postMessage method in html5 It is an exception. Some browsers such as ie6 can also use a few attributes such as top and parent). In short, you can only get an almost useless window object. For example, there is a page whose address is http://www.example.com/a.html . There is an iframe in this page, and its src is http://example.com/b.html. Obviously , this page has different domains from the iframe framework inside it, so we cannot get things in the iframe by writing js code in the page:
At this time, document.domain can come in handy. We just need to use document.domain on both pages: http://www.example.com/a.html and http://example.com/b.html Just set it to the same domain name. But it should be noted that the setting of document.domain is limited. We can only set document.domain to its own or higher parent domain, and the main domain must be the same. For example: the document.domain of a document in abexample.com can be set to any of abexample.com, b.example.com, and example.com, but it cannot be set to cabexample.com, because this is a child of the current domain Domain, you cannot set it to baidu.com, because the main domain is no longer the same.
Set document.domain in the page http://www.example.com/a.html:
Document.domain is also set in the page http://example.com/b.html, and this is also necessary. Although the domain in this document is example.com, the value of document.domain must be displayed:
In this way, we can access various properties and objects in the iframe through js.
However, if you want to directly request the http://example.com/b.html page through ajax in the http://www.example.com/a.html page, even if you set the same document.domain, it still won't work. , so the method of modifying document.domain is only suitable for interactions between frameworks of different subdomains. If you want to interact with pages of different subdomains through the ajax method, in addition to using the jsonp method, you can also use a hidden iframe to act as a proxy. The principle is to let this iframe load a page with the same domain as the target page you want to obtain data through ajax, so the page in this iframe can use ajax to obtain the data you want normally, and then through us I just mentioned that the method of modifying document.domain allows us to fully control this iframe through js, so that we can let the iframe send ajax request, and we can also obtain the received data.
3. Use window.name to cross-domain
The window object has a name attribute, which has a feature: that is, during the life cycle of a window, all pages loaded by the window share a window.name, and each page has a window.name for window.name. Read and write permissions, window.name persists in all pages loaded by a window, and will not be reset due to the loading of new pages.
For example: There is a page a.html, which contains the following code:
Let's take a look at the code of the b.html page:
3 seconds after the a.html page is loaded, it jumps to the b.html page, and the result is:
We see that the value set by its previous page a.html to window.name was successfully obtained on the b.html page. If all the loaded pages have not modified window.name afterwards, the value of window.name obtained by all these pages is the value set by the a.html page. Of course, if necessary, any of the pages can modify the value of window.name. Note that the value of window.name can only be in the form of a string. The maximum size of this string can allow a capacity of about 2M or even larger, depending on different browsers, but it is generally enough.
In the above example, the pages a.html and b.html we used are in the same domain, but even if a.html and b.html are in different domains, the above conclusion is also applicable, which is exactly the same. The principle of cross-domain using window.name.
Let’s take a look at how to obtain data across domains through window.name. Let’s give an example.
For example, there is a www.example.com/a.html page, and you need to use js in the a.html page to obtain the data in another page located on a different domain www.cnblogs.com/data.html.
The code in the data.html page is very simple, which is to set the data value that the a.html page wants to get for the current window.name. Code in data.html:
So in the a.html page, how do we load the data.html page? Obviously, we cannot directly load the data.html page by changing window.location in the a.html page, because we want to get the data in data.html even if the a.html page does not jump. The answer is to use a hidden iframe in the a.html page to act as an intermediary, and the iframe gets the data of data.html, and then a.html gets the data obtained by the iframe.
If an iframe acting as a middleman wants to obtain the data set through window.name of data.html, you only need to set the src of this iframe to www.cnblogs.com/data.html. Then a.html wants to get the data obtained by the iframe, that is, to get the value of the iframe's window.name, you must set the src of this iframe to the same domain as the a.html page, otherwise according to the previous In the same origin strategy, a.html cannot access the window.name property in the iframe. This is the entire cross-domain process.
Look at the code of the a.html page:
The above code is just the simplest principle demonstration code. You can encapsulate the above process using js, such as dynamically creating iframes, dynamically registering various events, etc. Of course, for security, after obtaining the data, it can also be destroyed as a proxy. iframe. There are also many similar ready-made codes on the Internet. If you are interested, you can find them.
Cross-domain through window.name, that's it.
4. Use the newly introduced window.postMessage method in HTML5 to transfer data across domains
window.postMessage(message,targetOrigin) method is a newly introduced feature of html5. You can use it to send messages to other window objects. Regardless of whether this window object belongs to the same source or different source, currently IE8+, FireFox, Chrome, Opera, etc. All the machines already support the window.postMessage method.
The window object that calls the postMessage method refers to the window object that is to receive 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 define the message that is received. If you do not want to limit the domain, you can use the wildcard character *.
The window object that needs to receive messages can be obtained by listening to its own message event, and the message content is stored in the data attribute of the event object.
The above-mentioned sending messages to other window objects actually refers to the situation where a page has several frames, because each frame has a window object. When discussing the second method, we said that the other party's window object can be obtained between frameworks of different domains, and the window.postMessage method can also be used. Here is a simple example with two pages
The result we get after running a page:
We saw that page b successfully received the message.
It is quite intuitive and convenient to use postMessage to transmit data across domains, but the disadvantage is that IE6 and IE7 do not support it, so whether to use it or not depends on actual needs.