Solving Cross Domain Issues with Silverlight 2

We all know that Silverlight and Flash follow a similar security model and run in the browser sandbox. These RIA platforms essentially request a cross domain policy file when a request is sent from the RIA application to a web service. If the policy file is not present or does not list your domain as an allowed domain, then you have these choices:

• Call, write, and ask the company/person to list your domain (i.e., the domain from which your Silverlight application is downloaded) as an allowed domain in the client policy file (clientaccesspolicy.xml or crossdomain.xml) – may not be very reasonable.
• Create your own proxy – the proxy will sit on your domain, and will make calls to the external domain. Hence, your Silverlight app will call the proxy on the same domain, so the Silverlight runtime will avoid asking for the cross domain policy file. Your proxy will simply call the external service and pass the response back to the Silverlight application.
• Use a third party proxy service instead of rolling your own – such as Yahoo Pipes @ http://pipes.yahoo.com/pipes or the Google AJAX Feed API @ http://code.google.com/apis/ajaxfeeds.
• Trick the browser and avoid using any proxy whatsoever. This only works if the Silverlight application can access the HTML Bridge and inject a JavaScript element into the head tag of the page. Also, you need to understand how to pass the response into a Silverlight control. If you don’t know how this can be accomplished, then this approach will not work for you. This is the option I will discuss further, since the other ones are self explanatory.

I am not sure if I would recommend using such an approach because it feels like a hack, but it does indeed work. This approach may not work at all, if, for example, you are loading your Silverlight application XAP file from a different domain than the web page that is hosting the Silverlight content. I am not sure if the Silverlight control will be able to modify the head HTML element of the host page.

Here is the most important snippet of code you need in order to implement this trick:

HtmlElement head = HtmlPage.Document.GetElementsByTagName("head")[0] as HtmlElement;
HtmlElement javascriptContent = HtmlPage.Document.CreateElement("script"); 
javascriptContent.SetProperty("type", "text/javascript"); 
javascriptContent .SetProperty("src", "http://aWebServiceSomeWhere"); 
head.AppendChild(javascriptContent);

Do you see the trick? The browser’s JavaScript engine will say, “oh, look, we have a new script element that has been added to the header, and it has a URL as the src property – I need to download and then execute that JavaScript!” Since the request is made from the browser’s DOM and has no relevance to any RIA technology, all outbound requests will succeed and no cross domain policy file is requested. After the JavaScript is returned, it is necessary to pass the results back to the Silverlight control. Clearly, the only reasonable way to do it is to force the JavaScript to contain a method call into your Silverlight control. For instance, Twitter allows you to specify a callback=YourJavascriptFunction in the request, and the resulting JavaScript returned from the Twitter service will contain YourJavascriptFunction in the response.

Bryant Likes wrote a Silverlight Twitter control that demonstrates using this trick and a fall-back mechanism that uses Yahoo Pipes. Have a look @ http://blogs.sqlxml.org/bryantlikes/archive/2009/01/23/twilight-a-silverlight-twitter-badge.aspx and http://www.codeplex.com/Twilight.

By the way, I am currently using Bryant’s excellent Silverlight Twitter badge on my blog.