Ci sono diversi modi in cui un utente può effettuare l’accesso, e risulta difficile aggiungere condizioni tramite un plugin che un utente debba soddisfare prima di poter accedere.
Alcuni esempi di condizioni che un autore di plugin potrebbe voler aggiungere all’autenticazione:
- garantire che il dominio email dell’utente segua un determinato pattern, ad esempio university.edu
- verificare il secondo fattore fornito da un provider 2FA (ne sembrano essercene diversi)
- garantire che l’utente abbia un abbonamento attivo tramite un provider di pagamenti
Le condizioni attuali vengono verificate (o non verificate) in modo diverso a seconda del contesto (elenco non esaustivo):
-
- tramite il metodo
create: password corretta, utente approvato, utente attivo, email dell’utente confermata, secondo fattore TOTP, utente sospeso, indirizzo IP corretto/errato - tramite il metodo
email_login: secondo fattore TOTP, utente approvato, utente sospeso, indirizzo IP corretto/errato
- tramite il metodo
-
- tramite
logon_after_password_reset: utente approvato (nota: questo viene verificato con una nuova istanza diGuardian), utente è personale
- tramite
-
- tramite
perform_accept_invitation: utente attivo
- tramite
Un modo per inserire una condizione personalizzata è preporre un modulo personalizzato che modifichi ogni metodo, il che non è un risultato desiderabile dal punto di vista della compatibilità con Discourse e risulta anche piuttosto brutto.
Suggerimento
Sarebbe più semplice sviluppare intorno all’autenticazione se fosse meno distribuita nel codice. Tutte le condizioni (e i messaggi di errore corrispondenti) che si potrebbero voler verificare potrebbero essere definite come metodi separati in un unico punto. Un utente che desidera accedere dovrebbe superare ogni condizione abilitata. Come autore di plugin, potresti aggiungere i tuoi metodi a questa classe, che il metodo log_on_user verificherebbe. Se volessi saltare una condizione in un contesto particolare, potresti passare un parametro per farlo.