Come to the dark side...we have cookies!

I recently ran into a problem where the application I was working on didn’t pass the security information as expected to the server. The application in this case is a Silverlight client, with a WebAPI and SignalR backend. For security, we are using WIF…or federated security…I don’t know what to call it anymore. We aren’t really federating it today, but it is based on the same framework…

It has been a while since I was involved in the system, but I got roped back in to solve some issues. And while doing so, I discovered that I wouldn’t get a proper security context for calls made from the client to the server using SignalR. For some reason, those calls where just not being authenticated properly…

Yesterday I was invited to speak in front of a bunch of really sharp guys attending the Lead Enterprise Architecture Program, LEAP, at Microsoft here in Stockholm. The topic of the day was how to share code between projects targeting multiple frameworks/platforms. Basically “how can we share code between projects aimed at WP7, Windows 8, Silverlight and WPF” in a useful way, limiting the duplication of code as well as maintenance.

Most of my presentation revolved around a sample I had written to target all platforms. It is a very simple application, but still shows that it is very possible to get it to work.

When working with Silverlight, we often end up communicating with some form of services. They might be SOAP-based WCF services, which Silverlight handles fine, but lately REST-like services have become a lot more popular, and Silverlight doesn’t always handle them as nicely… They often rely on headers and HTTP verbs other than GET and POST, which Silverlight doesn’t handle very well by default.

In my world, I am currently spending a lot of time working with a Silverlight client that is used in a situation where we use federated security. This requires the client to carry around a token that tells the service who he/she is, and what claims are being made.

In this case, we are using the thinktecture IdentityServer, which after a bit of configuration works very well. It makes it very easy to integrate with using Silverlight, which is nice. All you need to do is do is to make an HTTP GET call to the identity server, passing along the credentials in the form of a basic authentication header. The identity server in turn replies with a token that identifies the client (at least if the credentials are valid). The client can then POST that token to the the service (relying party) who will then use that token to authenticate the client. And after that, everyone is happy, and the service can trust the client being who he/she says he/she is…

There are several “missing” features in Silverlight that people keep bringing up, or keep trying to find solutions for. One of them is the template selector, or DataTemplateSelector class to be more specific.

The DataTemplateSelector has a single responsibility, which is the way it should be. It is responsible for returning a DataTemplate based an object. Generally, it is used in lists, where the data template can be selected based on the bound item, and thus give different templates to different kind of objects in the list.

In Silverlight, this is not possible out of the box, and instead requires us to create multiple UI controls, and hide and show them using data binding. This approach works, but it easily becomes heavy and complicated, which is why I want a template selector that works…

Sorry, for the cryptic title for this post, but it is sort of true, at least when it comes to client access policies. And I didn’t know it until a couple of days ago…

As a part of a project I am working on, we are deploying an STS (Secure Token Service) to handle authentication the users of an OOB Silverlight application. The STS is completely decoupled from the application, as it should be, and is hosted on its own, and the client requests a token from the service through a simple HTTP GET with basic authentication.

There are many ways to expose functionality and data from a server to a client. And there is probably almost as many going the other way… In Microsoft scenarios, using WCF is the obvious choice for most of us, and when people talk WCF, they generally talk SOAP based webservices.

SOAP can however be a less than ideal choice in a some cases. It is way more complicated than some of the other options, and on top of that it has a tendency to bloat the messages being sent, which can be an issue when working with mobile clients for example.

SignalR is a somewhat newish open source project that makes it possible to simulate push notifications on the web. It does so using long-polling (websockets available as an extra download), so it isn’t true push as such, but it gives the appearance of push. And on top of that, it is so ridiculously simple to set up…

Unfortunately, the NuGet package for SignalR doesn’t include the Silverlight client, which the GitHub project does. This is most likely going to be fixed in the near future, but currently you will have to do it the manual way instead of using NuGet.

The server part of SignalR works fine through NuGet, however, it doesn’t play nice with the Silverlight version as a property has been renamed and causes issues. So we have to do the whole thing manually to make sure both the client and server has the modified property… Once again, it is probably going to be fixed some time really soon.

A question I keep running into when I speak about XAML-based application developer is how the developer/designer workflow should work. I don’t know if the question is common in general, or if it is because people feel that I’m not only passionate about coding, but also about design.

I have spent quite a lot of time thinking about how this workflow should work when working with XAML. In other technologies, I believe that the flow is much harder to get going, and I believe it requires more steps. In the “XAML world”, it should be a lot easier. The separation between functionality and design is pretty clear. And this separation should enable quite a well working flow.

Before I get into how I see it, I want to add a disclaimer… I have not been able to try this out in the real world as much as I would have liked. Mainly because I, in most cases, play all the roles. Or at least manage everything from XAML to code, with visuals coming from a designer.

In Silverlight 5, we can use a new feature called “implicit data templates”. An “implicit data template” is a data template that will be used based on the type of the bound object instead of a “manual definition”. That is, we can define data templates and tell them what type they render, and then let the system figure out what template to use as it binds objects.

Ok, after yesterdays less technical post, I guess it is time to get back to writing a real techy post. This time, it is even techy, or geeky, enough to be about Silverlight 5, which currently is still in beta.

This obviously means that we can’t use it, but it doesn’t mean that we can’t have a look at some of the new features and start thinking about how we can upgrade our existing applications as soon as the new version is released…

Custom type providers might sound really obscure, and to be honest, not very interesting. But that’s where you are wrong…