Login Control and User Member

Question

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

The login control will automatically output the ValidateUser method of the membership provider, so no matter how I implement the provider, the only thing that monitors login control is the bool value returned by this method. What confuses me may be many reasons why the login attempt failed; user is blocked, too many attempts for a certain period of time, etc. I see no way to pass this to the control so that it can display the correct message. Other membership provider properties, such as PasswordStrengthRegularExpression, have absolutely no effect on login control (out of the box), I would hope that it will automatically convert to regular expression validators in some way, but that doesn't seem to be the case. Therefore, it seems to me that I need to initialize the login control properties with these settings from the provider configuration if I want them to take the control itself.

If the only thing the Login control does out of the box (without manually processing events and initializing, as described above), calls the ValidateUser method of the membership provider, I see no way to return to the Login control why the validation failed or even did something like throttling validation requests based on a specific time window. Ultimately, my question is, why would I even use a membership provider, and then combined with login controls? It seems like it was designed only for a yes / no answer, which is very restrictive. If I want to build logic with different messages back to the user, I need to process the input control events and call my own authentication classes that will handle all my business requirements, and also return a custom error message back to the Login control for the user so that they knew why their attempt was invalid.

If I'm not mistaken in my assumptions, it seems that the interface between the Login control as a membership API is too restrictive to be useful. The API may work better for other out-of-control controls, such as ChangePassword, but for the actual login I don’t see the point.

I appreciate your thoughts.

Answer 1

You're right. To implement the logic you are talking about, you need to implement the Authenticate event. This way you can write your own error message after you do your own check.

On the other hand, I do not think that the strength of the password should be verified during authentication, but rather on the creation of the user.

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 into your ValidateUser method. Happy coding ...

Answer 2

I had the same problem when using the registration method (change password) with the membership provider, where I wanted to get more information, and then just yes / no. Hope you can implement a solution similar to the workaround I came across. See this:

Issue with ChangePassword provider return method type

Answer 3

Okey, if you cannot change the Login-control, you will eventually need a different interface for logging in!