ユーザーがログインする方法は複数あり、プラグインを通じてログイン前にユーザーが満たすべき条件を追加するのは困難です。
プラグイン作成者が認証に追加したい条件の例をいくつか挙げます：
- ユーザーのメールアドレスドメインが特定のパターン（例：university.edu）に従っていることを確認
- 2FA プロバイダーからの第 2 要素認証を通過することを確認（2FA プロバイダーは多数存在します）
- 支払いプロバイダーを介してユーザーが有効なサブスクリプションを持っていることを確認
現在の条件は、文脈によってさまざまにチェックされています（またはチェックされていません）。完全なリストではありません：
-
createメソッド経由：正しいパスワード、ユーザー承認済み、ユーザーアクティブ、ユーザーのメールアドレス確認済み、TOTP 第 2 要素認証、ユーザー停止済み、正しい/誤った IP アドレスemail_loginメソッド経由：TOTP 第 2 要素認証、ユーザー承認済み、ユーザー停止済み、正しい/誤った IP アドレス
-
logon_after_password_reset経由：ユーザー承認済み（これは新しいGuardianインスタンスでチェックされる点に注意）、ユーザーがスタッフであること
-
perform_accept_invitation経由：ユーザーアクティブ
カスタム条件を追加する方法の一つとして、各メソッドを変更するカスタムモジュールをプリペンドするという方法がありますが、Discourse との互換性を維持する観点からは望ましくなく、またコードの美観も損なわれます。
提案
認証処理がコードベース全体に分散しているため、それをより一元化すれば開発が容易になります。確認したいすべての条件（およびそれに対するエラーメッセージ）を単一の場所で個別のメソッドとして定義できるようにします。ログインしようとするユーザーは、有効化された各条件を通過する必要があります。プラグイン作成者は、このクラスに独自のメソッドを追加でき、log_on_user メソッドがそれらをチェックします。特定の文脈で条件をスキップしたい場合は、そのためのパラメータを渡すことができます。