JavaScript is a front-end dynamic scripting technology often used in web development. In JavaScript, there is a very important security restriction called "Same-Origin Policy". This policy places important restrictions on the page content that JavaScript code can access, that is, JavaScript can only access content in the same domain as the document that contains it.
JavaScript security strategy is particularly important when performing multi-iframe or multi-window programming, as well as Ajax programming. According to this policy, JavaScript code contained in pages under baidu.com cannot access page content under the google.com domain name; even pages between different subdomains cannot access each other through JavaScript code. The impact on Ajax is that Ajax requests implemented through XMLHttpRequest cannot submit requests to different domains. For example, pages under abc.example.com cannot submit Ajax requests to def.example.com, etc.
However, when doing some in-depth front-end programming, cross-domain operations are inevitably required. At this time, the "same origin policy" appears to be too harsh. This article summarizes some technologies required for cross-domain on this issue.
Next we discuss cross-domain technology in two situations: first, we discuss cross-domain technology in different subdomains, and then we discuss cross-domain technology in completely different domains.
(1) Cross-domain technologies in different subdomains.
We will discuss two questions separately: the first question is how to make JavaScript calls across different subdomains; the second question is how to submit Ajax requests to different subdomains.
Let’s solve the first problem first. Suppose there are two different subdomains under the example.com domain: abc.example.com and def.example.com. Now suppose there is a page under def.example.com, which defines a JavaScript function:
We want to call the above function in a page under abc.example.com. Suppose that the page under abc.example.com we want to discuss is embedded in the page under def.example.com in the form of an iframe. In this case, we may try to make the following call in the iframe:
Okay, we noticed that this call is prohibited by the "same origin policy" mentioned earlier, and the JavaScript engine will directly throw an exception.
In order to implement the above call, we can do it by modifying the domain attributes of the two pages. For example, we can add the following JavaScript code snippets to the top of the two pages above abc.example.com and def.example.com:
In this way, the two pages become the same domain, and the previous call can be executed normally.
One thing to note here is that the document.domain attribute of a page can only be set to a higher-level domain name (except for the first-level domain name), but cannot be set to a subdomain deeper than the current domain name. For example, the page abc.example.com can only set its domain to example.com, not sub.abc.example.com, and of course it cannot be set to the first-level domain name com.
The above example discusses the case where two pages belong to an iframe nested relationship. When the two pages have an open and opened relationship, the principle is exactly the same.
Now let’s solve the second problem: how to submit Ajax requests to different subdomains.
Normally, we will use code similar to the following to create an XMLHttpRequest object:
The above code references ActiveXObject for compatibility with IE6 series browsers. Every time we call the newRequest function, we get a newly created Ajax object, and then use this Ajax object to send an HTTP request. For example, the following code sends a GET request to abc.example.com:
Assuming that the above code is included in a page under the abc.example.com domain name, the GET request can be sent successfully without any problems. However, if we now send a request to def.example.com, a cross-domain issue occurs and the JavaScript engine throws an exception.
The solution is to place a cross-domain file under the def.example.com domain, assuming it is called crossdomain.html; then move the definition of the previous newRequest function to this cross-domain file; and finally modify the document as before. The domain value is the same. At the top of the crossdomain.html file and the page that calls Ajax under the abc.example.com domain, add:
[code]
http://def.example.com/crossdomain.html">>
At this time, the page under the abc.example.com domain and the cross-domain file crossdomain.html are both under the same domain (example.com). We can call crossdomain in the page under the abc.example.com domain. newRequest function in html:
The request object obtained in this way can send an HTTP request to http://def.example.com.
(2) Cross-domain technologies in completely different domains.
If the top-level domain names are different, for example, example1.com and example2.com want to communicate on the front end through JavaScript, the required technology is more complicated.
Before explaining cross-domain technologies in different domains, let us first make it clear that the technologies to be discussed below are also applicable to the previous situation across different sub-domains, because crossing different sub-domains is only a special case of cross-domain problems. Of course, using the right technology under the right circumstances can ensure better efficiency and higher stability.
In short, according to different cross-domain needs, cross-domain technologies can be classified into the following categories:
1. JSONP cross-domain GET request
2. Achieve cross-domain through iframe
3. Flash cross-domain HTTP request
4. window.postMessage
This article ends here first. We will introduce the 4 cross-domain technologies mentioned above in detail later on!