Friday, August 1st, 2008
Cross domain access now, and support for the future
Kris Zyp is really leading the charge on various missions such as JSON-* and XHR-*. This time he has a posting on a new cross-site XHR plugin repository that wraps up the myriad of techniques that are both pending in standards (XDomain, XHR++) and work arounds (window.name, magic iframe hackery). It also falls back to the faithful "just put up a proxy" for those poor browsers that can't handle the ninja.
JAVASCRIPT:
-
-
// Access-Control: allow <*> for XHR
-
dojox.io.xhrPlugins.addCrossSiteXhr("http://othersite.com/");
-
dojo.xhrGet({url:"http://othersite.com/data"})
-
-
// window.name
-
dojo.require("dojox.io.xhrWindowNamePlugin");
-
dojox.io.xhrWindowNamePlugin("http://othersite.com/");
-
-
// proxy for the other folk
-
dojox.io.xhrPlugins.addProxy("/proxy?url=");
-
Fantastic work as usual.
4 rating from 33 votes
I don’t think there are any browsers that can’t do window.name message-passing; the proxy option is for supporting other sites which don’t have a cross-domain request api to call.
ill rather use flashxhr, same effect less mess.
I’m learning Dojo now, and it normally uses iFrames for this, right? Is there a case when using iFrames doesn’t work?
Dojo does have an iframe mechanism for cross-domain loading that uses fragment identifiers (#hash) to transfer data. However, this technique is very limited, it can only send messages in 2K chunks. The windowName module and the new native APIs are much more efficient.
@V1: How would flash based XHR work, if my site is not in the crossdomain.xml of the target site? I want to do an XHR from my online app to any third party site, but I cannot do that because my site is not listed in any of their xdomain XML. So, I think, Kris’ work would help me better than using any of the flash based XHR, unless I missed something totally. (which happens many a times)
window.name technique is better for FIM. It enable you run an remote Ajax RIA application from a single local disk html file.
How to run an remote Ajax RIA application from a single local disk html file.
Will this help to fetch another domain’s data through ? please tell me the answer?
i am looking for a solution to read some contents of another domain’s page data .. i am loading into iframe in my page.. is it possible toaccess it.
@ragjunk, @Loganathan: This approach requires that the target site opt-in by providing data using window.name technique, it doesn’t enable you to break the “steal” data without the target site’s consent; the target site must provide the data by setting the window.name. If you want the target site to provide you data using the secure window.name technique, encourage them to implement the protocol (it is defined here: http://www.sitepen.com/blog/2008/07/22/windowname-transport/)
@V1-flXHR is better (IMHO) because it implements the native XHR API. http://flxhr.flensed.com/ :)
@ragjunk-You’re right, the server has to grant permission. But that’s specifically the reason, the point. Technologies which permit or encourage totally unrestricted x-domain access are far less secure. And, with window.name, as kriszyp says, the server *does* have to opt-in, so it’s a good thing.
But, more importantly for the open web revolution, for sites which want to publish their content to anyone, and it’s safe for them to do so, they can use a “*” policy in their crossdomain.xml, which allows anyone to access it, without worrying about needing to specifically grant permission to each domain.
Without a client-oriented cross-domain Ajax, developing mash-up applications aggregating content for all sources is pretty much impossible. We have a page on [http://dev.mixendo.com/MiXHR Alternative Cross-domain Ajax solutions] where we discuss all possible solutions, but we wanted one which would work without any access to the remote servers we want to access.
This is why we have implementented the proxy pattern to provide cross-domain AJAX.
What’s more, we have opened this to anybody willing to use our infrastructure.
Include our cross-domain xhr javascript and:
1) keep using the XMLHttpRequest object as usual – just, it’s cross-domain enabled
2) you can make both GET and POST request… which is vital considering that GET is limited in lenght!
3) our proxy does implements a cache (squid based) to improve performance
4) our proxy can take care of cookies, mandatory for some websites
5) we have an improved cross-domain security model, the developer has to declare which sources his application is going to connect to so that the user know what’s going on. It’s not a perfect solution, but it’s a little improvement.
I can’t disclose much more yet, but we also are working on a pure client side solution which overcomes potential proxy issues, but we do believe the Proxy solution is a feasible one!
Please have a tour on our Mixendo Developers Website to learn more about our MiXHR Service and other upcoming cross-domain/mash-up solutions.