Djangoのカスタムユーザーでの認証と管理画面のカスタマイズ

Djangoでデフォルトの認証モデルではなくカスタムユーザーを使用した認証の実装してみました。デフォルトの管理画面での表示の挙動が思っていたのと異なっていたのでメモ。

前提

Django 4.0.3

初回のマイグレーションまでに行う事

Djangoは初回のマイグレーション実行までに認証モデルをカスタムする必要がある。デフォルトのユーザーモデルからカスタムユーザーモデルへの切り替えはアプリケーションを作り直すより根気の必要な作業になる恐れがあるとのこと。そのためデフォルトから変更する予定がなくても最初からカスタムユーザーモデルで開発することが推奨されている。
次の3ステップを初回マイグレーション前に行う。

1. models.pyにカスタムユーザーのモデルを定義
2. models.pyにカスタムユーザーで定義されたモデルを操作するマネージャークラス
3. setting.pyで認証に使用するユーザーモデルを設定

1. models.pyにカスタムユーザーのモデルを定義

カスタムユーザーは2通りで定義ができる。

AbstractUserクラスを継承する。

デフォルトのユーザーモデルをベースとしたカスタムモデル。必須項目を変更したり、パラメータをを追加できる。追加はできるがベースからあるパラメータは削除することはできない。(first_nameは必要ないためモデルから削除する等はできない。)
デフォルトのモデルをそのまま拡張するだけであるから追加で書くソースが少なくて済む。

models.py

from django.db import models
from django.contrib.auth.models import AbstractUser


class User(AbstractUser):
    phonenumber = models.IntegerField(null=True)
 #パラメータを一つ追加するだけのとき

AbstractBaseUser, PermissionsMixinクラスを継承する。

1.より柔軟にカスタマイズできる。1.のパターンでは出来なかった既存のパラメータの削除ができる。(既存のパラメータに縛られないカスタムユーザークラスを定義可能)
ただし認証機能のみ実装されているだけなのでパラメータ等をすべて定義する必要がある。とはいえほとんど項目を変更しないのであればAbstractUserクラス(~\django\contrib\auth\models.py)をほぼそのまま移植するだけである。以下もほとんど流用である。拡張性を考えて公式ドキュメントではこちらを推奨している。

models.py

from django.db import models
from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin
from django.contrib.auth.validators import UnicodeUsernameValidator
from django.core.mail import send_mail
from django.utils import timezone
from django.utils.translation import gettext_lazy as _


class DiaryUser(AbstractBaseUser, PermissionsMixin):
    class_id = models.IntegerField(null=True, unique=True)
    username_validator = UnicodeUsernameValidator()

    username = models.CharField(
        _("username"),
        max_length=150,
        unique=True,
        help_text=_(
            "Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only."
        ),
        validators=[username_validator],
        error_messages={
            "unique": _("A user with that username already exists."),
        },
    )
    first_name = models.CharField(
        _("first name"), max_length=50, blank=False, null=False)
    last_name = models.CharField(
        _("last name"), max_length=50, blank=False, null=False)
    email = models.EmailField(_("email address"), blank=True)
    is_staff = models.BooleanField(
        _("staff status"),
        default=False,
        help_text=_(
            "Designates whether the user can log into this admin site."),
    )
    is_active = models.BooleanField(
        _("active"),
        default=False,
        help_text=_(
            "Designates whether this user should be treated as active. "
            "Unselect this instead of deleting accounts."
        ),
    )
    date_joined = models.DateTimeField(_("date joined"), default=timezone.now)

    objects = DiaryUserManager()

    EMAIL_FIELD = "email"
    USERNAME_FIELD = "username"
    REQUIRED_FIELDS = ["email"]

    class Meta:
        verbose_name = _("user")
        verbose_name_plural = _("users")

    def clean(self):
        super().clean()
        self.email = self.__class__.objects.normalize_email(self.email)

    def get_full_name(self):
        full_name = "%s %s" % (self.first_name, self.last_name)
        return full_name.strip()

    def get_short_name(self):
        return self.first_name

    def email_user(self, subject, message, from_email=None, **kwargs):
        send_mail(subject, message, from_email, [self.email], **kwargs)

2. models.pyにカスタムユーザーで定義されたモデルを操作するマネージャークラス

マネージャークラスは1で書いたカスタムユーザーを定義するクラスより上に配置してください。BaseUserManagerクラスを継承して定義します。こちらもデフォルトからほぼ変更をしないのであればUserManagerクラス(~\django\contrib\auth\models.py)のソースからほぼ流用して作成できる。

models.py

from django.contrib.auth.models import BaseUserManager


