Question

I am working on implementing a custom membership provider that works against an existing schema in my database and have a few thoughts/questions.

The login control will automatically call the ValidateUser method of the membership provider, so no matter how I implement the provider the only thing the login control cares about is the bool value returned by this method. What I am confused about is there could be numerous reasons why a login attempt failed; user is locked out, too many tries in a period of time, etc. There is no way that I see to convey that to the control so it could display the proper message. Other properties of the membership provider such as PasswordStrengthRegularExpression have absolutely no effect on the login control as well (out of the box), I would have hoped that it would automatically somehow translate into regular expression validators, but that doesn’t seem to be the case. So it seems that I need to initialize the login control properties with these settings out of the provider configuration if I want them to take on the control itself.

If the only thing that the Login control does out of the box (without manually handling events and doing the initialization as described above) is call the ValidateUser method on the membership provider, I see no way to convey back to the Login control why the validation failed or even doing things like throttling the validation requests based on a certain time window. Ultimately my question is why would I even use the membership provider then in conjunction with the login control? It seems like it was only designed for a Yes/No type response, which is very restrictive. If I want to build in logic with different messages back to the user I need to handle the login control events and call my own authentication classes that will handle all of my business requirements as well as return a custom error message back to the Login control to display to the user so they know why their attempt is invalid.

Unless I am wrong in my assumptions, it seems that the interface between the Login control as the membership API is too restrictive to be useful. Perhaps the API works better for other auth controls like ChangePassword better but for the actual Login control I don’t see the point.

I appreciate your thoughts.

Answer 1

You are right. To implement the logic you are talking about, you need to implemente the Authenticate event. That way you could write back a custom error message after you do your own validation.

On the other hand I dont think the password strength should be validated on authentication but rather on user creation.

you could write something like this:

protected void Login_Authenticate(object sender, AuthenticateEventArgs e)
{
    try
    {
       e.Authenticated = myMembershipProvider.ValidateUser(LoginControl1.UserName,LoginControl.Password);

    }
    catch(Exception ex)
    {
      LoginControl1.FailrureText = ex.Message;
    }
}

And throw your custom Exception in your ValidateUser method. Happy coding…