Comments on: Cross domain access now, and support for the future http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future Cleaning up the web with Ajax Sat, 13 Mar 2010 17:21:22 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: stefanoc http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-271620 stefanoc Wed, 25 Feb 2009 13:22:10 +0000 http://ajaxian.com/?p=3991#comment-271620 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 <strong>any access to the remote servers</strong> 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 <a href="http://dev.mixendo.com/MiXHR" title="mixendo cross-domain xhr (MiXHR)" rel="nofollow">cross-domain xhr</a> 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 <a href="http://dev.mixendo.com/wiki/Mixendo_XHR_Security" title="Mixendo Cross-domain XHR Security" rel="nofollow">cross-domain security model</a>, 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 <a href="http://dev.mixendo.com" title="Mixendo Developers" rel="nofollow">Mixendo Developers Website</a> to learn more about our MiXHR Service and other upcoming cross-domain/mash-up solutions. 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.

]]> By: shadedecho http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266364 shadedecho Mon, 04 Aug 2008 01:26:09 +0000 http://ajaxian.com/?p=3991#comment-266364 @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. @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.

]]> By: kriszyp http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266361 kriszyp Sun, 03 Aug 2008 19:26:44 +0000 http://ajaxian.com/?p=3991#comment-266361 @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: <a href="http://www.sitepen.com/blog/2008/07/22/windowname-transport/" rel="nofollow">http://www.sitepen.com/blog/2008/07/22/windowname-transport/</a>) @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/)

]]> By: Loganathan http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266353 Loganathan Sat, 02 Aug 2008 08:34:38 +0000 http://ajaxian.com/?p=3991#comment-266353 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. 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.

]]> By: Loganathan http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266352 Loganathan Sat, 02 Aug 2008 08:20:01 +0000 http://ajaxian.com/?p=3991#comment-266352 Will this help to fetch another domain's data through ? please tell me the answer? Will this help to fetch another domain’s data through ? please tell me the answer?

]]> By: linb http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266349 linb Sat, 02 Aug 2008 00:01:51 +0000 http://ajaxian.com/?p=3991#comment-266349 window.name technique is better for FIM. It enable you run an remote Ajax RIA application from a single local disk html file. <a href="http://knol.google.com/k/yb-li/how-to-run-an-remote-ajax-ria" rel="nofollow">How to run an remote Ajax RIA application from a single local disk html file</a>. 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.

]]> By: ragjunk http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266346 ragjunk Fri, 01 Aug 2008 21:57:47 +0000 http://ajaxian.com/?p=3991#comment-266346 @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) @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)

]]> By: kriszyp http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266342 kriszyp Fri, 01 Aug 2008 19:42:34 +0000 http://ajaxian.com/?p=3991#comment-266342 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. 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.

]]> By: Nosredna http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266335 Nosredna Fri, 01 Aug 2008 16:40:33 +0000 http://ajaxian.com/?p=3991#comment-266335 I'm learning Dojo now, and it normally uses iFrames for this, right? Is there a case when using iFrames doesn't work? I’m learning Dojo now, and it normally uses iFrames for this, right? Is there a case when using iFrames doesn’t work?

]]> By: V1 http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266326 V1 Fri, 01 Aug 2008 13:20:13 +0000 http://ajaxian.com/?p=3991#comment-266326 ill rather use flashxhr, same effect less mess. ill rather use flashxhr, same effect less mess.

]]> By: henrah http://ajaxian.com/archives/cross-domain-access-now-and-support-for-the-future/comment-page-1#comment-266324 henrah Fri, 01 Aug 2008 12:30:59 +0000 http://ajaxian.com/?p=3991#comment-266324 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. 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.

]]>