| Comments

After posting my sample implementation of accessing Amazon Simple Storage Solution (S3) via Silverlight, I reflected quickly and also chatted with some AWS engineers.

Cross-domain Policy

One thing that you should never do is just deploy a global clientaccesspolicy.xml file blindly.  Often times in samples, we (I) do this.  I need to be better about this guidance to be honest, so I’ll start here.  As an example, for the S3 cross domain policy file, we really should add some additional attributes to it to make it more secure.  Since we know it is a SOAP service, we can ratchet down the requests a little bit by adding the http-request-headers restrictions like this:

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <access-policy>
   3:   <cross-domain-access>
   4:     <policy>
   5:       <allow-from http-request-headers="SOAPAction,Content-Type">
   6:         <domain uri="*"/>
   7:       </allow-from>
   8:       <grant-to>
   9:         <resource include-subpaths="true" path="/"/>
  10:       </grant-to>
  11:     </policy>
  12:   </cross-domain-access>
  13: </access-policy>

Additionally (and ideally) we’d be hosting our application from a known domain.  In this instance let’s say I was going to host my application on timheuer.com in the root domain.  I would add the allow from attribute and complete my security like this:

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <access-policy>
   3:   <cross-domain-access>
   4:     <policy>
   5:       <allow-from http-request-headers="SOAPAction,Content-Type">
   6:         <domain uri="http://timheuer.com"/>
   7:       </allow-from>
   8:       <grant-to>
   9:         <resource include-subpaths="true" path="/"/>
  10:       </grant-to>
  11:     </policy>
  12:   </cross-domain-access>
  13: </access-policy>

Of course if I had a cool application and others wanted to embed it, I could add more domains to that allow list as well and just list them in there.  But restricting it makes sense if you want to provide some secure access to your APIs (as a service provider) and to you (in methods of doing things like this sample).

More security with SSL

As I mentioned in the initial sample I changed the binding configuration, modifying the binding to use a security mode of “None” instead of “Transport.”  I actually did this because I use the built-in web server from Visual Studio for most of my development and it doesn’t support HTTPS connectivity.  To demonstrate my sample with S3 I had to ensure the schemes matched because in Silverlight 2 right now to access a secure service, the XAP itself would have to be served from a secure location.  The contexts must match.

I’ve come to learn that even with a bucket alias (except ones with “.” characters) you can use the SSL cert from Amazon S3 as it is a wildcard certificate.  So your endpoint (assuming a bucket name of timheuer-aws) could be https://timheuer-aws.s3.amazonaws.com/soap and it would work.

Using SSL of course means that currently you will have to serve your application from an SSL endpoint as well to avoid cross-scheme violations.

I hope this helps clear some things up and provide you with a more secure and recommended way of accessing Amazon S3 services with Silverlight!

| Comments

I’ve got a thought lately and curious if I’m thinking crazy.  You see, probably the most asked questions I get are around working with services within Silverlight.  Although I’ve got some helpful (at least I think they’re helpful) posts on the subject:

it still seems there are people not quite able to get over some stumbling blocks.  Believe me, I get it.  New stuff can be confusing when it doesn’t work as expected.  So here’s my thought.  Today I helped a colleague that kept emailing back-and-forth about something.  I told him “let’s get on a live meeting and fix it together” – and we did – and he was happy.

As I was doing that I thought…why not do that for everyone?  Of course, the obvious answer is because it couldn’t possibly work in all situations.  I can see one question: "Hey I’ve got my JBOSS service using Fitzer serialization on HP/UX servers with a RPC remote call exposed via standard SOAP – why doesn’t it work?”  Some things just aren’t solvable in this debug session format I’m envisioning.  But things like “I keep getting that friggin 404!” might be.

So what do you think?  I’m thinking that it would be a combination conference call and Live Meeting (as that is the technology I have available to myself—so participants would have to install the client software).  There would be some limits (i.e., amount of people) and you’d have to be willing to share your desktop – what’s the point of a live debugging if you aren’t going to show right?

Another (Chad) suggested that I gather a list of questions and just do a webcast answering those and working through some situations.

Leave a comment here on your thoughts.  Am I crazy?  Would it be too many cooks in the kitchen and not work?  And if you’ve done something similar, what has worked in the past?

| Comments

We were all jumping for joy when Silverlight 2 beta 1 was released and the ability to connect to services was more readily/easily available to us.  For discoverable services that provided a WSDL we were quickly able to implement them using the Add Service Reference capability in Visual Studio 2008.  Beta 2 brings a few changes to the world of services that you should know about.  I’ll do my best to recap some of them here.

Generating a WCF Service

In beta 1 when we created a WCF service for use in Silverlight, we used the “WCF Service” template in Visual Studio (assuming you used Visual Studio).  This was fine and created a standard WCF service for us.  There were a few changes that we had to make to ensure that our Silverlight application could consume it in an acceptable manner.  First, we had to change the binding configuration in ASP.NET web.config from wsHttpBinding to basicHttpBinding as Silverlight only supports that binding type right now.  Secondly, we might have had to add capabilities to enable ASP.NET compatibility support depending on what we were doing with the service.  In beta 2, this process gets a bit simpler for services specifically built for Silverlight.  After you install the tools for Visual Studio, you now get a new item type:

It is important to note that the WCF Service template is still a perfectly acceptable one to choose, you just have to ensure to make those changes accordingly.  The new Silverlight-enabled WCF Service basically does those for us as well as add the ASP.NET compatibility attributes for us in the code.  Additionally, the traditional interface/implementation is simplified into a single class.  Again, the other ways are still valid, but for services specifically built for Silverlight, this might be an easier route to get them done.

Cross-domain policy file updates

Cross-domain restrictions still apply within beta 2 and the same rules apply.  There is one subtle change that is required to your clientaccesspolicy.xml file that is required.  In the allow-from node of the policy file, the attribute http-request-headers is now required.  If your service is an open/public one then specifying “*” is probably acceptable (you’ll have to be the judge of that.  If you only wanted to allow specific headers (besides the blacklisted ones) you can provide those in a comma-separated list and can use wildcards as well.  For example you could use X-MyApp-* if you wanted.

Another thing to note about the support for Adobe’s crossdomain.xml policy file is one thing we found in interpretation of the policy template.  Previously Flash was a Macromedia product and as such that file is adorned with a DOCTYPE that represents a schema with macromedia in it.  Well, Adobe has changed the schema a little bit and also updated the DOCTYPE to reflect Adobe as the authority.  Right now, Silverlight still expects to validate the macromedia declaration.

ServiceReferences.ClientConfig

In beta 1, when you performed the Add Service Reference operation a file named ServiceReferences.ClientConfig was created and had some configuration information in it.  This file, however, wasn’t really used.  In beta 2, this configuration file can be shipped with your XAP and used as configuration.  It provides a subset of WCF configuration.  Refined details of those settings are in the SDK, but I thought it might be helpful to know.

Change to WebClient

In beta 1, WebClient was the easiest library to use in accessing non-discoverable services.  One challenge was that it only supported GET verb requests.  In beta 2 WebClient has changed to enable POST verb actions as well.  the UploadStringAsync function will send the request but the endpoint URI must be a URI that accepts the POST verb.

In addition, WebClient is now callable on a background thread in addition to the UI thread.  This may come in handy for some situations.

I see these as small but helpful changes.  Most are based on feedback we received from beta 1 customers and community, so thank you for that feedback.  I hope this helps!