Solutions for Cross-origin communication between ajax and JS

In a recent project, ajax cross-Origin data retrieval is required. If it is in the current domain, but it is true that there is no problem, but the browser in the second-level domain and other domains will pop up a prompt box: "This page is
 
 
1. What causes cross-origin failure of ajax?
Ajax itself uses the XMLHttpRequest object to interact with data. For security reasons, the browser does not allow cross-origin operations of JavaScript code, so it will warn you.
2. Is there any perfect solution?
No. There are many solutions, but they can only be selected based on your actual situation.
 
Specific situations include:
1. Mutual access between the domain and subdomain: www.aa.com and book.aa.com
2. Mutual access between the domain and other domains: iframe for www.aa.com and www.bb.com
3. Mutual access between the domain and other domains: Use XMLHttpRequest as the access proxy for www.aa.com and www.bb.com
4. Mutual access between the domain and other domains: www.aa.com and www.bb.com use JS to create dynamic scripts
 
 
Solution:
1. If you want to achieve data interaction, you must develop www.aa.com and book.aa.com. You can use iframe to add book.aa.com to a page at www.aa.com and add document. domain = "aa.com" to both www.aa.com and iframe to unify the domain and implement cross-origin access. Just like the built-in iframe in the same domain, you can directly call the JS in it. (I did not try this method, but it is theoretically feasible)
 
 
2. When the two domains are different and you want to call each other, you also need to develop the two domains. Iframe can be used to call data. The solution is to use the hash attribute of the window. location object. The hash attribute is # dshakjdhsjka in http: // domian/web/a.htm # dshakjdhsjka. Using JS to change the hash value does not refresh the web page. In this way, you can use JS to access the hash value for communication. However, most browsers except IE only need to change the hash to record the history, and you need to handle it before and after it is very troublesome. But it can still be used for simple processing. I will download the specific code below. The general process is that page a and page B are in different domains, B is added to a through iframe, and a modifies the hash value of iframe through JS, B makes a listener (because JS can only modify the hash, and whether the data is changed can only be determined by B). It is detected that the hash value of B is modified and the modified value is obtained, after processing, return the value required by a, and then modify the hash value of a (Note that if a is the query page, such as http: // domian/web/. aspx? Id = 3, directly parent in B. window. location cannot obtain data, and an error with no permissions is reported. a needs to upload the data, which is also troublesome.) Similarly, a also needs to listen, if the hash changes, the returned data is obtained and processed accordingly.
 
 
3. This situation is the most common and most commonly used. You can modify only one of www.aa.com and www.bb.com, that is, the other is others'. People tell you what the connection parameter looks like if you want to obtain data, the format of the returned data. What you need to do is to create a webpage in your domain so that the server can obtain data from another website and then return it to you. A Under domain1 is directed to GetData in the same domain. aspx request data, GetData. aspx to ResponseData under domain2. aspx sends the request, ResponseData. aspx returns data to GetData. aspx, GetData. aspx is returned to a to complete a data request. GetData. aspx acts as a proxy. For more information, see my code.
 
 
4. the difference between this and the previous one is that the request uses the <script> tag for the request. This requirement is also required by you to develop both domains. The principle is JS file injection. a JS tag is generated within a in the domain. Its SRC points to a page B in another domain of the request and B returns data, you can directly return the JS Code. Because the src attribute of the script can be cross-origin. The Code is also relatively simple.
 
Code:
Http://www.live-share.com/files/300697/Cross_The_Site_Test_code.rar.html
(Can't csdn paste attachments ?)
 
Summary:
First case: domain and subdomain issues can completely resolve interactions.
Case 2: Cross-origin is difficult to implement and requires control from both domain developers. It is suitable for simple interaction.
Case 3: Cross-origin: developers only need to control one domain. It is a common method to add a proxy to obtain data.
Case 4: Cross-origin, both domain developers need to control and return a piece of js Code.
 
PS: the code can be modified as needed.
 
This is a reference link from others. There are many articles in laomei.
 
1. Security Considerations: Dynamic HTML
Http://msdn.microsoft.com/library/default.asp? Url =/workshop/author/dhtml/sec_dhtml.asp
 
2. About Cross-Frame Scripting and Security
Http://msdn.microsoft.com/library/default.asp? Url =/workshop/author/om/xframe_scripting_security.asp
 
3. Cross-Domain Proxy
Http://ajaxpatterns.org/Cross-Domain_Proxy
 
4. Cross Domain XMLHttpRequest using an IFrame Proxy
Http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book75
 
5. Back Button Support for Atlas UpdatePanels
Http://www.nikhilk.net/BackButtonSupport.aspx
 
6. Cross-document messaging hack
Http://blog.monstuff.com/archives/000304.html
 
7. Building Mash-ups with "Atlas"
Http://atlas.asp.net/docs/Walkthroughs/DevScenarios/bridge.aspx
 
8. Calling web services hosted outside of your application with "Atlas"
Http://blogs.msdn.com/federaldev/archive/2006/07/31/684229.aspx
 
Http://www.federaldeveloper.com/Shared%20Documents/Presentations%20by%20Marc%
 
20 Schweigert/CallAtlasWebServiceInDifferentProject.zip
 
9. AJAX Tip: Passing Messages Between iframes
Http://www.25hoursaday.com/weblog/PermaLink.aspx? Guid = 3b03cf9d-b589-4838-806e-64efcc0a1a15
 
10. OSCON Cross-site Ajax Slides
Http://blog.plaxo.com/archives/2006/07/oscon_crosssite.html
 
Http://www.plaxo.com/css/api/Joseph-Smarr-Plaxo-OSCON-2006.ppt
 
11. OSCON 2006: Cross-site Ajax
Http://www.sitepoint.com/blogs/2006/07/28/oscon-2006-cross-site-ajax/