Controllo dell'accesso e provider di appartenenze personalizzate

Question

Sto lavorando all'implementazione di un provider di appartenenze personalizzato che funziona con uno schema esistente nel mio database e ho alcuni pensieri/domande.

Il controllo di accesso chiamerà automaticamente il metodo ValidateUser del provider di appartenenze, quindi non importa quanto implemento il provider l'unica cosa di cui il controllo di accesso si preoccupa è il valore di bool restituito da questo metodo. Ciò di cui sono confuso è che potrebbero esserci numerosi motivi per cui un tentativo di accesso non è riuscito; l'utente è bloccato, troppi tentativi in ​​un periodo di tempo, ecc. Non vedo in alcun modo che ciò possa essere trasmesso al controllo in modo che possa visualizzare il messaggio corretto. Altre proprietà del provider di appartenenza come PasswordStrengthRegularExpression non hanno assolutamente alcun effetto sul controllo del login (out of the box), avrei sperato che si sarebbe automaticamente tradotto in qualche modo in validatori di espressioni regolari, ma che non sembra essere il Astuccio. Quindi sembra che ho bisogno di inizializzare le proprietà di controllo login con queste impostazioni fuori dalla configurazione del provider se voglio che assumano il controllo stesso.

Se l'unica cosa che il controllo di accesso fa fuori dalla scatola (senza gestire manualmente gli eventi e facendo l'inizializzazione come descritto sopra) è chiamare il metodo ValidateUser sul provider di appartenenze, non vedo alcun modo per tornare al Login controllare perché la convalida non è riuscita o anche fare cose come la limitazione delle richieste di convalida in base a una determinata finestra temporale. In definitiva, la mia domanda è perché dovrei usare il provider di appartenenza anche in combinazione con il controllo di accesso? Sembra che sia stato progettato solo per una risposta di tipo Sì/No, che è molto restrittiva. Se voglio creare una logica con messaggi diversi per l'utente, devo gestire gli eventi di controllo dell'accesso e chiamare le mie classi di autenticazione che gestiranno tutti i miei requisiti aziendali e restituire un messaggio di errore personalizzato al controllo di accesso per visualizzare all'utente in modo che sappiano perché il loro tentativo non è valido.

A meno che non abbia torto nelle mie ipotesi, sembra che l'interfaccia tra il controllo di accesso come API di appartenenza sia troppo restrittiva per essere utile. Forse l'API funziona meglio per altri controlli di autenticazione come ChangePassword, ma per il controllo di accesso effettivo non vedo il punto.

Apprezzo i tuoi pensieri.

Answer 1

hai ragione. Per implementare la logica di cui si sta parlando, è necessario implementare l'evento Authenticate. In questo modo è possibile scrivere un messaggio di errore personalizzato dopo aver effettuato la propria convalida.

D'altra parte non penso che la forza della password debba essere convalidata sull'autenticazione, ma piuttosto sulla creazione dell'utente.

Si potrebbe scrivere qualcosa di simile:

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

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

e buttare il vostro eccezione personalizzata nel metodo ValidateUser. Felice codifica ...

Answer 2

Ho avuto lo stesso tipo di problema nell'utilizzo del metodo di accesso (Cambia password) con il provider di appartenenza, dove in Volevo più informazioni quindi solo un Sì/No. Si spera che sia possibile implementare una soluzione simile alla soluzione alternativa che ho trovato. Vedere questo:

Membership provider ChangePassword method return type problem

Answer 3

Okey, se non riesci a cambiare la cosa del controllo di accesso, alla fine avrai bisogno di un'altra interfaccia di controllo login!