Welcome!

AJAX & REA Authors: Lee Novak, Alin Irimie, Jonny Defh, RealWire News Distribution, Brandon Watson

Related Topics: Web 2.0, AJAX & REA, Silverlight

Web 2.0: Article

Cross-Domain JSON with Silverlight Avoids crossdomain.xml Restriction

One of Silverlight’s advantages over Flash is the relatively effortless interop with AJAX

Joshua Allen's Blog

One of Silverlight’s advantages over Flash is the relatively effortless interop with AJAX. The other day, I needed to mash up some JSON data from various sites, and found it pretty easy to use AJAX to circumvent the crossdomain.xml restriction.

Both Flash and Silverlight allow you to “mash up” data from other web sites, but only if that site has a crossdomain.xml policy file defined. This sucks if you are calling a service like FriendFeed, who can’t make up their mind.

If you’re doing pure AJAX, you can get around these cross-domain restrictions by using JSON. One of Silverlight’s advantages over Flash is the relatively effortless interop with AJAX. The other day, I needed to mash up some JSON data from various sites, and found it pretty easy to use AJAX to circumvent the crossdomain.xml restriction. In the next month or two, my team will release a simple library to make this generic, but in the meantime here is an explanation for anyone who is blocked:

Step 1: Call into JavaScript from Silverlight, passing the URL of the JSON API:

HtmlPage.Window.Invoke("injectScript", url);

Step 2: The JavaScript Function “injectScript” looks like this:

function injectScript(url) {

var head = document.getElementsByTagName(‘head’)[0];

var script = document.createElement(’script’);

script.type = ‘text/javascript’;

script.src = url;

head.appendChild(script);

};

Step 3: Have the JSON script call back to a function in your page called “callback”:

function callback(obj) {

var silverlight = document.getElementById("silverlight");

 

if (silverlight) {

silverlight.Content.Page.PassData(JSON.stringify(obj));

}

};

Step 4: The callback() JavaScript function passes the data into Silverlight, where it is loaded into a JsonObject:

[ScriptableMember]

public void PassData(string data)

{

JsonObject data = …

}

IMO, this code is cleaner and faster than the standard technique of creating a “WebRequest” from Silverlight. And of course, a WebRequest will fail if the crossdomain.xml is missing.

 

So, is this a security hole? No! All web browsers on the planet allow cross-domain access to JSON, and if JsonObject.Parse had a “url” parameter, we presumably wouldn’t need to check for crossdomain.xml. The current restrictions in Silverlight undoubtedly result from the fact that WebRequest doesn’t know whether its result is intended for Json, XML (which all web browsers restrict by default), or something else.

 

More Stories By Joshua Allen

Joshua Allen, an Evangelist at Microsoft, is also author of the "Better Life Through Software" blog.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Edgar 12/05/08 04:27:12 PM EST

Interesting article. I would like to point out that calling across browser domains will not work in all browsers. Firefox will outright prevent this behavior, and IE will alert the user with a warning. The best way to call into a service that you can't control is to make a call into your server, and then inside you server code forward that call onto the service onto the seperate domain. So the call flow would like something like this:
Silverlight->ASP.NET Server->Service.
Fortunately this is pretty easy to do.

shadedecho 12/05/08 10:09:39 AM EST

Uhh, how exactly is this really at all different from flash and externalinterface?

For instance, flash can easily make calls like:

ExternalInterface.registerCallback("flcallback",handleResponse);
ExternalInterface.call("injectScript", url);

and the flash actionscript response handler:

function handleResponse(str:String):void {
// do something with the string
}

and of course the javascript for "injectScript" is the same.

and the JS callback function:

function callback(obj) {
var fl = document.getElementById("myflash");
if (fl) {
fl.flcallback(JSON.stringify(obj));
}
}

----------------------------
I don't see how this is any functionally different? In fact, some parts of that I think are a bit more sensible than the SL version.

And btw... this is really (IMHO) not a good idea to circumvent appropriate server-side authorization mechanisms. The "crossdomain.xml" is really a powerful tool, and if a web2.0 service provider can't figure out how to publish a sensible one for mashups to use, then it's THEIR fault, not the fault of the security model.