Cross-Domain Post With Silverlight or Why I Hate Hackers

All I wanted was a nifty Silverlight demo of my company’s new .NET package rating API for the commercial print industry.  The main goal of the demo was to provide sample code that developers could look at to understand how easy it is to use.  To keep the sample code simple, I wanted the Silverlight application to call the API directly.  Should have been easy, right?  Well, it wasn’t mainly because the API does an HTTP post to a site in a different domain and Silverlight just doesn’t allow that.

I’m not going to regurgitate the various ways you can get around this limitation.  Just google search on “cross domain post silverlight” if you want technical details.  I settled on a proxy approach, which I implemented grumbling all the way.

Grumbling because it only has to be this annoying because hackers have developed a number of malicious ways to use cross-domain posts to do nasty things.  Again, I’ll spare you the details but you can follow the link if you really want them.  Suffice it to say that because some people find it amusing, profitable or fulfilling to lie, cheat and steal, you have to jump through hoops to post something to an outside domain from Silverlight.  It’s really the same reason I have to waste $20 per month on alarm monitoring for my home.  If a very few people did not suck, we would not have to lock our doors, we would not have to install annoying virus checking software on our computers and we could do cross-domain posts from Silverlight without requiring the domain we are calling to have some magic file that we require.

End rant.

First Impressions of Silverlight

I am in the process of putting together some demos for the shipping API my company has started marketing within the commercial print industry.  I decided to use Silverlight mainly to see if it really makes it easier to deliver a rich UI experience via a web browser on Mac and PC.  If I like it enough, I will probably use it for the administrative interface of our Connect Shipping product.  So far, I am moderately impressed.  Here are some random initial thoughts based on my experience so far:

  • It’s too bad I have to make a Silverlight-specific version of the API DLL.  I know it would be easy to wrap in a web service, but I want the demo app to call the API directly.
  • Creating my Silverlight API DLL is not as bad as I thought it would be thanks to VS 2010 linked files and a couple bits of conditionally compiled code specific to Silverlight.
  • Caliburn Micro is a very nice lightweight open source MVVM library for Silverlight and WPF.  Works on the Windows 7 phone too.  The Soup to Nuts tutorial series is quite helpful.
  • Silverlight is sure sticky about the foreground thread.  You absolutely have to do your work in the background.
  • Too bad I can’t use log4net.  Yes, I know about Clog.
  • Silverlight’s HttpWebRequest only supports asynchronous methods.  I find this sort of annoying.  I realize I need to put this processing in the background, but I think using a BackgroundWorker to wrap a synchronous HttpWebRequest would be much simpler.
  • The Silverlight testing framework is pretty decent as long as you do not try to use it with Chrome.  It has nice support for testing my asynchronous API.  Too bad the asynchronous tests are not at all compatible with standard MSTest.
  • Although the visual designer for XAML in VS 2010 is decent, it is often easier to hand-edit the XAML.
  • Need to display source code with syntax highlighting.  Jeff Wilcox has put together a nice syntax highlighting text block that does what I need.