Существует несколько способов входа пользователя в систему, и сложно добавить условия через плагин, которые пользователь должен выполнить перед входом.
Вот примеры условий, которые автор плагина может захотеть добавить к процессу аутентификации:
- Проверка того, что домен электронной почты пользователя соответствует определённому шаблону, например university.edu
- Проверка второго фактора от провайдера 2FA (таких провайдеров довольно много)
- Проверка наличия у пользователя активной подписки через платёжного провайдера
Текущие условия проверяются (или не проверяются) в зависимости от контекста (неполный список):
-
- через метод
create: правильный пароль, пользователь одобрен, пользователь активен, подтверждён адрес электронной почты, второй фактор TOTP, пользователь приостановлен, правильный/неправильный IP-адрес - через метод
email_login: второй фактор TOTP, пользователь одобрен, пользователь приостановлен, правильный/неправильный IP-адрес
- через метод
-
- через
logon_after_password_reset: пользователь одобрен (обратите внимание, что это проверяется с новым экземпляромGuardian), пользователь является сотрудником
- через
-
- через
perform_accept_invitation: пользователь активен
- через
Один из способов внедрения пользовательского условия — предварить каждый метод пользовательским модулем, что нежелательно с точки зрения обеспечения совместимости с Discourse и выглядит довольно некрасиво.
Предложение
Разработка вокруг аутентификации была бы проще, если бы она была менее распределена по кодовой базе. Все условия (и соответствующие сообщения об ошибках), которые могут потребоваться для проверки, можно было бы определить как отдельные методы в одном месте. Пользователь, желающий войти в систему, должен был бы пройти каждое включённое условие. Автор плагина мог бы добавлять свои собственные методы в этот класс, которые затем проверялись бы методом log_on_user. Если в определённом контексте нужно пропустить условие, можно передать соответствующий параметр.