Introduction
If you are developing using ASP.NET membership and login controls, you will be seeing the above image. This article will discuss how to prevent and/or cure this.
Background
Generally I have seen that when developers use ASP.NET membership provider and login controls, they come across this error. They will complain:
- I have a user in the database and am still not able to login.
- It worked fine on the local machine and when moved to host, it won't let me login.
-
So I will be discussing some points which I have assembled from my own experience as well as from others.
Note: I am assuming here that you are using aspnetdb or used aspnet_regsql.exe to create default membership database. I will try to point out explicitly about custom dataschema.
User Specific Details
Check Password
- Wrong Password: Often people might think they are entering the correct password but they are not. So make sure you are entering the correct password. If you have any doubts about this, create a new test user and write down the password and make sure it is what you are entering when trying to log-in.
- Trim Password: Secondly, sometimes when you are debugging you can see the password you are entering looks the same in code-behind when you debug the
Login1.Password value is correct. But that might not be the case. Suppose you are copy/pasting the password from a file or somewhere, accidentally a space is added while copying it. So Trim the password before feeding it to Membership.Validate method.
Check UserName
- Same rules as the password above.
Check the following in the membership database tables.
aspnet_Users Table
- Check that User exists i.e.
UserName
aspnet_Membership Table
Membership Provider Specific Settings Issues
applicationName Attribute
- Check if
applicationName attribute is set for your membership provider in your web.config.
- If you haven't configured your web.config, then it means your application was using default membership provider settings in machine.config. And
applicationName is already set to ‘/’. So it should not be a problem. Still you can check aspnet_Applications table and see if the application name exists.
Note: Check why should you set this?
passwordFormat Attribute
- There are three settings 0=Clear, 1=Hashed and 2=Encrypted. Compare your web.config and
aspnet_Users table to check if the user was created using the same passwordFormat mentioned in your web.config. There were no changes made in development and production. Because sometimes you might create a user using Clear and then decide to change to Hash.
HashAlgorithmType Attribute
protected void Page_Load(object sender, EventArgs e)
{
Response.Write (Membership.HashAlgorithmType);
}
- Now if you see they are the same not a problem, but if not then how to go about it. If
HashAlgorithmType is not explicitly set in web.config, the membership provider will use it from <machineKey> element’s validation attribute value. Default value for this is SHA1. So you will have to set this explicitly.
<membership hashAlgorithmType="SHA1">
<providers>....</providers>
</membership>
Setting Membership Provider in web.config
- If you are setting custom provider settings in web.config, the bold settings below are to be taken care. Set defaultprovider value. This will be useful when you have more than one provider.
- The
<clear /> will help membership provider not to get confused with any other providers in machine.config or anywhere else.
- Always set the
applicationName attribute.
<membership defaultProvider="AspNetSqlMembershipProvider">
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="LocalSqlServer"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
requiresUniqueEmail="false"
passwordFormat="Hashed" maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="7"
minRequiredNonalphanumericCharacters="1"
passwordAttemptWindow="10" passwordStrengthRegularExpression=""
applicationName="/ " />
</providers>
</membership>
Database Related Settings
Connectionstring
connectionstringName = LocalSqlServer: If you are having the name of your connectionstring as ‘LocalSqlServer’ in your web.config, don't forget to add the remove tag as shown below:
<connectionStrings>
<remove name="LocalSqlServer"/>
<add name="LocalSqlServer" connectionString="....."/>
</connectionStrings>
Note: I would always use a unique name instead of ‘LocalSqlServer” for my connectionstring name. This will automatically clear any confusion. For example:
<connectionStrings>
<clear />
<add name="MembershipProvider" connectionString="....."/>
</connectionStrings>
And then also configure my membership provider as below:
<membership defaultprovider=”..”>
<providers>
<clear/>
<add name="...”
...
...
connectionStringName="MembershipProvider"
</providers>
</membership>
Other Reasons / Checklist / Troubleshooting
Are you using Authenticate event of Login Control
If you are calling Membership.ValidateUser method or any other mechanism to authenticate, don't forget to set e.Authenticate like this as shown below:
protected void Login1_Authenticate(object sender, AuthenticateEventArgs e) {
if (Membership.ValidateUser(Login1.UserName, Login1.Password)) {
e.Authenticated = true; }
else{e.Authenticated = false; }}
OR
Do you have any empty structure for Login Authenticate event
protected void myLogin1_Authenticate(object sender, AuthenticateEventArgs e)
{
}
Ending Notes
This is all from my experiments and articles and other forums about this error. If there are any errors or any good stuff missing, please point it out so others can find the solution in one place. Many thanks to developers whose experiences helped me write this article, especially the community on www.asp.net forums.
Resources
Check out these forums threads and other links which might help you to understand more.
