

EasyXDM – crossdomain javascript done right - Swizec
http://www.zemanta.com/fruitblog/easyxdm-crossdomain-javascript-done-right/

======
re
EasyXDM is apparently a wrapper around HTML5's window.postMessage() with
fallbacks for older browsers.

[http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/web-messaging.html#web-messaging)

------
edd
For people who prefer code to do the talking you can find the EasyXDM repo
here: <https://github.com/oyvindkinsey/easyXDM>

------
amix
If you control the domains you can use script tags communication or Cross-
Origin Resource Sharing Ajax (for newer browsers). This makes it possible to
create cross domain communication with a few lines of code and it works in
most modern browsers. I blogged about my experience here:
<http://amix.dk/blog/post/19677>

~~~
arijo
Yeah, but this is no solution if you want to provide a javascript sdk api for
external developers to access.

------
fiznool
I recently had a problem with a cross domain AJAX call to a third party web
service which requires a JSESSIONID cookie to be present in each request for
session management.

On the face of it, CORS supports this by setting withCredentials: true on the
XHR object being sent over the wire. But as I was building a PhoneGap app, the
files were being loaded using the file:// protocol, which has the side-effect
of setting the Origin header to null whenever you make an AJAX call. According
to the CORS spec, when using withCredentials, you must set the response header
Access-Control-Allow-Origin on the server to something _other_ than the
wildcard *. In this case, it would need to be my Origin. But since my Origin
was null, I was stuffed, and I don't think that what I was trying to do, could
be done.

Do you think EasyXDM might help here?

(The scenario is explained in more detail on Stack Overflow:
[http://stackoverflow.com/questions/9103876/cors-cookie-
crede...](http://stackoverflow.com/questions/9103876/cors-cookie-credentials-
from-mobile-webview-loaded-locally-with-file) )

~~~
jacobolus
This seems like a bug / missing feature in Phone Gap. You should ask them for
advice / file a ticket. This sort of thing sounds like a generally useful
feature to have, so hopefully they should be receptive.

~~~
fiznool
Good idea. I tried them on Twitter but they seem a bit busy to respond right
now :) Will see if I can get through to them.

------
mike-cardwell
There's a HTTP response header that a site can return to allow cross-domain
ajax. I don't recall the details off the top of my head.

~~~
Animus7
Access-Control-Allow-Origin, aka CORS.

<http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing>

~~~
mradmin
This solves all issues but unfortunately is not well supported in the older
browsers :(

------
karlokeeffe
I recently used EasyXDM at work to implement a JavaScript API to allow access
to a presentation player within an iFrame.

Very impressed with the ease of integration, and with support for IE6 (I used
the Flash Transport).

I would heartily recommend it if you need to support very old browsers, and
have no control of the parent page.

------
meow
I found eaxyXDM to be well.. not so easy. Not in actual usage but it felt like
too much of magic going around, which made me uncomfortable using it (what if
some thing breaks and I'm not able to fix it..). I ended up using much more
limited but much easier to understand code at this location:
[http://www.onlineaspect.com/2010/01/15/backwards-
compatible-...](http://www.onlineaspect.com/2010/01/15/backwards-compatible-
postmessage/)

It uses postmessage for newer browsers and hash location trick for older
browsers.

------
Animus7
TL;DR

A bag of neatly unified transport hacks around X-Domain restrictions. Like
Socket.io, but without the proxy server and direct connect instead of pub/sub.

~~~
jacobolus
Incorrect. This library is for communication between two browser frames or
windows. Socket.io and other Comet servers are for communication between a
browser client and a server (sometimes these Comet servers use some kind of
communication channel between frames on different domains as part of their
internal machinery, but that’s just an implementation detail).

~~~
Animus7
I think we're both correct here. Blasting data between frames to get around
cross-domain restrictions is a means to an end.

What you're _really_ trying to achieve is data moving between hosts at
different domains: i.e. pushing or pulling. In that sense both this and
Socket.io are trying to achieve the same thing, only EasyXDM is more free-form
about it.

Though I do admit I haven't used EasyXDM myself so I could be totally
confused. The repo documentation is long and vague, hence my TL;DR.

~~~
jacobolus
As a comment elsewhere in this discussion says (it really should be voted up
to the top), EasyXDM is just a wrapper for the HTML5 postmessage API, with
fall-backs in browsers which don’t support it.

* * *

> _What you're really trying to achieve is data moving between hosts at
> different domains_

Not really. Usually when you use something like EasyXDM, the goal is either to
build a site that has different server components located on different domains
under your control, or to build a mashup between services explicitly set up to
be used for mashups. There’s no data being “moved between hosts”; we’re just
combining two data sources in one browser window.

When you use a Comet server like socket.io, by contrast, the goal instead is
to open up a persistent connection between browser and server, so that data
can be sent back and forth. Also, FWIW, there’s nothing in socket.io or most
Comet servers that forces a developer to implement a pub/sub system, as you
implied in your first post. [As I said before, sending cross-domain messages
between frames, e.g. using EasyXDM, might be part of the inner workings of the
browser side of some Comet transports, but that’s just an implementation
detail, and an application developer would not be expected to touch that code
or care about it; it’s just a black box.]

Neither one of these really matches your description, and the two are
substantially different from each other. I think you’re confused.

------
petercooper
Funny to see this here! Just yesterday I was reverse engineering Twitter's
JavaScript (to turn off those hideous animations they use now - found an
easier way in the end..) and saw EasyXDM in there and read up about it :-) So,
yeah, Twitter's using it for _something_.

------
Johnyma22
I usually go with the reverse proxying approach.

If I didn't have access to both backends or enough resources to implement a
decent solution I figure I wouldn't have enough resources to be confident in
the security.

------
radagaisus
Two weeks ago we evaluated a bunch of cross domain solutions. The Web Intents
examples didn't even work. Porthole wasn't maintained. EasyXDM was good but
didn't have the flow we wanted. We eventually decided to use socket.io

~~~
jacobolus
You wanted to send messages from one browser window to another within the same
browser (or from one frame to another), so you used socket.io, which
presumably requires a persistent server connection in both windows/frames?
That seems rather silly, tying up not only your server resources but also your
users’ CPU and bandwidth &c., entirely unnecessarily. (Or maybe I’m
misunderstanding your use case..?)

~~~
radagaisus
You got the use case wrong :-) We wanted to continually send information from
third party sites to our site, that's why we picked socket.io. But for our
login flow socket.io felt like on overkill, so I tried to use EasyXDM.

~~~
sciurus
Could you share the approaches you tried for login?

~~~
radagaisus
Sure. Basically the user is on site A and presses a link that opens a pop up
from our site. The pop up logs him in, either through oAuth or a local login.
Then site A should get the user details back.

EasyXDM works with iframes, not with popups, so the only option we had (well,
the one I thought about) was sending a request to the server every few ms to
check if the user logged in. That's pretty horrible. We needed continuous
updates from site A to our site so we decided to use socket.io. Sockets don't
have sessions, so we listen to a random channel name, and pass that channel
name to the popup, which sends the user details as a message to that channel.

That's still complicated. I'm still not sure it's the right approach. And I'm
not an expert. But it works for now.

