Thu Jan 12 2012

Setting up an MVC3 website using built-in membership provider

Oh wait… this is awful. AWRUCHKA. Right dry heaving done with.

It's a good job so few websites want to authenticate users and collect data on them otherwise we'd constantly have to write the same code ove… what's that? Oh my! Everyone is going through this.

Jesus no wonder people bang on about RoR. It makes this easier in comparison

Anyway - I'll forget how to do this before I have to do it again


  • fire up a new MVC3 web application
  • Jump into nuget and Install-Package System.Web.Providers 
  • Sort out a connection string for SQL CE
  • Add a key to make sure the login link always points to LogOn

Now my web.config looks like this (edited out parts I haven't touched for something approximating brevity)

<?xml version="1.0" encoding="utf-8"?>
  For more information on how to configure your ASP.NET application, please visit
    <add name="users" connectionString="Data Source=|DataDirectory|users.sdf;"
    <add key="webpages:Version" value="" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
    <add key="loginUrl" value="~/Account/LogOn" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/LogOn" timeout="2880" />
    <membership defaultProvider="DefaultMembershipProvider">
        <clear />
        <add name="DefaultMembershipProvider" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="users" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" />
    <profile defaultProvider="DefaultProfileProvider">
        <clear />
        <add name="DefaultProfileProvider" type="System.Web.Providers.DefaultProfileProvider, System.Web.Providers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="users" applicationName="/" />
    <roleManager enabled="false" defaultProvider="DefaultRoleProvider">
        <clear />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
        <add name="DefaultRoleProvider" type="System.Web.Providers.DefaultRoleProvider, System.Web.Providers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="users" applicationName="/" />
    <sessionState mode="InProc" customProvider="DefaultSessionProvider">
        <add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" applicationName="/" />

Now start a debug session for the web app. Click logon. Click Register. Fill in the form. Register. Click Logoff and stop the debug session in Visual Studio

You can see the new SQL CE database and have a look at the schema. The Memberships and Users tables have a new row. The new user.

ssms screenshots

ssms screenshots

ssms screenshots

ssms screenshots

Hurrah - all the information you'll ever need is collected.

What?! You want to know more than name and email. Now that's a turn up for the books.

It turns out you can store key-value pairs in the profiles table. I think that anyone that wrote ASP dot Net websites will be old-hand at this but I've never had to do that or this…

While you can do magic up a key-value pair whenever you feel the need to in your code it's probably better to use one of these new fangled Class thing-a-ma-bobs

using System;
using System.Web.Profile;

namespace AcrHack.Models
    public class CustomProfile : ProfileBase
        //magic string
        public static string ADDRESS = "address";

        public string Address
            get { return this[ADDRESS] as String; }
            set { this[ADDRESS] = value; }

Now a quick edit to the web config above so that the providers opening tag becomes

<profile defaultprovider="DefaultProfileProvider" inherits="AcrHack.Models.CustomProfile"/>

which makes the Profile Provider aware of the new Profile class

Next step is to find the RegisterModel (this could be the CreateModel or some other model) and add an Address field

public class RegisterModel
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Display(Name = "Email address")]
    public string Email { get; set; }

    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }

    //Added Address field
    public string Address { get; set; }

and edit the Register method in the controller

public ActionResult Register(RegisterModel model)
    if (ModelState.IsValid)
        // Attempt to register the user
        MembershipCreateStatus createStatus;
        Membership.CreateUser(model.UserName, model.Password, model.Email, null, null, true, null, out createStatus);

        if (createStatus == MembershipCreateStatus.Success)
            FormsAuthentication.SetAuthCookie(model.UserName, false);
            //Changes here
            //Create loads or creates a profile based on searching for username
            var userProfile = ProfileBase.Create(model.UserName) as CustomProfile;
            userProfile.Address = model.Address;
            //End of changes
            return RedirectToAction("Index", "Home");
            ModelState.AddModelError("", ErrorCodeToString(createStatus));

    // If we got this far, something failed, redisplay form
    return View(model);

and finally edit the view to add an editor field for the new property. (I'll leave that as an exercise for the reader)

Now we can go back to the Register page

register page

Register and then have a look in the profile table.

profile table

Ta da!

So there's a mechanism for extending the default profile.

Honestly, it feels messy and since at this point if there's a need for any data access layer then since there'll be a link on user name or user id anyway it's likely a better idea to have the additional data in the DAL and fangle the authentication and user models together in a ViewModel.

Having gone away and checked some code committed on another project by the lovely OrangeTentacle that's what he's done. So having figured it out for myself I'll probably go and crib off that much tidier code

Additional Reading:

Simple.Web.Providers announcement