Forms Authentication – Custom Membership Provider Gotchas

Forms Authentication is a very useful feature of the Asp.net framework. Unfortunately, in its default configuration, the requirements for password length and strength, security question, and some of the other options are too strict for most low-end web applications and Intranets.
So, if you are new to this subject and try to find information on the web for how to customize Forms Authentication, you will most certainly come across this very useful post on Scott Guthrie’s blog.Scott explains the importance of the applicationName parameter for custom Membership providers. He explains why the applicationName should be set to “/”, to match the default setting for the application root node. However, if you only define a custom Membership provider in your web.config, then move the database or change the web root, things will fall apart because the applicationName for the default Role provider will be different, resulting in 2 entries in the aspnet_Applications table. Once that happens, and new users and roles are added, there will be duplication going on in the database for each new entry (because role queries and membership queries will use a different application).

The answer is: If you use customer providers, you must always create both, a membership and a role provider, and use the same application name in the web.config:

<roleManager defaultProvider="MyRoleProvider" enabled="true">
 <providers>
  <clear/>
  <add connectionStringName="LocalSqlServer"
       applicationName="/"
       type="System.Web.Security.SqlRoleProvider"
       name="MyRoleProvider"/>
 </providers>
</roleManager>
<membership defaultProvider="MyMembershipProvider">
 <providers>
  <clear/>
  <add connectionStringName="LocalSqlServer"
       applicationName="/"
       minRequiredPasswordLength="5"
       minRequiredNonalphanumericCharacters="0"
       requiresQuestionAndAnswer="false"
       requiresUniqueEmail="false"
       name="MyMembershipProvider"
       type="System.Web.Security.SqlMembershipProvider" />
 </providers>
</membership>

Again, if you do not define both providers, the result is potentially the same as when you use different application names for the membership and the role provider – much confusion in the database.

I tried to comment on Scott’s post, but was unable to register this morning. Microsoft has built an impressive single-signon infrastructure on their community sites that use the Windows Live id, but this does not help when you a served a broken image link for the Captcha :-).