A More Structured MembershipProvider

If you take a look at the official documentation that tells you how to create your own custom MembershipProvider, you’ll notice that the documentation is mostly about describing:

• How you should throw exceptions and when
• Which events you should invoke and when
• How the logic in each method should work

Let’s stop here for a moment. What are the most typical reasons for creating a custom membership provider? Is it to change the behaviour(/contract) of the provider? Or maybe change the password handling? No. The most common reason is to add support for a custom data source.

Back to the MembershipProvider class. As I see it, it has four responsibilities:

1. Be able to handle all members (login, register, etc.)
2. Load/store information from/in a data source
3. Keep track of account/password policies and handle those
4. Handle passwords (encrypt/hash/compare)

And that’s why it’s such a tedious task to create a custom MembershipProvider: you need to implement all of those responsibilities.

Griffin.MvcContrib to the Rescue!

With MembershipProvider in Griffin.MvcContrib, you do not need to know all of those details. Our MembershipProvider uses DependencyResolver (a built-in Service Locator in MVC3) to lookup the dependencies that it needs. You need to register the following services in your inversion of control container:

IAccountRepository

Used to retrieve/store membership accounts from/to a data source. It’s the only thing you need to implement to get support for a custom data source (like a database or a Web Service).

• Source code

IPasswordStrategy

Used to handle passwords (comparing them, encrypting, decrypting). There are three strategies available in the framework:

• ClearTextStrategy – Store passwords as clear text in the database
• HashedPasswordStrategy – Hash passwords before they are stored
• TripleDesPasswordStrategy – Use TripleDes to encrypt/decrypt passwords

• Source code

IPasswordPolicy

Defines how passwords should be treated. For instance, the minimum length, number of attempts before locking the account, etc.

Two policy implementations exist. One which loads the policies from web.config and a “normal” class which you can create and assign the properties in.

• Source code

How To Use It

Disclaimer: You should know that Account Administration Tools won’t work since the provider has a dependency on DependencyResolver. Other than that, the provider works like any other provider.

Start by modifying your web.config to specify the new provider:

<membership defaultProvider="GriffinMembershipProvider">
    <providers>
      <clear />
      <add name="GriffinMembershipProvider" 

         type="Griffin.MvcContrib.Providers.Membership.MembershipProvider" 

         applicationName="/" />
    </providers>
</membership>

Then you need to register the dependencies in your inversion of control container. Here is a sample for Autofac:

protected void Application_Start()
{
	ContainerBuilder builder = new ContainerBuilder();
	builder.RegisterType<HashPasswordStrategy>().AsImplementedInterfaces();
	builder.RegisterType<RavenDbAccountRepository>().AsImplementedInterfaces();
	builder.RegisterInstance(new PasswordPolicy
		 {
			 IsPasswordQuestionRequired = false,
			 IsPasswordResetEnabled = true,
			 IsPasswordRetrievalEnabled = false,
			 MaxInvalidPasswordAttempts = 5,
			 MinRequiredNonAlphanumericCharacters = 0,
			 PasswordAttemptWindow = 10,
			 PasswordMinimumLength = 6,
			 PasswordStrengthRegularExpression = null
		 }).AsImplementedInterfaces();

	// the rest of the initialization
}

If you like to switch from hashed passwords to encrypted passwords, you just need to register TripleDesStrategy in the container instead. Or implement your own strategy.

The code is available on github.