IFRAME Cross-domain

A recent project that requires Ajax to get data across domains, if there is no problem in this domain, but placed in the two-level domain and other domains under the browser directly pop-up prompt box: "The page is accessing data outside its control, this is a bit dangerous, whether to continue"


1. What caused the problem of Ajax cross-domain
Ajax itself actually interacts with the data through the XMLHttpRequest object, and the browser does not allow the JS code to cross-domain operations for security reasons, so it warns.

2. What is the perfect solution?
No. There are many solutions, but only according to their own actual situation to choose.

The specific situation is as follows:
I. Mutual access to the domain and subdomains: www.aa.com and book.aa.com
Ii. Mutual access to the domain and other domains: IFrame for www.aa.com and www.bb.com
Third, mutual access to this domain and other domains: Www.aa.com and www.bb.com with XMLHttpRequest Access Proxy
Iv. Mutual access to the domain and other domains: www.aa.com and www.bb.com Create dynamic scripts with JS


Workaround:
First, if you want to do data interaction, then www.aa.com and book.aa.com must be developed by you. Book.aa.com can be added to the www.aa.com with an IFRAME under a page, www.aa.com and iframe with document.domain = "aa.com", so that you can unify the domain, you can achieve cross-domain access. In peace when the same domain embedded iframe, directly invoke the inside of the JS can be. (This method I did not try, but the theory is feasible)


Second, when two domains are not at the same time, if you want to call each other, then the same need two domain is you to develop. Using IFRAME can make the data call each other. The solution is to use the hash attribute of the Window.location object. The hash attribute is the #dshakjdhsjka inside the Http://domian/web/a.htm#dshakjdhsjka. The use of JS to change the hash value of the page will not be refreshed, can be achieved by JS access to hash value to achieve communication. However, except IE, most of the other browsers just change the hash will record history, you need to deal with forward and backward, very troublesome. However, the simple processing can still be used, the specific code I will download the following. The general process is the page A and page b in different domains, B through the IFRAME added to a, a through JS to modify the hash value of the IFRAME, B inside to do a monitoring (because JS can only modify the hash, the data can only be changed by the B itself to judge), the detection of B's hash value has been modified, Get the modified value, after processing return a required value, and then to modify the hash value of a (this place to note, if a itself is the kind of query page, such as http://domian/web/a.aspx?id=3, In B, the direct parent.window.location is unable to obtain data, the same report does not have the authority of the error, need A to pass this, so also more trouble), the same a inside also to do the monitoring, if the hash changes to obtain the data returned, and then do the corresponding treatment.


Third, this situation is most often encountered, but also the use of the most. It's www.aa.com and www.bb.com. You can only modify one, that is, another is someone else's, they tell you to get the data on the access to a certain connection parameter is what it looks like, and finally return the data is what format. And all you have to do is create a new Web page in your domain and let the server get the data on someone else's website and return it to you. Domain1 A to the getdata.aspx request data under the same domain, Getdata.aspx sends the request to responsedata.aspx under Domain2, Responsedata.aspx returns the data to Getdata.aspx , Getdata.aspx returns to a, which completes a data request. Getdata.aspx acted as an agent in it. Specifically, you can look at my code.


The difference between this and the last is that the request is requested using the <script> tag, and this requirement is also two domains that are developed by you. The principle is JS file injection, in the domain of a within a JS tag, its SRC point to the request of another domain of a page b,b return data can be directly back to JS code. Because the SRC attribute of the script can be cross-domain. Look at the code specifically, this is also relatively simple.

Code
Http://www.live-share.com/files/300697/Cross_The_Site_Test_code.rar.html
(Csdn can't paste attachments?) )

Summarize:
The first scenario: domain and subdomain issues that can completely resolve the interaction.
Second case: cross-domain, the implementation of the process is very cumbersome, requires two domain developers can control, suitable for simple interaction.
The third case: cross-domain, developers only control a domain, the implementation process needs to increase the agent to obtain data, is a common way.
Fourth case: cross-domain, two domain developers need to control, return a section of JS code.

PS: The code itself can be modified according to the situation.

This is to take other people's reference link, the old beautiful article more.

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 a 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%

20schweigert/callatlaswebserviceindifferentproject.zip

9. AJAX tip:passing Messages between IFRAMEs
HTTP://WWW.25HOURSADAY.COM/WEBLOG/PERMALINK.ASPX?GUID=3B03CF9D-B589-4838-806E-64EFCC0A1A15

Ten. 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

OSCON 2006:cross-site Ajax
http://www.sitepoint.com/blogs/2006/07/28/oscon-2006-cross-site-ajax/

IFRAME Cross-domain