JS cross-Domain notes

What is cross-domain, cross-domain refers to the mutual access between different domains, as long as the protocol, domain names, ports are any different, are treated as a different domain.

For the different ports and protocols, only through the background to solve, the front desk is powerless.

Subject to browser-origin policy, JS in this domain cannot manipulate page objects (such as the DOM) of other domains. The homologous strategy (same origin policy) is a convention, which is the most core and basic security function of the browser.

Here need to be clear: the so-called domain is not related to JS storage server, such as Baidu.com page loaded google.com js, then this JS domain is baidu.com instead of google.com. In other words, this JS can manipulate the Baidu.com Page object, and cannot manipulate the Google.com Page object.

1 cross-domain resource sharing (CORS)

CROS (cross-origin Resource sharing) cross-domain resource sharing, which defines how the browser and server should communicate when accessing cross-domain resources. The basic idea behind Cros is to have the browser communicate with the server using a custom HTTP header to determine whether the request or response should succeed or fail.

var xmlhttp;if (window. XMLHttpRequest)  {//code for ie7+, Firefox, Chrome, Opera, Safari  xmlhttp=new XMLHttpRequest ();  } else  {//code for IE6, IE5  xmlhttp=new activexobject ("Microsoft.XMLHTTP");  } Xmlhttp.onreadystatechange=function ()  {  if (xmlhttp.readystate==4 && xmlhttp.status==200)    {    document.getElementById ("mydiv"). Innerhtml=xmlhttp.responsetext;    }  } Xmlhttp.open ("GET", "www.ggggg.com", true); Xmlhttp.send ();

Entering the absolute path in the open URL is cors.

The server-side support for cors is mainly done by setting up Access-control-allow-origin. If the browser detects the appropriate settings, it can allow Ajax for cross-domain access. Isn't it convenient?

2 Jsonp cross-domain

So what's the problem? What is JSONP? Wikipedia is defined as: JSONP (JSON with Padding) is a "usage pattern" of data format JSON that allows Web pages to be data from other domains.

Jsonp, also known as fill JSON, is a new way to apply JSON. It's just a JSON that is contained in a function call.

JSONP consists of two parts: the callback function and the data. The callback function is the function that should be called in the page when the response arrives, and the data is the JSON data that is passed into the callback function.

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.

Compared with JSONP, Cors is undoubtedly more advanced, convenient and reliable.

1. JSONP can only implement get requests, and Cors supports all types of HTTP requests.

2, using cors, developers can use ordinary XMLHttpRequest to initiate requests and obtain data, than JSONP have better error handling.

3. JSONP is primarily supported by older browsers, which often do not support cors, and most modern browsers already support Cors.

3 Document.domain Cross-subdomain

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.

4. Use Window.name for 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.cnblogs.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.cnblogs.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.

5. Use the newly introduced Window.postmessage method in HTML5 to transfer data across domains

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 that IE6, IE7 does not support, so the use of the need to decide according to actual needs.

6 Creating script dynamically

Because the script tag is not limited by the same-origin policy.

function Loadscript (URL, func) {  var head = Document.head | | document.getelementbytagname (' head ') [0];  var script = document.createelement (' script ');  script.src = URL;  Script.onload = Script.onreadystatechange = function () {    if (!this.readystate | | this.readystate== ' loaded ' | | this.readystate== ' complete ') {      func ();      Script.onload = Script.onreadystatechange = null;    }  };  Head.insertbefore (script, 0);} Window.baidu = {  sug:function (data) {    console.log (data);  }} Loadscript (' Http://suggestion.baidu.com/su?wd=w ', function () {console.log (' Loaded ')});//Where is the content we requested? We can see what the script introduces in the source of the Chorme debug panel

7 Server-side proxy implementation

This is a way of not implementing cross-domain through JS: Through the server-side proxy implementation.

Specific ideas: Because the browser has the same-origin policy restrictions , so you want to cross-domain access to resources under other domains, you need to bypass the browser of this limit, you can set up a proxy on the server side, the server side of the cross-domain site to make requests, and then return the request results to the front end, the limitations of the same-origin policy are successfully avoided.

Here's how:

1. In localhost:81/a.html, make a request to an agent under homologous

$.ajax ({    URL: '/proxy.php?name=hello&info=information ',   //server-side agent    type: ' GET ',    success: function () {}})

2, in the agent proxy.php, to the non-homologous server issued a request, obtain the results of the request, the results are returned to the front end.

<?php $name =$_get[' name ']; $info = $_get[' info ']; $crossUrl = ' http://b.com/sub?name= '. $name;   Make a request to another domain $res = file_get_contents ($CROSSURL); echo $res;  ? >

When the data provider does not provide support for the JSONP protocol or the Window.name protocol, and there is no open access to other domains, we can crawl the data through the server proxy. For example, when a page under the baidu.com domain needs to request a resource file getusers.php under Google.com, sending a direct AJAX request to google.com/getusers.php is definitely blocked by the browser. At this point, we have an agent under Baidu.com, and then bind the AJAX request to this proxy path, such as baidu.com/proxy/, The proxy then sends an HTTP request to access the getusers.php under Google.com, and the cross-domain HTTP request is made on the server side (the server side has no same-origin policy restrictions), and the client does not produce a cross-domain Ajax request. This cross-domain approach does not require an agreement with the target resource and is aggressive.

8 Flash URLLoader

Flash has its own set of security policies that can be used by the server to declare which domain SWF files can be accessed by the Crossdomain.xml file, and SWF can also use the API to determine which domain SWF it can load. When accessing resources across domains, such as data from a domain baidu.com request domain google.com, we can use Flash to send HTTP requests. First, modify the crossdomain.xml on the domain google.com (typically stored in the root directory, if you do not need to create it manually), and add baidu.com to the whitelist. Second, send HTTP requests via Flash Urlloader, and finally pass the response results to JavaScript via the Flash API. Flash Urlloader is a common cross-domain solution, but if you need support for iOS, this is not a good solution.

JS cross-Domain notes