Creating a custom membership provider
When working with an ASP.NET site that requires some sort of user authentication (almost every time, I'd say), we often need to establish our own logic, and use our own database instead of the one provided by ASP.NET (with our own data model or stuff).
There are basically two reasons why you'd want to create a custom membership provider class:
- You wish to store your membership information in a database different from the one ASP.NET provides (which is an SQL Server Express database), like an Oracle or MySQL database or a Web Service.
- You wish to store your membership information in an SQL Server database whose schema (data model) differs from the default one used by the System.Web.Security.SqlMembershipProvider class. An example of this would be if our company already has a shared membership SQL Server database for all applications.
Given this, it's pretty likely you'll have to create your own membership class, and here's one way to do it:
First of all, implement a class that inherits from the abstract class System.Web.Security.MemershipProvider. This class, as well, inherits from another abstract class, System.Configuration.Provider.ProviderBase, so we should implement those methods as well. Basically, what needs to be created is a class with the following definition:
public class MyProvider : MembershipProvider
After that, we need to initialize (implement) the class variables used by the base class, setting each one to the value required by our business logic:
Next, implement all the methods you need, with your own custom logic:
//Minimun password length
private int minRequiredPasswordLength = 6;
//Minium non-alphanumeric char required
private int minRequiredNonAlphanumericCharacters = 0;
//Enable - disable password retrieval
private bool enablePasswordRetrieval = true;
//Enable - disable password reseting
private bool enablePasswordReset = false;
//Require security question and answer (this, for instance, is a functionality which not many people use)
private bool requiresQuestionAndAnswer = true;
private string applicationName = "MYAPP";
//Max number of failed password attempts before the account is blocked, and time to reset that counter
private int maxInvalidPasswordAttempts = 3;
private int passwordAttemptWindow = 10;
//Require email to be unique
private bool requiresUniqueEmail = true;
private MembershipPasswordFormat passwordFormat = new MembershipPasswordFormat();
//Regular expression the password should match (empty for none)
private string passwordStrengthRegularExpression = String.Empty;
If by any chance you decide not to implement any of the base class methods (and not use the base logic, either), just throw a new NotImplemetedException:
public override bool ValidateUser(string username, string password)
//For our example, user will be authenticated if username and password are the same
return username == password;
The final step is to modify our Web.config file:
public override string GetUserNameByEmail(string email)
throw new NotImplementedException();
This is obviously an alternative that requires time and work, but if well implemented, it's sure worth it.
<add type="MyProvider" name="MyProvider">
Revision number 3, Wednesday, May 20, 2009 7:14:05 AM by hugonne
You must Login to comment.
Tue, May 19, 2009 10:21 AM
Need to mention thread safety: In general, ASP.NET goes to great lengths to prevent developers from having to write thread-safe code. HTTP handlers and HTTP modules, for example, are instanced on a per-request (per-thread) basis, so they don't have to be thread-safe unless they access shared state. Providers are an exception to the one-instance-per-thread rule. ASP.NET 2.0 providers are instanced one time during an application's lifetime and are shared among all requests. Because each request is processed on a different thread drawn from a thread pool that serves ASP.NET, providers can (and probably will be) accessed by two or more threads at the same time. This means providers must be thread-safe. Providers containing non-thread-safe code may seem to work at first (and may work just fine under light loads), but are likely to suffer spurious, hard-to-reproduce data-corruption errors when the load-and consequently, the number of concurrently executing request-processing threads-increases. The only provider method that doesn't have to be thread-safe is the Initialize method inherited from ProviderBase. ASP.NET ensures that Initialize is never executed on two or more threads concurrently. See this artical for more: http://msdn.microsoft.com/en-us/library/aa479030.aspx
Fri, Nov 13, 2009 7:42 AM
If you privide little more details, then it will be very much helpful for me.
Thu, Sep 11, 2008 8:48 PM
Overview The CreateUserWizard control provides the user interface for the MembershipProvider object that communicates with the user account data store for your Web site to create new user accounts in the data store. The CreateUserWizard relies on the MembershipProvider
Mon, Feb 4, 2008 8:00 AM
MSDN How To's How To: Create GenericPrincipal Objects with Forms Authentication - This How To shows you how to create and handle GenericPrincipal and FormsIdentity objects when using Forms authentication. How To: Protect Forms Authentication in ASP.NET