今回のお題
今回はdjangoアプリのallauthというユーザー認証機能に含まれる退会処理という仕様についてまとめます。
基本的には自分用のメモです。
目次
- 退会処理とは
- 退会処理のロジック
- 退会済みになると変わること
- 退会しても変わらないこと
退会処理とは
退会処理はallauthの機能の一つで、他の言語では同様の機能を指して論理削除という言葉が使われていることも多いです。
具体的には、ユーザーを削除する際にデータそのものを完全に消してしまうのではなく、データは残しつつもサービスの利用などの一部の機能が行えない状態にすることを言います。
退会処理を実装するメリットは退会後でもユーザー情報を参照できるようになることですね。
例えば月額制のサービスであれば再加入した際に過去のアカウント情報やポイントなどを引き継げるといったメリットがあります。
反面デメリットとしては個人情報を保持し続けることによるセキュリティリスクと、アプリケーションのロジックが複雑化することですね。
後者に関してですが、例えばユーザー一覧ページを表示する際に物理削除であればUserモデルを全て取得するという処理のみで済んでいたのが、退会処理であればUserモデルからアクティブなレコードのみを全て取得するという処理になり一手間増えることになります。
上記は至極単純な例にしても、ユーザー情報を扱う処理で都度ユーザーの退会状態を考慮することになるので、必然的にロジックは複雑化してしまいます。
退会処理のロジック
djangoアプリのユーザー認証パッケージであるallauthにおいて、退会処理がどのように実現されているのかをまとめておきます。
- allauthが提供するAbstractUserにはデフォルトで
is_activeというフィールドが設定されている（デフォルト値はTrue) - このフィールド値が
Falseに設定されているユーザーに関しては退会扱いとなり、一部の操作が行えなくなる。 - 退会処理後もユーザー情報は保持されているので、管理者画面などから
is_active=Trueに戻すことで再びアカウントとして利用できるようになる。
退会済みになると変わること
退会処理になると変わることは以下の通りです。
- そのユーザーを用いてログインすることができなくなる。また、ユーザー編集画面などで
is_activeフィールドの値をfalseに変更した場合には自動でログアウトされる。 -
ログインしていても特定の処理ができないのではなくログイン自体ができないので、{{ user.username }}などとしてログインユーザーの情報を拾うこともできなくなる。
退会済みになっても変わらない部分
-
User.objects.all()などとしたした場合、戻り値には退会済みのユーザーも含まれる。 - 一意制制約の際には、退会済みのユーザーの情報も参照される（退会済みのユーザーとの重複も許されない）。
終わりに
とりあえず基本的な仕様については以上としておきます。
また必要があれば適宜追加します。