.NET Membership - Part I - What and Why

So with my little CMS client I am building, I have decided to use the .NET Membership functionality that has been a part of .NET since 2.0 (it is also being used in 3.0 in case you were wondering like I was). This isn’t some new fangled javascript library. This is an old workhorse that has been around a while (since 2005) but a lot of developers don’t know much about it. As I worked with it I noticed that it is pretty nice, but it has some funkiness that needs to be worked around. In the end I figured it would be helpful for new and old devs to get the lowdown on this functionality.

So what is Membership? Basically it is MS’s way of getting rid of the tedious stuff that is part of every functional website. Stuff like creating and managing users, logging in and out, user roles, etc. How do they get rid of it? Basically they have built a system of database goodies and server controls that do most of the heavy lifting for you. Notice I said most…

Over the next few days I will go over what it is, why I chose to use it, and how to get it to be useful for your app. Today’s goal is to give you an overview of the functionality and explain how to get it up and running on your site.

Why use this thing anyway?
The simple answer to that is because you don’t want to write all the tedious junk that goes into creating and maintaining users, roles, and logins. Does it do anything you as a developer can’t do? Nope.

Will it save you time? Yeah, it probably will, which is why I ended up using it for my CMS project. If you have a lot of fancy shmancy stuff, then it might we a wash really, but for the standard logins and such, its not a bad way to go.

Another cool thing is it easily works with the ASP.NET Ajax framework. Combined these two things can really do a lot of work for very little effort.

Pieces and Parts
As I mentioned before, the Membership stuff works by combining database goodies with custom server controls. I will get to setting up the database a bit later, but lets first talk about the different server controls. Each of these guys are really customizable in terms of look and feel, so you can get them to fit into your design.

  • Login - This is basically your login tool. Username, password, and even a “remember me” button is all built in.
  • LoginView - This control allows you to build your pages so that logged in visitors see different stuff than the anonymous ones. Furthermore, you also limit what a user sees based on role. Check back tomorrow to see more details about this guy.
  • PasswordRecovery - As you might guess, this control helps users remember their passwords. It sends emails to registered users with their password information.
  • LoginStatus - You know all the sites that say “Welcome Joe” once you log in? This basically does that, or you can set it to point to your login page. If the user is logged in, it provides a nice logout button.
  • LoginName - This is the “Joe” part I talked about above. It lets you display the user’s name.
  • CreateUserWizard - To say this control is a beast is an understatement. Simply put it is a fully customizable wizard that steps users through the process of creating an account. It works, but unless you have some serious user requirements, it may be easier to skip this one.
  • ChangePassword - Helps users change their password

Now a lot of these controls seem a bit silly…I mean a loginname control? The reason they do that is because the MS “marketeers” want to tell everyone that you can create a fully functional site with literally no coding. However, those who can code really can do without several of these. The best of the bunch are the Login, LoginView, and to a certain extent the password controls. Those guys, in my opinion, are worth the price of admission. The others have their uses, but overall just aren’t as necessary.

One really cool thing that you get access to by using the Membership stuff is the Profile object. This guy keeps track of the user as he moves through the app. By default you can get their username, whether they are online or not, the last time they logged in, etc. You can even setup your own custom properties that you want to pay attention to. For instance, want to keep a user out of a specific area of the site until he fills out a specific questionnaire? Just create a custom boolean in the Profile and viola…the problem is solved without ever hitting the database. Nice. I will get into more specifics about the Profile object in future articles.

Looks kinda cool…what does it take to get it working?
From a code perspective there really isn’t a whole lot required. The bear is getting the database ready and connected to the site. Here is how that works.

If you wander over to the .NET framework folder (typically its housed in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) you will see a little doodad called aspnet_regsql.exe. If you run this little guy, a simple GUI comes up and asks you which database you would like to setup (obviously at this point you need to have created your database). It works with both SQL Server 2000, 2005, and the Express versions. Once you push “go” the tool will create a bunch of tables and stored procs for you.

At this point your database is ready to use the controls, but your website isn’t. Time to play with the web.config file. Included in Visual Studio is a tool called “ASP.NET Configuration” that provides a lot of useful functionality. One of those useful pieces is supposed to set up the providers (what connects the site to the database) for you, and in the earliest betas of VS 2005 it actually did, but at some point it got neutered. Because of this, I have learned the hard way that if you want this thing to work correctly, you have to manipulate the web.config manually.

The first thing you need is to setup a connection string under the “configuration” section. It looks something like this:

<connectionStrings>
     <add name="CS" 
     connectionString="server=localhost;database=DB Name;integrated security=true"/>
</connectionStrings>

Once that is in place, mosey on over under the system.web section and add the following:

<roleManager enabled="true" defaultProvider="CustomRP">
  <providers>
    <clear />
    <add name="CustomRP" 
    connectionStringName="CS" 
    applicationName="MyApp" 
    type="System.Web.Security.SqlRoleProvider" />
  </providers>
</roleManager>
<authentication mode="Forms"/>
<membership defaultProvider="CustomMP">
<providers>
   <clear />
   <add name="CustomMP"
   connectionStringName="CS"
   enablePasswordRetrieval="false"
   enablePasswordReset="true"
   requiresQuestionAndAnswer="true"
   applicationName="MyApp"
   requiresUniqueEmail="false"
   passwordFormat="Hashed"
   maxInvalidPasswordAttempts="5"
   minRequiredPasswordLength="7"
   minRequiredNonalphanumericCharacters="1"
   passwordAttemptWindow="10"
   passwordStrengthRegularExpression=""                     
   type="System.Web.Security.SqlMembershipProvider, System.Web, 
   Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>

There are really two sections to this: RoleManager and Membership. The RoleManager is how you tell .Net where to look for the database that houses your roles. The Membership settings tell .NET where to find the Membership database. With Membership, you have a lot of configurable options. The application name, how long your passwords should be, how strict should your passwords be, etc. are particular to your app so pick what is best for you.

Also notice that if you wanted to, you could have separate databases for your RoleManager and Membership. If you are building a monster site that needs to have a server farm, this could be helpful. In the example above both are pointing to “CS”.

If you don’t want to do this at all, you could always use the built in providers that are the standard default. Since I usually like to have only one database, I prefer this way, but your mileage may vary. Since I am using a custom provider for both I use the little command “clear”. This clears out the default settings so I can provide my own.

Once you have your web.config saved, you can use the Visual Studio “ASP.NET Configuration” tool to make any other changes, like adding user roles and such. Your app is now membership approved.

So now you have a site that can utilize all the controls. Tomorrow I will go over some of these controls and other features of the Membership framework. Let me know if there is anything in particular you would like covered.

Leave a Comment

Name: (Required)

E-mail: (Required)

Website:

Comment: