Friday, August 1st, 2008

Cross domain access now, and support for the future

Category: XmlHttpRequest

<p>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
< view plain text >
  1. // Access-Control: allow < *> for XHR
  2. dojox.io.xhrPlugins.addCrossSiteXhr("http://othersite.com/");
  3. dojo.xhrGet({url:"http://othersite.com/data"})
  4.  
  5. // window.name
  6. dojo.require("dojox.io.xhrWindowNamePlugin");
  7. dojox.io.xhrWindowNamePlugin("http://othersite.com/");
  8.  
  9. // proxy for the other folk
  10. dojox.io.xhrPlugins.addProxy("/proxy?url=");

Fantastic work as usual.

Related Content:

Posted by Dion Almaer at 6:45 am
10 Comments

+++--
3.9 rating from 39 votes

10 Comments »

Comments feed TrackBack URI

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.

Comment by henrah — August 1, 2008

ill rather use flashxhr, same effect less mess.

Comment by V1 — August 1, 2008

I’m learning Dojo now, and it normally uses iFrames for this, right? Is there a case when using iFrames doesn’t work?

Comment by Nosredna — August 1, 2008

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.

Comment by kriszyp — August 1, 2008

@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)

Comment by ragjunk — August 1, 2008

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.

Comment by linb — August 1, 2008

Will this help to fetch another domain’s data through ? please tell me the answer?

Comment by Loganathan — August 2, 2008

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.

Comment by Loganathan — August 2, 2008

@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/)

Comment by kriszyp — August 3, 2008

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

Comment by shadedecho — August 3, 2008

Leave a comment

You must be logged in to post a comment.