Control de inicio de sesión y proveedor de membresía personalizada

Question

Estoy trabajando en la implementación de un proveedor de membresía personalizado que funciona en contra de un esquema existente en mi base de datos y tengo algunas ideas/preguntas.

El control de acceso llamará automáticamente al método ValidateUser del proveedor de pertenencia, así que no importa cómo implementar el proveedor de la única cosa que el control de acceso le importa es el valor booleano devuelto por este método. Lo que me confunde es que podría haber numerosas razones por las que falló un intento de inicio de sesión; el usuario está bloqueado, hay demasiados intentos en un período de tiempo, etc. No veo la manera de transmitir eso al control para que muestre el mensaje correcto. Otras propiedades del proveedor de membresía como PasswordStrengthRegularExpression no tienen ningún efecto en el control de inicio de sesión (desde el primer momento), esperaba que de alguna manera se tradujera en validadores de expresiones regulares, pero eso no parece ser el caso. Por lo tanto, parece que necesito inicializar las propiedades de control de inicio de sesión con estas configuraciones fuera de la configuración del proveedor si quiero que asuman el control en sí.

Si la única cosa que el control de sesión hace fuera de la caja (sin manipulación manual de eventos y hacer la inicialización como se describe más arriba) es llamar al método ValidateUser en el proveedor de pertenencia, no veo ninguna manera de transmitir de nuevo a la sesión controle por qué falló la validación o incluso haciendo cosas como limitar las solicitudes de validación basadas en una ventana de tiempo determinada. En última instancia, mi pregunta es ¿por qué usaría el proveedor de membresía entonces junto con el control de inicio de sesión? Parece que solo fue diseñado para una respuesta tipo Sí/No, que es muy restrictiva. Si deseo construir lógica con diferentes mensajes para el usuario, necesito manejar los eventos de control de inicio de sesión y llamar a mis propias clases de autenticación que manejarán todos mis requisitos comerciales, así como devolver un mensaje de error personalizado al control de inicio de sesión para mostrar al usuario para que sepa por qué su intento no es válido.

A menos que me equivoque en mis suposiciones, parece que la interfaz entre el control de inicio de sesión como la API de membresía es demasiado restrictiva para ser útil. Tal vez la API funcione mejor para otros controles de autenticación como ChangePassword, pero para el control de inicio de sesión real no veo el punto.

Aprecio tus pensamientos.

Answer 1

tiene usted razón. Para implementar la lógica de la que está hablando, debe implementar el evento Autenticar. De esta forma, podría volver a escribir un mensaje de error personalizado después de hacer su propia validación.

Por otro lado, no creo que la fuerza de la contraseña deba validarse en la autenticación, sino más bien en la creación del usuario.

se podría escribir algo como esto:

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

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

y lanzar excepción personalizada en su método ValidateUser. Feliz codificación ...

Answer 2

Tuve el mismo tipo de problema al utilizar el método de inicio de sesión (Cambiar contraseña) con el Proveedor de Membresía, donde en el que deseaba más información, solo un Sí/No. Con suerte, puede implementar una solución similar a la solución que se me ocurrió. Ver esto:

Membership provider ChangePassword method return type problem

Answer 3

Okey, si no puede cambiar el control de inicio de sesión, en última instancia necesitará otra interfaz de control de inicio de sesión.