2

ログイン試行の失敗回数を追跡し、それに基づいてアクションを実行するカスタムユーザーモデルがあります。このロジックを書くのに良い場所はどこだろうと思います。

以下は、ユーザーモデルの*failed_attempts*フィールドを更新するために私が念頭に置いている2つのオプションです。

  1. バックエンドでメソッドを認証します。
  2. Userモデルの*check_password*メソッド。AbstractBaseUserモデルからこのメソッドをオーバーライドしました。

そして、基本的なロジック（すべてのケースを網羅しているわけではありません）は次のようになります。

  • 認証が失敗した場合は、前回失敗したログイン試行の時刻を確認してください。
  • それが最近の場合は、失敗したログイン数を増やします。
  • カウントが最大試行に達した場合は、アカウントを数分間ロックします（または何か他のことをします）。

私の質問は、このロジックを作成するためのより良い場所とその理由です。

4

2 に答える 2

1

リストした詳細のみを使用すると、モデルのフィールドを更新すると非常に混乱するという理由だけで、認証方法の方が適切だと思います。check_password

しかし、なぜ「裏付けのある認証メソッド」とcheck_passwordモデルのメソッドの両方があるのでしょうか。

于 2012-12-19T21:28:48.980 に答える
1

内容：実際には、そのロジックを認証バックエンドに実装します。

方法：特定の個別のモデルを使用してログイン試行を追跡するか、miko（fail2ban）によって提案されたソリューションを使用します。

理由：認証をユーザーから切り離します。ボーナス：Djangoの今後のプラグイン可能なモデルを利用したい場合はUser、それは良い考えです。

ちなみに、必要な機能を提供するために既存の認証バックエンドをラップすることで、さらに「より優れた」ソリューションを実現できる方法がおそらくあります。

于 2012-12-20T01:53:19.827 に答える