Wednesday, November 28th, 2007

CrossFrame: a Safe Communication Mechanism Across Documents and Across Domains

Category: JavaScript, Security, Yahoo!

<p>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 src attribute), and the IFrame must poll to detect changes in the value of its location.hash property. 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 use parent.parent to 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:

javascript
< view plain text >
  1. // To receive messages, subscribe to the onMessage event:
  2. YAHOO.util.CrossFrame.onMessageEvent.subscribe(
  3.     function (type, args, obj) {
  4.         var message = args[0];
  5.         var domain = args[1];
  6.         // Do something with the incoming message...
  7.     }
  8. );
  9. // To send a message, call YAHOO.util.CrossFrame.send():
  10. YAHOO.util.CrossFrame.send("http://www.y.com/proxy.html",
  11.                            "frames['mashup']",
  12.                            "message");

Check out the demo, and they read that Julien doesn’t think that ou should use it :)

Related Content:

Posted by Dion Almaer at 12:45 am
5 Comments

++++-
4.2 rating from 32 votes

5 Comments »

Comments feed TrackBack URI

I assume you meant “CrossFrame” in the first sentence. CrossSafe is the cross site communication solution that uses Subspaces instead of fragment identifier messaging.

Comment by Kris Zyp — November 28, 2007

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?

Comment by Mikael Bergkvist — November 28, 2007

Good comment on the “paying someone something” ;)

Comment by Jonathan Bond-Caron — November 28, 2007

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

Comment by Julien Lecomte — November 28, 2007

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.

Comment by Steve Roussey — November 28, 2007

Leave a comment

You must be logged in to post a comment.