This is an interesting hack: a host script can communicate with scripts in an iframe via the postMessage API and relying on the fact that a script running in the frame can make same-domain requests.
I am worried that people will choose this option just because it is easier rather than use what is technically the right thing to do. (CORS) Please don't use this unless you really have to. The arguments against CORS in the Readme aren't really compelling. The web is messy enough as it is.
It would be nice if we could forego these hacks, as @jabo mentioned, hacking around lack of support is our only choice. If it's not iframe+postMessage, then it'd be flash - either way it's suboptimal.
XDomain is not a CORS polyfill as incorrectly stated in the readme. If it actually supported CORS, you could configure it with Access-Control-* headers and it would magically work. I wrote pmxdr[1] and libxdr[2] 5 years ago, which enable the same functionality while also actually supporting CORS headers, so it does magically work after dropping in.
Accepted your PR, this is indeed a CORS alternative, not a polyfil.
I did think about utilizing CORS headers, however by placing a proxy.html file on your domain, you can be seen as implicitly allowing cross-domain requests. I've added a simple DSL to the script tag to futher restrict access. To only accept requests from 'foo.master-domain.com', just do:
<script ... master="foo.master-domain.com">
Adding CORS to XDomain is an unnecessary complication, CORS requires modifying the server code, CORS can cause superfluous requests and CORS sucks.
RE: pmxdr: since you don't replace XMLHttpRequest, it doesn't work after dropping it in. Does jQuery's $.ajax magically work? Angular's $http?
Conceptual Overview
XDomain will create an iframe on the master to the slave's proxy.
Master will communicate to slave iframe using postMessage.
Slave will create XHRs on behalf of master then return the results.
XHR interception is done seamlessly via XHook.
This sounds like some rather complex hack and to promote this as a silver-bullet instead of CORS seems a little odd or maybe even irresponsible to be honest.
Q: But I love CORS
A: You shouldn't. You should use XDomain because...
Can you ensure that browsers or ad blockers won't block this kind of behaviour. Do you really want to go through those hoops just to save you from setting up a (server-side) proxy in the worst case, or try to get who you need to use CORS with to allow it on their domain?
> Can you ensure that browsers or ad blockers won't block this kind of behaviour
> [...] or try to get who you need to use CORS with to allow it on their domain?
There's no fundamental security difference between this and actual CORS since it requires the actual domain specifically serve a particular response to allow it. Either you have the ability to serve the proxy file from a particular domain and the general ability to set CORS headers, or you don't.
I'm sorry, I've not looked at the code yet, but are you saying that being able to drop a html-file in some misconfigured servers public ftp-directory, or on some blogs upload folder is equivalent to being able to set http-headers?
That's only true if CORS accept html-meta tags as replacement for http headers (which I don't think it does)?
Again, I might be missing something, not having looked at the code yet, but it sounds like a rather strong statement.
For me XDomain is an essential tool to get CORS working in IE, for example when building a SPA with the API on a different domain. Very easy to implement and works transparently without needing to change anything else.
> IE uses a different API (XDomainRequest) for CORS...
This is true and is pretty sad. I'm sure MS had various internally-focused reasons for it, but it has really held the world back. That said, it appears they finally got with the program as of IE10[1].
This concept is pretty much how I started with SockJS. I realized that by using the iframe/postmessage it is possible to get decent "realtime" in all the browsers. For example Opera had EventSource but it didn't support cross domain. But it did support iframe/postmessage....
To make things even more exciting the iframe was loaded with proper (third party) cookies, so it is theoretically possible to use cookie-based authorization (at least to some extent).
Cookies are also required in long-polling scenarios to get sticky sessions, think: JSESSIONID.
But the problem is browsers nowadays block third party cookies and CORS just works, so there is _no_ need for the postmessage hack. Sadly...
[blocked] The page at 'https://dl.dropboxusercontent.com/u/14376395/html/proxy.html'
was loaded over HTTPS, but ran insecure content from
'http://jpillora.com/xdomain/dist/0.6/xdomain.js': this content should
also be loaded over HTTPS.
Ok, pmxdr seems more like it. I want to continue using my jQuery and Angular requests without messing with the procedure.
EDIT: Or, actually pmxdr doesn't look like drop-in in the sense I mean at all. I want to use jQuery's $.ajax and Angular's $http. I need to have a look at libxdr.
I am worried that people will choose this option just because it is easier rather than use what is technically the right thing to do. (CORS) Please don't use this unless you really have to. The arguments against CORS in the Readme aren't really compelling. The web is messy enough as it is.