JS cross-Domain access

Issue: What types of address access are cross-domain access

URL type	Intranet URL (abbreviated)	Description	Whether access is allowed
Http://www.xxyy.com/1.js Http://www.xxyy.com/2.js	Http://ecapp01/1.js Http://ecapp02/2.js	Under the same domain name	YES
Http://www.xxyy.com/1.js Http://www.xxyy.com/b/2.js	Http://ecapp01/1.js Http://ecapp02/b/2.js	Different folders under the same domain name	YES
Http://www.xxyy.com/1.js Https://www.xxyy.com:1234/2.js	Http://ecapp01/1.js Http://ecapp02:9090/b/2.js	The lower end of the same domain is not	NO
Http://www.xxyy.com/1.js Http://www.cc.xxyy.com/2.js	Http://ecapp01/1.js Http://ecapp03/2.js	Primary domain name is the same, sub-domain name is different Two IIS servers under the intranet are located under different domains	NO
Http://www.xxyy.com/a.js Http://www.xxyy.com/childsite/b.js	Http://ecapp01/1.js Http://ecapp01/childsite/2.js	Same server child site	YES

Instance scenario:

Production environment workflow platform released on server: srvflow.ent.com.cn

Test environment Workflow platform published on server: Srvflowtest.test.dom

Production environment Business form published on server: srvbizform.ent.com.cn

Test environment Business form published on server: Srvbizformtest.test.dom

Application not b/s architecture

The workflow platform wants to integrate various business forms through the IFRAME, enabling the loading of business forms, and operational approvals

Platform and business forms follow parameters and interface definitions

Scenario Issues:

In the test environment through the IFRAME operation is normal, when the business form is the test environment application, and the workflow platform is the production environment server, then generated the JS cross-domain access problem

Workaround:

Because the IFRAME must be used, it is necessary to ensure that the primary domain is consistent;

Create a business form in srvflow.ent.com.cn to create a test site and a production site, so that the primary domain is the same

However, the workflow job platform application site and the business form site port are not reachable, so it is still a cross-domain access, but the problem has become simple

1. Workflow Platform HTML settings

Document.domain = ' srvflow.ent.com.cn ';

2. Business Form HTML settings

Document.domain = ' srvflow.ent.com.cn ';

This allows you to freely manipulate the business form through the framework

Iframework.submit (' "+ Doitem. Parms + "');

Appendix **********************************************************

One, cross-domain through JSONP

1. By referencing the file method

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 where the code needs to use AJAX to get JSON data from a different domain.

Assuming that the JSON data address is http://example.com/data.aspx, then the code in a.html can do this:

<script>

Funcion Callback ()

{

Do something

}

</script>

<script src= ' Http://example.com/data.aspx?callback=callback ' ></script>

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.aspx return must be an executable JS file, so the background code of this page may be this:

 protected void Page_Load (        object sender, EventArgs e) {string result = "callback ({\" name\ ": \" Zhangsan\ ",            \ "date\": \ "2012-12-03\"}) ";            Response.Clear ();            Response.Write (Result);        Response.End (); 
 The client full code might look like this 
      

<script type= "text/javascript" >        null;        Window.onload = function () {            var script = document.createelement ("script");            Script.type = "text/javascript";            SCRIPT.SRC = "http://example.com/data.aspx";            var head = document.getElementsByTagName ("head") [0]; Head.insertbefore (script, head.firstchild);}; function callback (data) {result = data;} function B_click () {alert (result.name);} </script>    

2. Through jquery

<script type= "text/javascript" >

$.getjson ('http://example.com/data.aspx', function (data) {
Do something
})

</script>

After the data is obtained, it is automatically destroyed, which is actually the function of a temporary agent function. $.getjson method will automatically determine whether cross-domain, not cross-domain, then call the ordinary Ajax method;
Cross-domain, the JSONP callback function is invoked in the form of an asynchronously loaded JS file.

Second, by modifying the document.domain to cross the subdomain

Browsers have a homologous policy,

One of the limitations is that in the first approach we say that you cannot request a document from a different source by using AJAX methods.

The second limitation of the

is that the frames of different domains in the browser are not interoperable with JS. 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 cannot use the properties and methods of the retrieved window object (the PostMessage method in HTML5 is an exception, and some browsers such as IE6 You can use a few properties such as top, parent, and so on, 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:

<script>
function Btn_click () {
var Ifm=document.getelementbyid (' Iframework ')
var cont=ifm. Contentwindow;
alert (cont.document);//null
alert (cont.name);//null
}
</script>

This time, document.domain can come in handy, we just put http://www.example.com/a.html and http://example.com/b.html this 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:

Document.domain = ' srvflow.ent.com.cn ';

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:

Document.domain = ' srvflow.ent.com.cn ';

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.

Third, using Window.name to cross-domain

The Window object has a Name property, which has a feature: in the lifetime of a window, all the pages loaded by the window share a Window.name, each page has permission to read and write to Window.name, and Window.name is persisted in 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:

Window.name= ' This is a.html data ';

Page b.html, which has this code:

alert (window.name);

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, to get the window.name value of the IFRAME, you must also put this IFRAME SRC is set to the same domain as the a.html page, otherwise, according to the same Origin policy, a.html cannot access the Window.name attribute in the IFRAME. This is the entire cross-domain process.

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.

JS cross-Domain access