Existem várias maneiras de um usuário fazer login, e é difícil adicionar condições por meio de um plugin que um usuário possa precisar satisfazer antes de ser autenticado.
Alguns exemplos de condições que um autor de plugin pode desejar adicionar à autenticação:
- garantir que o domínio de e-mail do usuário siga um determinado padrão, por exemplo, universidade.edu
- validar o segundo fator de um provedor de 2FA (parece haver vários)
- garantir que o usuário tenha uma assinatura ativa por meio de um provedor de pagamentos
As condições atuais são verificadas (ou não) de maneiras diversas, dependendo do contexto (lista não exaustiva):
-
- via método
create: senha correta, usuário aprovado, usuário ativo, e-mail do usuário confirmado, segundo fator TOTP, usuário suspenso, endereço IP correto/incorreto - via método
email_login: segundo fator TOTP, usuário aprovado, usuário suspenso, endereço IP correto/incorreto
- via método
-
- via
logon_after_password_reset: usuário aprovado (observe que isso é verificado com uma nova instância deGuardian), usuário é membro da equipe
- via
-
- via
perform_accept_invitation: usuário ativo
- via
Uma maneira de inserir uma condição personalizada é preender um módulo personalizado que modifique cada método, o que não é um resultado desejável do ponto de vista da manutenção da compatibilidade com o Discourse e também é bastante feio.
Sugestão
Seria mais fácil desenvolver em torno da autenticação se ela fosse menos distribuída na base de código. Todas as condições (e mensagens de erro correspondentes) que se deseja verificar poderiam ser definidas como métodos separados em um único local. Um usuário que deseje fazer login precisaria passar por cada condição habilitada. Como autor de plugin, você poderia adicionar seus próprios métodos a essa classe, que o método log_on_user verificaria. Se você desejar ignorar uma condição em algum contexto específico, poderia passar um parâmetro para fazer isso.