Implementing OpenId with ASP.Net MVC

January 16, 2009

OpenId is awesome. I first discovered it when I started using OpenId allows users to create a single account that they can use to login to any website that accepts it. All the user has to do is create an account with an OpenId provider (I happen to use The nice thing about this for developers is that it completely offloads all the managing of users, profiles, passwords, authentication, and other headaches associated with developing a site to someone else.

Here is a diagram and an explanation of the sign-in process.

Get a Provider
The first thing you need to do is to setup an account with an OpenId provider. RpxNow has a “Basic” package for free that has everything you need to get started. They also allow users to sign-in using their existing accounts fomr places like Facebook, AOL, Google, and several others. This is awesome if you don’t want your users to deal with the hassles of createing yet another account.

Add a Login Link
Now we need to provide a link to allow the user to sign-in to our site. Add the following code in the <Head> section of your page.

<script src="" type="text/javascript"></script>
<script type="text/javascript">
        RPXNOW.token_url = "";
        RPXNOW.realm = "myRpxAccountName";
        RPXNOW.overlay = true;
// -->

Then add the Login link to your page:

<a class="rpxnow" onclick="return false;" href="">Login</a>

A couple of things to note here. The “myRpxAccountName” is the developer account you get when you register with RpxNow, and the “; link is where the authentication token gets sent (you’ll see this part below). Also, the only thing really needed for the link to work is for it to have a the “rpxnow” class assigned to it.

Setup Controller Action
Once the user logs in through they’re OpenId provider we get an authentication token returned to us. It gets sent to the “; link we specified above. Using the “Default” routing of {controller}/{action}/{id} we can setup our controller like this:

public class AccountController : Controller
     // Matches
     public ActionResult Login(string token)


Get User Information
The most complicated part of the process is sending the token to the Rpx Webservice and getting the user profile information back. The good news is they give us the code to help use get started. I’ve modified the code slightly which you can download at the end of this post.

public ActionResult Login(string token)
     XElement profile = Rpx.GetProfileData(token);

/* Example of returned data.
    <rsp stat="ok">
          <formatted>Micah Martin</formatted>

    //Determine if user is new and if so then create
    //a new record in the database and map the recordId
    //to the openId
       Rpx.Map(openId, userId);

    //Login user
    FormsAuth.SetAuthCookie(username, rememberMe);
    return RedirectToAction("Index", "Home");

Essentially what happens here is we call into the Rpx webservice and get the profile data back. You then determine if the user already exists in the database. If not then create a new record and pass the new record Id along with the OpenId (in my case into the Rpx.Map function. Now all future login requests for the user will contain a <primaryKey> node with recordId of the user. Last thing to do is just call a FormsAuth function to finish the login.

All told it probably took less than 45 minutes to get it implemented. The longest part was understanding the work flow, and even that wasn’t bad. I hope this has been helpful. You can download the Rpx class file Here Rpx. You will need to rename it from .doc to .cs.

kick it on


Model-View-ModelController – My take on MVVM – Introduction

January 9, 2009

I’ve seen a lot of examples from guys like Josh Smith and Karl Shifflett on best practices for using MVVM (Model-View-ViewModel). These are really great examples, but I have yet to find anyone doing real-world development in WPF on a LOB (line of business) application applying these principles.

I’m currently in development on a very large application and I will be writing a series of articles on the structure in which it is built including what I am calling Model-View-ModelController; a cross between MVVM and MVC. They obviously won’t entail any of the business specifics, but I want to demonstrate some of the patterns I am using to both give ideas to anyone struggling with the same issues I have and to also learn more through feedback from the community. Any and all feedback will be much appreciated.

The technologies I will be focusing on are WPF, and Linq-To-Sql. A few of the tenets I will be focusing on are

  • Views Instantiate the ModelControllers, and other Views
  • ModelControllers know NOTHING about the Views
  • ModelControllers instantiate Models and other ModelControllers
  • Models are simply DTO objects and have no knowledge of the existence of anything other than related Models

kick it on

Solution: Styling a large amount of controls

December 11, 2008

I’m really on this “Attached Property” kick. I’m probably totally over using them, but I think it’s such a powerful tool when used in the right scenario. I’m not really sure what the right scenario actually is, but I keep running into situations where to me they just make sense. Also there’s something about adding behavior to objects without actually inheriting from them that gives me a sense that I’m doing something really cool, cutting edge, and adventerous…alright that’s a little ridiculous. Moving on…

So I had posted a question on StackOverflow (by the way this is such an awesome site) and also wrote here about finding the best approach to applying styles to a large amount of controls. I spent an hour or so on the phone with Karl Shifflett discussing the pro’s and con’s of the various approaches to take which I wont re-hash here. I finally landed on this idea that uses my good buddy DependencyProperty.RegisterAttached.

What I’ve done is create 4 styles in a resource dictionary

  1. A style for the containing panel (i.e. Grid, StackPanel, etc.)
  2. A style for the first item(s)
  3. A style for the last items(s)
  4. A style for all the items in between


The reason I create different styles is that depending on where the object is in the panel I may want to apply more or less margin, or to different amounts on different sides. Obviously this is just one particular scenario, but you get the point. Then I set the the attached property on the containing grid like this (can also be a StackPanel/DockPanel):

<Grid local:AttachedProperties.IsStandardContainer="True">

Essentially what the attached property does is iterates through all the children in the Panel and applies one of the specified styles to each element. Care is taken not to override any explicit styles set on any child objects.

Here is a full example including the code for the attached property. Make sure you change the extension from .doc to .zip.

kick it on

CommandBindings in MVVM

December 10, 2008

Anyone who has tried to implement RoutedCommands in WPF using M-V-VM has undoubtedly run into issues. Commands (non-UI commands that is) should be implemented in the ViewModel. For instance if I needed to save a CustomerViewModel then I would implement that as a command directly on my CustomerViewModel. However if I wanted to pop up a window to show the users addresses I would implement a ShowCustomerAddress command directly in the view since this a UI specific function.

The problem lies in the way that RoutedCommands find their associated CommandBindings. In order for a command to be executed it has to have a CommandBinding which tells it how to handle the Executed and CanExecute events. When you associate a control with a command it walks up the logical tree to find the first command binding associated with it. A typical scenario would look like this:

<CommandBinding Command="ApplicationCommands.Save" CanExecute="Save_CanExecute" Executed="Save_Executed" />

<Button Command=”ApplicationCommands.Save” Content=”Save” />

This approach forces us to define the behavior of of the command directly in our view, when really that logic should be in the ViewModel. So how do we get the the View to look for the CommandBindings in the ViewModel instead of the baked in behavior of searching up the logical tree? Well, we can’t. So instead, we need a way to get the CommandBindings out of the ViewModel and into the View. The first thing we need is a CommandBindingCollection property in our ViewModel:

private readonly CommandBindingCollection _CommandBindings;
public CommandBindingCollection CommandBindings
      return _CommandBindings;

Now we create our CommandBindings and add them to the CommandBinding property we created:

public CustomerViewModel(Customer model)
//Create a command binding for the Save command
CommandBinding saveBinding = new CommandBinding(ApplicationCommands.Save, SaveExecuted, SaveCanExecute);

//Register the binding to the class
CommandManager.RegisterClassCommandBinding(typeof(CustomerViewModel), saveBinding);

//Adds the binding to the CommandBindingCollection

Now with a little Attached Property goodness we add the commandbindings of our ViewModel to our View:

public static DependencyProperty RegisterCommandBindingsProperty =  DependencyProperty.RegisterAttached("RegisterCommandBindings", typeof(CommandBindingCollection), typeof(AttachedProperties), new PropertyMetadata(null, OnRegisterCommandBindingChanged));

public static void SetRegisterCommandBindings(UIElement element, CommandBindingCollection value)
if(element != null)
element.SetValue(RegisterCommandBindingsProperty, value);
public static CommandBindingCollection GetRegisterCommandBindings(UIElement element)
return (element != null ? (CommandBindingCollection)element.GetValue(RegisterCommandBindingsProperty) : null);
private static void OnRegisterCommandBindingChanged
(DependencyObject sender, DependencyPropertyChangedEventArgs e)
UIElement element = sender as UIElement;
if (element != null)
CommandBindingCollection bindings = e.NewValue as CommandBindingCollection;
if (bindings != null)

This is how you would use it in the view:

<UserControl local:AttachedProperties.
RegisterCommandBindings="Binding CommandBindings}" >



There are few other examples of how to do this like Josh Smith posted on CodePlex, but I think this is a much more straightforward approach and requires less code. I really hope this helps someone dealing with the same issue. If you think there is a better way, please let me know.


There is a full example that you can download here. Be sure to change the file extension from .doc to .zip.
kick it on

Finding the Best Approach to Styling a LOB App

December 4, 2008

In my LOB apps I usually wind up with containers that contain a bunch of different TextBlocks and TextBoxes for users to enter data. Normally I need to apply a certain margin or vertical/horizontal alignment to each control.

Let’s say I have Grid on my form that looks like this (a lot of markup was eliminated for brevity):

   <TextBlock Text="MyLabel" />
   <TextBox Text={Binding ...}/>
   <!-- Repated a bunch more times along with all of the Grid.Row, 
Grid.Column definitions -->

Now let’s say I need every single item contained in my grid to have Margin=”3,1″ VerticalContentAlignment=”Left” VerticalAlignment=”Center”. There are several ways to achieve this:

  1. Set the properties directly on each control – BAD!! Does not allow for skinning or centralizing styles.
  2. Create a Style with an x:Key=”MyStyleName” and apply the style to each control. Better…Makes centralizing styles and skinning more manageable but still requires a ton of markup, and can become unwieldy.
  3. Create a global style (i.e. don’t specify an x:Key and set the TargetType={x:Type TextBox/TextBlock} – BAD!! The problem with this is that it affects ALL controls in the app that don’t explicity override this style. This can be bad for things like menus, grids, and other controls that use textblocks and textboxes.
  4. Create a style that targets the Grid and explicitely sets the dependecy propety values like <Setter Property="Frameworkelement.Margin" Value="3,1" /> Not bad…it correctly applies the style to every element in it’s content, but also applies it directly to the Grid itself…not exactly what I want.

So what approach do you take and why? What works the best?

kick it on

HeaderFormatString and ContentFormatString

November 17, 2008

I started exploring both HeaderFormatString and ContentFormatString and ran into a little weirdness.

First thing to note is this:

If you set the HeaderTemplate or HeaderTemplateSelector property of a HeaderedContentControl, the HeaderStringFormat property is ignored. MSDN

There are quite a few gotchas like this in WPF to watch out for.

Second thing to note is that these properties aren’t the same as doing this:
HeaderedContentControl and HeaderStringFormat are used specifically for classes that implement IFormattable. HederStringFormat formats the header, and ContentStringFormat formats the content. The value of either property is the format that gets passed to your classes implementation if IFormattable.ToString. You can read the full example on MSDN. But here is the gist of how to make it work.


This TabItem will now display “This is my formatted string” in the header, and the content will be “this is my non-formatted string”.


There a couple things to keep in mind. Typically these properties would be used in the context of an ItemsControl. The HeaderStringFormat would not be bound in this way, and instead will have the default binding provided by the ItemContainer of the HeaderedItemsControl. For instance if you set the ItemsSource property of the TabItem, then it will automatically wire up the header and the content binding for you, and all you have to do is supply the formatting value you want.

Last, but not least, I was able to get everything working properly with a GroupBox and TabItem, but not so much luck with an expander and I’m not sure why. The expander handles the ContentStringFormat properly, but not the HeaderContentStringFormat. This is suprising considering that the both inherit from HeaderContentControl…

kick it on

Consolidating XAML Namespaces

October 9, 2008

I’m working on a project that has numerous namespaces. Each time I need to use a class in XAML I have to add a new namespace declaration to the XAML file. This quickly becomes unwieldy when you start using multiple namespaces like this:


Then of course you have to figure out what namespace each item is in order to use in XAML.

An easy way around this is to consolidate all of the namespaces at the assembly level using the XmlnsDefinitionAttribute from the System.Windows.Markup namespace. In the AssemblyInfo.cs (or .vb) you add this attribute for each namespace you want to consolidate like this:



There is an optional parameter you can pass in that specifies which assemblies the namespaces live in. This allows you to consolidate namespaces across multiple assemblies.

Now back to our XAML, we can blow out all of these namespace declarations for a much simpler, cleaner approach:


kick it on