Rediscovering the Obvious

One of the ongoing struggles with Silverlight development involves the crossdomain.xml and clientaccesspolicy.xml security files. They are there for a very good reason, and shouldn’t be circumvented in violation of the website owners’ licenses.

Now, however, I have a different sort of problem. The final application is going to be hosted on the same server as the (HTTP Get-based) web service, and thus I don’t need any sort of crossdomain files… in production. Unfortunately, I do need them for development because Silverlight will be running from my local machine and will see the services as remote. How do I deal with this? I don’t have access to the root folder on the server, only the area where my content will be stored. I don’t want to have to publish for every round of UI testing as a tweak and evolve my services. Mocks will only get me so far in ensuring end-to-end capability, and I need to test the fiddly bits of the API and parsing code against the real data.

After quite a bit of fruitless searching for proxy servers, intercepts, etc, I remembered that Fiddler2 actually has a pretty strong rules engine. A bit of browsing in their cookbook page and I realized how easy it would be. Insert the following into the rules file (Hit Ctrl-R to edit) and now I can access the services via Silverlight from my computer without hurting the overall security of the application on either the client or server, nor do I have to write a custom proxy. All I have to do is fire up Fiddler when I want to run and test.

if (oSession.url=="some.domain.com/clientaccesspolicy.xml")
{
    oSession.url = "localhost/clientaccesspolicy.xml";
}