One of the great things about the Asp.Net Membership System is that it was designed to snap into many types of enterprise and off-the-shelf applications to provide a consistent model for common tasks such as authenticating users. Several of the database tables (AspNet Users, AspNet Membership and AspNet Roles) include an “ApplicationID” column, which allows for more than one application to utilize a single database. Therefore, it is possible for two different users of two separate applications to have the same username without experiencing a conflict since the combined ApplicationID & UserName would be distinct.
A master table, AspNet Applications, includes a list of the distinct ApplicationID’s which may be in use by the various membership tables. Since this field is a “uniqueidentifier” (GUID), a separate string field called “ApplicationName” is available for looking up the ApplicationID. The following figure illustrates a record in the AspNet Applications table that maps an ApplicationName “/” to the globally unique ApplicationID.
The ApplicationName can be nearly any string (up to 256 characters) and is originally defined, not in the database, but as an attribute of each of the SQL Server providers (AspNetSqlMembershipProvider , AspNetSqlProfileProvider , AspNetSqlRoleProvider.)
The default attributes for each of the AspNet SQL Providers are defined in machine.config, which is generally stored in c:\windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config. This is an important file that should never be modified so Asp.Net lets you override any of its settings by simply placing sections of the file into a web.config file within your web site.
The following is an excerpt from the <system.web> section of machine.config, which defines the System.Web.Security.SqlMembership provider as the default provider for handling membership. Notice that one of its attributes, applicationName, is set to a backslash.
<system.web>
…
<membership>
<providers>
<clear />
<add connectionStringName="LocalSqlServer"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="7"
minRequiredNonalphanumericCharacters="1"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
…
</system.web>
If you wanted to store data for more than one application within a single database or if you desired some control over the applicationName which is used in the AspNet Applications table, you can create a web.config file, in the root folder of your web site, to override the applicationName that is specified in machine.config (shown above.)
The following is an excerpt from web.config. Notice that <clear /> is used to remove any default providers (such as the one in machine.config) from memory and that the applicationName has now been set to something more interesting.
<membership>
<providers>
<clear />
<add connectionStringName="LocalSqlServer" enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
applicationName="myCustomApp"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="7"
minRequiredNonalphanumericCharacters="1"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
Assuming you have already been running the web application, there is likely a pre-existing record in the AspNet Applications table as well as records in the other membership (AspNet Membership, AspNet Users, AspNet Roles) tables that correspond to the ApplicationID for “/”. So guess what happens in the database the first time the application is run after changing the ApplicationName in web.config?
As shown here, a new record, along with a new ApplicationID, has been generated by the provider. All of your existing data including membership, users and roles is still stamped with the original ApplicationID and therefore inaccessible by your provider. This is not a flaw in the system or an oversight on the part of Microsoft. It is simply something you must understand if you intend to modify the applicationName attribute on your provider configuration settings.
Let’s say you have some existing membership records and wish to associate them with the new ApplicationName/ApplicationID. This is very simple to accomplish by issuing the following statements in SQL Server:
UPDATE AspNet Membership SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’
UPDATE AspNet Users SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’
UPDATE AspNet Roles SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’
(Please substitute the appropriate GUID for “new-application-id” and “old-application-id”)
The SQLMembership provider’s foreign-key constraints will prevent you from deleting the original AspNet Applications record for “/” until you have successfully modified the ApplicationID values in each of the membership tables. Assuming that you performed the suggested updates then successfully deleted the record in AspNet Applications for “/”, can you see how a new record, again with a backslash “/” in the ApplicationName field, might be re-created the next time you run the web application?
Other providers, such as the AspNetSqlRoleProvider and the AspNetSqlProfileProvider also define default behaviors in machine.config and therein, the attribute for applicationName is “/” by default. If you use roles or profiles in your web application, be sure to override the default implementation for all three AspNet providers in web.config as appropriate for your solution.