Wednesday, November 28th, 2007
CrossFrame: a Safe Communication Mechanism Across Documents and Across Domains
Category: JavaScript, Security
, Yahoo!
Julien Lecomte has written about CrossSafe, a “safe communication mechanism across documents and across domains”.
We already have some solutions such as the URL fragment identifier or the Flash LocalConnection object, so why did Julien see the need for this?
CrossFrame is a variant of the URL fragment identifier mechanism. In the original technique, the containing page sets the URL fragment identifier of an embedded IFrame (usually via its
srcattribute), and the IFrame must poll to detect changes in the value of itslocation.hashproperty. This technique can be further built upon to allow for 2-way communications between an IFrame and its containing page, or between two distinct IFrames.The original URL fragment identifier technique has many limitations, many of which can be worked around except maybe for the following:
- It unnecessarily consumes CPU cycles by requiring the receiver to poll.
- It creates “fake†history entries on Safari and Opera.
How does CrossFrame work?
While CrossFrame also has limitations of its own, I find it to be a much cleaner and simpler approach. Here is how it works:
In order to communicate with the mashup hosted in domain Y, the page, hosted in domain X, dynamically creates a hidden IFrame and points it to a special proxy file hosted in domain Y, using the URL fragment identifier to convey the message (step 1) When the special proxy file is loaded in the hidden IFrame, it reads its URL fragment identifier and passes it to a globally accessible function defined in the IFrame hosting the mashup (step 2) using
parent.frames['mashup']to get to it. The same technique can also be used by the mashup to communicate with the page (the proxy will useparent.parentto get to the page) Finally, when all is said and done, the hidden IFrame is automatically removed from the DOM by the library.
To send and receive messages you use the following JavaScript:
- // To receive messages, subscribe to the onMessage event:
- YAHOO.util.CrossFrame.onMessageEvent.subscribe(
- function (type, args, obj) {
- var message = args[0];
- var domain = args[1];
- // Do something with the incoming message...
- }
- );
- // To send a message, call YAHOO.util.CrossFrame.send():
- YAHOO.util.CrossFrame.send("http://www.y.com/proxy.html",
- "frames['mashup']",
- "message");
Check out the demo, and they read that Julien doesn’t think that ou should use it :)
I assume you meant “CrossFrame” in the first sentence. CrossSafe is the cross site communication solution that uses Subspaces instead of fragment identifier messaging.
I’m not going to say who or what, but it’s puzzling that the author isn’t taking any notice whatsoever that this problem has already been dealt with by xxxx, along with a number of other problems / techniques previously mentioned.
Is it about paying someone something?
Good comment on the “paying someone something” ;)
@Mikael
The problem of cross-domain requests has been solved in many different manners, but the problem of client-side cross-domain messaging has never been solved in a satisfactory way, and this library does not pretend to give a definitive solution either. I hope browser vendors will implement the HTML 5 section pertaining to client-side cross-domain communication very soon, so we can all stop hacking around the problem.
This is similar to what live.com does, though they also incorporate the ability to send large data sets by chunking the data, read receipts, etc.