Il existe plusieurs façons pour un utilisateur d’être connecté, et il est difficile d’ajouter des conditions via un plugin qu’un utilisateur devrait remplir avant de pouvoir se connecter.
Voici quelques exemples de conditions qu’un développeur de plugin pourrait souhaiter ajouter à l’authentification :
- Vérifier que le domaine de l’e-mail de l’utilisateur suit un motif spécifique, par exemple university.edu
- Valider le deuxième facteur auprès d’un fournisseur d’authentification à deux facteurs (il en existe plusieurs)
- S’assurer que l’utilisateur dispose d’un abonnement actif via un fournisseur de paiement
Les conditions actuelles sont vérifiées (ou non) de manière variable selon le contexte (liste non exhaustive) :
-
- via la méthode
create: mot de passe correct, utilisateur approuvé, utilisateur actif, e-mail de l’utilisateur confirmé, deuxième facteur TOTP, utilisateur suspendu, adresse IP correcte/incorrecte - via la méthode
email_login: deuxième facteur TOTP, utilisateur approuvé, utilisateur suspendu, adresse IP correcte/incorrecte
- via la méthode
-
- via
logon_after_password_reset: utilisateur approuvé (remarque : cela est vérifié avec une nouvelle instanceGuardian), utilisateur est membre du personnel
- via
-
- via
perform_accept_invitation: utilisateur actif
- via
Une façon d’insérer une condition personnalisée consiste à préfixer un module personnalisé modifiant chaque méthode, ce qui n’est pas souhaitable du point de vue de la compatibilité avec Discourse et est également peu élégant.
Suggestion
Il serait plus facile de développer autour de l’authentification si celle-ci était moins dispersée dans la base de code. Toutes les conditions (et les messages d’erreur correspondants) que l’on pourrait souhaiter vérifier pourraient être définies comme des méthodes distinctes en un seul endroit. Un utilisateur souhaitant se connecter devrait satisfaire chaque condition activée. En tant que développeur de plugin, vous pourriez ajouter vos propres méthodes à cette classe, que la méthode log_on_user vérifierait ensuite. Si vous souhaitez ignorer une condition dans un contexte particulier, vous pouvez passer un paramètre pour le faire.