Member Management Prototype Component Beta

Here are my first impressions on the Members and Roles library issued by Microsoft to run on ASP.Net 1.1 and to simulate some of the new features to be found in ASP.NET 2.0.

Download Library Here.
Discuss Here.

(Scott Watermasysk’s Post introduces the component, and Scott On Writing points out some of the reasons I wrote this article (i.e. the lack of Docs) )

Installation

After installing the application you are presented with a directory on your desktop with a word document, a DLL and a directory of SQL scripts. There is also a copy of a sample configuration file.
So I ran the three SQL scripts from within SQL Query Analyser and I had myself a blank database.

I then set up a web application in Visual Studio 2003 and references the DLL. After editing the web.config file I sat back and waited for WebForm1.aspx to load.

It did. Mmmm I though, must be more to this :D

First User

The first time you run any code that actually accesses the database an Application will be created. You can have many applications running off the same SQL server, each with their own users, roles etc.

First I changed the web.config so that it used FormsAuthentication and then set it to deny anonymous users like so:

This redirects the anonymous in user to a page Login.aspx. So I created the page with its usual Username/Password box and Login button.

In the Login code I put the test to see if the user is correct:

if( Membership.ValidateUser(txtUsername.Text, txtPassword.Text) )
{
System.Web.Security.FormsAuthentication.RedirectFromLoginPage(txtUsername.Text, false, “/”);
}

However the login still fails, as there are no users in the database. Everything has to be done either in code, or using the SQL stored procedures. However, as manipulation of the application id is cumbersome I decided to put a bit of cheat code in the page load event.

if( Membership.FindUsersByName(“Sam”).Count == 0 )
{
Membership.CreateUser(“Sam”, “password”, “sam@wackylabs.net”);
}

This created a user if none existed, and I could then log in as that user.

Password Threshold

Then I decided to test the password threshold. This is where you get the password wrong so many times it locks your account. So I tried to add the ‘documented’ parameter into the web.config file, maxInvalidPasswordAttempts. However this isn’t the correct parameter, and caused the app to crash. The correct parameter is passwordAttemptThreshold and should be set in the membership/providers/add section of the web.config file.

Then I realised that if the number of attempts has passed, then the above validation code just fails. I.e. it fails if the user doesn’t exist, and also if the user DOES exist, but is locked out.

To see if the user is logged out after a failed ValidateUser call I added the following code:

MembershipUser user = Membership.GetUser(txtUsername.Text);
if( user != null && user.IsLockedOut )
{
StatusLabel.Text = “You are locked out dude!”;
}

Also note that the above code tells the user they are locked out even if the password is incorrect. If you want to turn on password retrieval then you need to set enablePasswordRetrieval to true and passwordFormat to either “Encrypted” or “Clear”. “Hash” will not work with password retrieval (as it is a one way algorithm). An alternative to turning on password retrieval is to use password reset, which will generate a new password for the user and you can then email them with their new password.

Roles

Roles are accomplished fairly simply. You create them as follows:

Roles.CreateRole(“Role1”);

You then add a role to a user as follows:

Roles.AddUserToRole(user.UserName, “Role1”);

And you can test to see if a user is in a particular role in many ways, one of which is below:

Roles.IsUserInRole(user.UserName, “Role1”);

The above returns true or false if the user is or isn’t in the role. There are also methods for adding many users to one role, many roles to one user and many users to many roles.

Profiles and Profile Properties

Profile properties must first be defined in the web.config file.

As can be seen in the above example 3 profile properties have been declared in the element. The defaultValue parameter is optional.

Then the profile can be created for a user, and its properties retrieved.

ProfileBase profile = ProfileBase.Create(user.UserName);
string a = (string)profile[“ExampleProperty2”];

Given the above properties this will return “b”. To set the property you can do a similar thing:

ProfileBase profile = ProfileBase.Create(user.UserName);
profile[“ExampleProperty2”] = TextBox1.Text;
profile.Save();

The profile needs to be saved to write the changes back to the database.

Conclusion

The code above shows that once the hard work of setting up has been accomplished it is fairly easy to use the default provider with the database. The table structures are fairly self explanatory and you should have no problem linking them into other tables to make a complete application.

With the advent of ASP.NET 2.0 just around the corner, with management tools for most of the above basic configuration, as well as the new Login control which simplifies the whole login process it may be better to just wait for them. However, familiarity with the above framework is only going to be good and the knowledge should carry forward quite easily.

I haven’t looked at developing your own providers for things other than SQL Server database, but it doesn’t look like it would be too hard (having used Reflector to look at some of the code). There are I believe just 3 classes to override, ProfileProvider, RoleProvider and MembershipProvider. Their will be an Active Directory provider included by default in ASP.NET 2.0.

There is also the license issue. The module is issued with a ‘demo only’ license, and cannot be used in production environments, which does make it slightly redundant unless people are really going to start developing ASP.NET 2.0 apps now, in which case why not just use the Whidbey betas?