If you have spent anytime with Silverlight, you’ve likely run across the cross-site scripting issue.  Essentially, the browser doesn’t let you do web requests from other sites than the one you’re hosted in.   This is to prevent nasty script kiddies from doing nefarious things.

While I hope that Microsoft solves this in the way that Flash does (essentially a white-list that is located on the server that says what sites are ok), I do suggest a workaround: proxy calls offsite through your server.  You can create a simple service on your site that returns data from another site. Then in Silverlight its a matter of making a request up to your own server to get the data and work with it in whatever way you want.

Luckily with .NET 3.5 and WCF’s new REST stack, this is really easy.  For example, here is a simple WCF service using the new WebGet attribute to specify that it can be called like a REST service:

[ServiceContract(Namespace = "")]
[AspNetCompatibilityRequirements(
       RequirementsMode = 
            AspNetCompatibilityRequirementsMode.Allowed)]
public class Service
{
  // Add [WebGet] attribute to use HTTP GET
  [WebGet(ResponseFormat=WebMessageFormat.Xml)]
  [OperationContract]
  public XElement DoWork()
  {
    return XDocument.Load("http://wildermuth.com/rss").Root;
  }
}

The trick here is to add the WebGet attribute to your method.  Note I am specifying that I want XML (JSON is the default) so I can get the data back to Silverlight as XML. As a return type I am specifying XElement (XDocument may make more sense but its not Serializable) so we load a XDocument and just return the root of the document.  Voila, a service you can call from Silverlight to call out to another service.

I could have changed this to accept a parameter with the request to make and I didn’t do this on purpose.  You can imagine if you leave an open relay like that open, you’re inviting script kiddies to do nasty things.

What do you think?