• Choose a category
• All
• Classic-Fiction

Validating Users

At this point, we’re ready to write some code that uses the membership API. Let’s start with the most common operation—authenticating credentials. Using the features of the membership subsystem, you can rewrite the code in the login page you saw previously to authenticate a user as follows:

void LogonUser(Object sender, EventArgs e)

{

var user = userName.Text;

var pswd = passWord.Text;

if (Membership.ValidateUser(user, pswd))

FormsAuthentication.RedirectFromLoginPage(user, false);

else

errorMsg.Text = "Sorry, yours seems not to be a valid account.";

}

This code doesn’t look much different from what you would write without providers, but there’s one big difference: the use of the built-in ValidateUser function. Here is the pseudocode of this method as it is implemented in the system.web assembly:

public static Boolean ValidateUser(String username, String password)

{

return Membership.Provider.ValidateUser(username, password);

}

As you can see, all the core functionality that performs the authentication lives in the provider. What’s nice is that the name of the provider is written in the web.config file and can be changed without touching the source code of the application. The overall schema is illustrated in Figure 19-6.

Figure 19-6. Membership using the provider model.

Managing Users and Passwords

The Membership class provides easy-to-use methods for creating and managing user data. For example, to create a new user programmatically, all you do is place a call to the CreateUser method:

Membership.CreateUser(userName, pswd);

To delete a user, you call the DeleteUser method:

Membership.DeleteUser(userName);

You can just as easily get information about a particular user by using the GetUser method. The method takes the user name and returns a MembershipUser object:

var user = Membership.GetUser("DinoE");

Once you’ve got a MembershipUser object, you know all you need to know about a particular user, and you can, for example, programmatically change the password (or other user-specific information). An application commonly needs to execute several operations on passwords, including changing the password, sending a user her password, or resetting the password, possibly with a question/answer challenge protocol. Here is the code that changes the password for a user:

var user = Membership.GetUser("DinoE");

user.ChangePassword(user.GetPassword(), newPswd);

To use the ChangePassword method, you must pass in the old password. In some cases, you might want to allow users to simply reset their password instead of changing it. You do this by using the ResetPassword method:

MembershipUser user = Membership.GetUser("DinoE");

string newPswd = user.ResetPassword();

In this case, the page that calls ResetPassword is also in charge of sending the new password to the user—for example, via e-mail. Both the GetPassword and ResetPassword methods have a second overload that takes a string parameter. If specified, this string represents the answer to the user’s “forgot password” question. The underlying membership provider matches the supplied answer against the stored answers; if a user is identified, the password is reset or returned as appropriate.

Note

It goes without saying that the ability to reset the password, as well as support for the password’s question/answer challenge protocol, is specific to the provider. You should note that not all the functions exposed by the membership API are necessarily implemented by the underlying provider. If the provider does not support a given feature, an exception is thrown if the method is invoked.

The Membership Provider

The beauty of the membership model lies not merely in the extremely compact code you need to write to validate or manage users but also in the fact that the model is abstract and extensible. For example, if you have an existing data store filled with user information, you can integrate it with the membership API without much effort. All you have to do