EasyXDM – crossdomain javascript done right
zemanta.com
zemanta.com
http://www.whatwg.org/specs/web-apps/current-work/multipage/...
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... )
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.
It uses postmessage for newer browsers and hash location trick for older browsers.
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.
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
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.
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.
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.