class DiaryUserManager(BaseUserManager):
    use_in_migration = True

    def _create_user(self, username, email, password, **extra_fields):
        if not username:
            raise ValueError('ユーザーネームを入力してください')
        if not email:
            raise ValueError('Emailを入力して下さい')
        email = self.normalize_email(email)
        username = self.model.normalize_username(username)
        user = self.model(username=username, email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self.db)
        return user

    def create_user(self, username, email, password=None, **extra_fields):
        extra_fields.setdefault('is_active', False)
        extra_fields.setdefault('is_staff', False)
        extra_fields.setdefault('is_superuser', False)
        return self._create_user(email, username, password, **extra_fields)

    def create_superuser(self, username, email, **extra_fields):
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_superuser', True)
        extra_fields.setdefault('is_active', True)
        extra_fields.setdefault('first_name','DEFAULT_FIRST_NAME')
        extra_fields.setdefault('last_name','DEFAULT_LAST_NAME')
        if extra_fields.get('is_staff') is not True:
            raise ValueError('is_staff=Trueである必要があります。')
        if extra_fields.get('is_superuser') is not True:
            raise ValueError('is_superuser=Trueである必要があります。')
        return self._create_user(username, email, **extra_fields)

 #ここより下にカスタムユーザーモデル定義クラスを配置　

3. setting.pyで認証に使用するユーザーモデルを設定

認証システムにどのユーザーモデルを使用して認証するかを認識させる。stting.pyの一部を抜粋。

setting.py

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
+   'diaryapp.apps.DiaryappConfig',

]

+AUTH_USER_MODEL = 'diaryapp.DiaryUser'

'diaryapp.apps.DiaryappConfig', についてはアプリ名だけで指定しているサイトも多い。これはアプリ名のみの指定でもDjangoは指定されたアプリ内に存在するapps.pyファイルのAppConfigを継承したクラスを自動で読み取ることができるからである。(AppConfig.defaultがTrueとなっているもののみ。)
上のソースでの表記はより明示的に指定できるため公式ドキュメントではこちらが推奨されている。
AUTH_USER_MODEL = 'diaryapp.DiaryUser'では認証に使用するカスタムユーザーモデルを指定している。

初回のマイグレーションとスーパーユーザーの作成

この辺りは特に通常と異なる手順はない。
(仮想環境名)$ python manage.py makemigrations アプリ名 初回のマイグレーションファイルを作成
(仮想環境名)$　python manage.py migrate マイグレーションファイルの適用
python manage.py createsuperuser　スーパーユーザーの作成

デフォルトの管理画面のカスタマイズ

特にadmin.pyに何も書いていない状態でログインすると次のようにユーザー欄は存在しない。

admin.py

from django.contrib import admin
from .models import DiaryUser

admin.site.register(DiaryUser)

上のソースを追加すると管理画面にユーザー欄が表示され、登録情報の変更が可能。

以下は登録ユーザーの変更画面。ユーザーを追加でも表示項目は同じである。

admin.pyのソースに次のようにUserAdminを継承したクラスを追加する。

admin.py

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import DiaryUser


class DiaryUserAdmin(UserAdmin):
    list_display = ('class_id','username',
                    'last_name', 'first_name', 'is_active', 'last_login')

admin.site.register(DiaryUser, DiaryUserAdmin)

ユーザー一覧画面の表示でユーザー名をクリックしても登録情報の変更ページに飛ばなくなっていた。見づらいがclass_idの‐をクリックすると遷移できる。

また、変更、追加画面の表示がそれぞれ変わる。


これは継承元のUserAdminクラスでフィールが次のように設定されているからである。list_displayと同じようにオーバーライドすればフィールドを変更できる。

~\django\contrib\auth\admin.py

fieldsets = (
        (None, {"fields": ("username", "password")}),
        (_("Personal info"), {"fields": ("first_name", "last_name", "email")}),
        (
            _("Permissions"),
            {
                "fields": (
                    "is_active",
                    "is_staff",
                    "is_superuser",
                    "groups",
                    "user_permissions",
                ),
            },
        ),
        (_("Important dates"), {"fields": ("last_login", "date_joined")}),
    )
    add_fieldsets = (
        (
            None,
            {
                "classes": ("wide",),
                "fields": ("username", "password1", "password2"),
            },
        ),
    )

さらに次のようにlist_displayとlist_display_linksを指定してみる。

admin.py

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import DiaryUser


class DiaryUserAdmin(UserAdmin):
    list_display = ('class_id','username',
                    'last_name', 'first_name', 'is_active', 'last_login') 
    list_display_links = ('first_name',)

admin.site.register(DiaryUser, DiaryUserAdmin)

class_id欄からは変更画面に遷移できず、list_display_linksで指定したfirst_nameから遷移。

この部分は期待していた部分とは異なった動きだっためUserAdminクラスからソースを追うと次のようになっていた。

~\django\contrib\admin\options.py

    def get_list_display_links(self, request, list_display):
        """
        Return a sequence containing the fields to be displayed as links
        on the changelist. The list_display parameter is the list of fields
        returned by get_list_display().
        """
        if (
            self.list_display_links
            or self.list_display_links is None
            or not list_display
        ):
            return self.list_display_links
        else:
            # Use only the first item in list_display as link
            return list(list_display)[:1]

list_display_linksが優先されるが存在しない場合はlist_displayの一番左の要素から変更画面に遷移することが確認できた。