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:
https://www.leggetter.co.uk/2009/10/23/how-i-approach-problem-solving-in-code.html
The Silverlight runtime would first request
https://www.leggetter.co.uk/clientaccesspolicy.xml
If this request fails it will then request
https://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.
[caption id="attachment_426" align="alignnone" width="300" caption="Using Fiddler to AutoRespond with a fake Security Policy File"]
[/caption]
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).
