Top Linux Links You Must Click On


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.

 

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

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

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.

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.


  Subscribe to our RSS feeds now and receive the next article instantly!
In It? Reprint It! Contact advertising(at)sys-con.com to order your reprints!
ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters