Using Fiddler to trick Silverlight into allowing a crossdomain Web Request

If you are trying to make a web request from a Silverlight application the first thing the Silverlight runtime will do is request a security policy file (see Network Security Access Restrictions in Silverlight) from the root of the server you are making your web request to. This happens if you are making your request using the HttpWebRequest or WebClient class. If the Silverlight runtime fails to get a security policy file your web request will fail. If your Silverlight application relies on this web request then you are going to need to contact the server owner and get them to add a security file but until then you can use the Fiddler HTTP Proxy to trick the Silverlight runtime into believing that it does have permission to make the request.

If you want to skip the explanation you can jump straight to the screencast

How Silverlight makes a web request

If you were making a web request from Silverlight to download the following page:

http://www.leggetter.co.uk/2009/10/23/how-i-approach-problem-solving-in-code.html

The Silverlight runtime would first request

http://www.leggetter.co.uk/clientaccesspolicy.xml

If this request fails it will then request

http://www.leggetter.co.uk/crossdomain.xml

If both of these requests fail (return a 404 HTTP status) the Silverlight runtime will not allow you to make your web request. *

* Note: The web request failure due to a failure to download a security policy file can manifest itself in a number of ways. I’ll try to remember to put a post up about this later.

The clientaccesspolicy.xml file is Microsoft’s own security policy file. The crossdomain.xml file is used by Adobe Flash but is also supported by Silverlight. For more information see master-policy file.

Now that we’ve got the background information out of the way we can get on to the interesting stuff.

An example using the Twitter Streaming Feed

If you wanted to write your own Real-Time Rich Internet Application (RTRIA) that consumed data from the Twitter real-time data stream you’d be stuck. Well, you’ll be stuck until Twitter puts a security policy file up **. Until then you can trick the Silverlight runtime by using Fiddler to detect the security policy file request and fake a response.

** The following URLs are where Twitter would put their security policy files should they decide to allow cross domain access. Please not that you’ll be prompted for your Twitter username and password if you click on them by the browser because you need to sign in with valid twitter credentials to access the twitter stream domain: http://stream.twitter.com/clientaccesspolicy.xml and http://stream.twitter.com/crossdomain.xml)

To do this you will need to set up an AutoResponder in Fiddler that intercepts the request for the security policy file by the Silverlight runtime and returns a fake security policy file. In the example below I have an AutoResponder set up for http://stream.twitter.com/crossdomain.xml.

Using Fiddler to AutoRespond with a fake Security Policy File

Here’s an example of a crossdomain.xml security policy file which grants access to requests from all domains.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Once you’ve set up the AutoResponder start Fiddler. Then start your Silverlight application that is trying to stream data from Twitter and bingo! You should have real-time data from Twitter in your RIA – a Real-Time Rich Internet Application (RTRIA).

Fiddler HTTP Proxy Screencast

Related posts:

1. How to make a cross domain web request with SilverLight 2
2. Silverlight uses XCP tmp files for Web Requests
3. Using Fiddler to help develop cross domain capable JavaScript web applications
4. Kwwika Silverlight API – Chat Example
5. Kwwika Silverlight API – Chat Example