EasyXDM – crossdomain javascript done right(zemanta.com)
zemanta.com
EasyXDM – crossdomain javascript done right
http://www.zemanta.com/fruitblog/easyxdm-crossdomain-javascript-done-right/
24 comments
For people who prefer code to do the talking you can find the EasyXDM repo here: https://github.com/oyvindkinsey/easyXDM
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
Yeah, but this is no solution if you want to provide a javascript sdk api for external developers to access.
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... )
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... )
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.
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.
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.
Access-Control-Allow-Origin, aka CORS.
http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
This solves all issues but unfortunately is not well supported in the older browsers :(
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.
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.
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-...
It uses postmessage for newer browsers and hash location trick for older browsers.
It uses postmessage for newer browsers and hash location trick for older browsers.
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.
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.
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).
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.
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.
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.
* * *
> 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.
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.
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.
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.
[deleted]
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
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..?)
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.
Could you share the approaches you tried for login?
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.
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.
http://www.whatwg.org/specs/web-apps/current-work/multipage/...