

XDomain: A pure JavaScript CORS alternative - politician
https://github.com/jpillora/xdomain

======
axanoeychron
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.

~~~
jabo

        > Please don't use this unless you really have to
    

CORS is not fully supported in older versions of IE. So that essentially means
that we need to resort to these hacks just for IE.

~~~
jpillora
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.

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

[1]: [https://github.com/eligrey/pmxdr](https://github.com/eligrey/pmxdr) [2]:
[https://github.com/eligrey/libxdr](https://github.com/eligrey/libxdr)

~~~
jpillora
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?

------
gingerlime

        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?

~~~
esrauch
> 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.

~~~
e12e
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.

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

------
_greim_
> 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].

[1] [http://caniuse.com/cors](http://caniuse.com/cors)

------
majke
Cool stuff!

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

------
sktrdie
The Dropbox example doesn't seem to work for me:
[http://jpillora.com/xdomain/example/dropbox/](http://jpillora.com/xdomain/example/dropbox/)

I'm on latest Chrome, OS X and get this error:

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

~~~
jpillora
Used to be able to load HTTP->HTTPS (though not HTTPS->HTTP), now it looks
like both are blocked. Fixed.

------
gortok
There is another competitor in this space: EasyXDM. I've used it for about 5
months now, and I have to say it's pretty awesome.

~~~
Kiro
But doesn't EasyXDM require you to do all calls using their library? XDomain
is drop-in.

~~~
Sephr
The library EasyXDM uses internally to support CORS is pmxdr. I wrote pmxdr
and libxdr to be a CORS XHR drop-in.

~~~
Kiro
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.

EDIT2: Same thing.

~~~
Sephr
Yeah, it's only a drop in for XMLHttpRequest.

