Django認証：二つの道の探求

はじめに

Web開発の世界では、ユーザー認証はほとんどのアプリケーションにとって譲れない機能です。シンプルなブログから複雑なeコマ Lauracommerceプラットフォームまで、ユーザーアクセス、ロール、プロフィールを安全に管理することは最優先事項です。Djangoは、「締め切りを守る完璧主義者のためのWebフレームワーク」として、すぐに利用できる非常に堅牢で柔軟な認証システムを提供しています。しかし、アプリケーションが複雑化し、独自の要件が出現するにつれて、開発者はしばしば重要な決断に直面します。Djangoの組み込みUserモデルを使い続けるべきか、それとも必要に応じてカスタムユーザーモデルの領域に踏み出すべきか？この記事では、両アプローチのニュアンスを掘り下げ、Djangoアプリケーションの設計時に情報に基づいた意思決定を行うための包括的なガイドを提供します。

Django認証のコアコンセプト

比較分析に入る前に、Djangoの認証システムに関わるコアコンポーネントについて共通の理解を確立しましょう。

• Userモデル: アプリケーションの個々のユーザーを表す中心的な要素です。資格情報（ユーザー名やパスワードハッシュなど）と基本的な識別情報を格納します。
• 認証バックエンド: 実際の認証プロセス（例：データベースに対してユーザー名とパスワードを検証する）を処理するクラスです。Djangoには、Userモデルに対して認証を行うデフォルトのバックエンドが付属しています。
• AUTH_USER_MODEL設定: アプリケーションのユーザーモデルとしてどのモデルを使用するかを指定する重要なDjango設定です。デフォルトでは auth.User に設定されています。
• 権限とグループ: Djangoの認証システムは認可にも拡張され、「投稿を編集できる」などの権限を定義したり、ユーザーをロール（例：「エディター」）にグループ化してアクセス制御を管理したりできます。

それでは、Djangoでユーザーを管理するための2つの主要なパスを探ってみましょう。

Djangoの組み込み認証システム

Djangoのデフォルトユーザーモデル django.contrib.auth.models.User は、ほとんどのDjangoプロジェクトで事前に構成されている強力で十分にテストされたソリューションです。その即時利用可能性と包括的な機能セットにより、多く のアプリケーションにとって最良の出発点となることがよくあります。

機能と利点

• すぐに利用可能: セットアップ不要。スーパーユーザーを作成して認証を開始するだけです。
• 堅牢で安全: 長年のコミュニティレビュー、バグ修正、セキュリティ強化の恩恵を受けています。パスワードハッシュ、ソルト、セッション管理などを処理します。
• 管理インターフェースとの統合: Django管理インターフェースとシームレスに統合され、管理者は最小限の労力でユーザーとグループを管理できます。
• 包括的な機能: username、password、email、first_name、last_name、is_staff、is_active、is_superuser、last_login、date_joined のフィールドが含まれています。
• パスワードリセット機能: Djangoは、パスワードリセットを処理するための組み込みビューとフォームを提供しており、ゼロから正しく安全に実装するのは複雑です。

いつ使用するか

組み込み User モデルは、次のような場合に最適です。

• ほとんどの標準的なWebアプリケーション: ユーザー要件がデフォルトで提供されるフィールドと一致する場合。
• 迅速なプロトタイピング: 認証システムを迅速にセットアップできます。
• ユーザープロフィールが最小限のアプリケーション: 追加のユーザーデータが User モデルへの1対1の関係（例：UserProfile モデル）を介して処理される場合。

例：組み込みユーザーの使用

Post を作成者に関連付けたいとします。組み込み User モデルを使用すると、簡単です。

# myapp/models.py
from django.db import models
from django.contrib.auth.models import User # 組み込みUserをインポート

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    author = models.ForeignKey(User, on_delete=models.CASCADE) # 直接の外部キー
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

# Djangoビューまたはシェルでの使用例：
# from django.contrib.auth.models import User
# from myapp.models import Post
# 
# user = User.objects.create_user(username='john_doe', password='securepassword')
# post = Post.objects.create(title='My First Post', content='Hello, world!', author=user)

カスタムユーザーモデル

組み込み User モデルは強力ですが、常にすべての要件に適合するとは限りません。多くの場合、アプリケーションにはより具体的なユーザー関連データ（例：phone_number、date_of_birth、user_type、avatar）が必要になります。または、異なる認証識別子（例：ユーザー名ではなくメールアドレス）を好む場合もあります。ここでカスタムユーザーモデルが輝きます。Djangoは、AbstractUser または AbstractBaseUser を継承することで、ユーザーモデルをカスタマイズするための2つの主な方法を提供します。

AbstractUser

AbstractUser は AbstractBaseUser をサブクラス化し、username、email、first_name、last_name、is_staff、is_active、is_superuser、last_login、date_joined など、すべてのデフォルトフィールドを含む User モデルの完全な実装を提供します。必要な追加フィールド、メソッド、またはマネージャーを追加できます。これは、Djangoの標準ユーザーフィールドを維持したい場合、ほとんどのカスタムユーザーモデルにとって推奨されるアプローチです。

AbstractBaseUser

AbstractBaseUser は、パスワードハッシュとトークン化されたパスワードリセットを含むユーザーモデルのコア実装を提供します。それ以外のフィールドは含まれていません。これを使用する場合、ユーザーモデルを識別する方法（例：username の代わりに email）を含む、ユーザーモデルに必要なすべてのフィールドを定義する必要があります。また、REQUIRED_FIELDS と USERNAME_FIELD を定義する必要があります。このアプローチは最大の柔軟性を提供しますが、より多くの作業も必要とします。

カスタムユーザーモデルの使用時期

• ユニークなユーザーフィールドの追加: アプリケーションに組み込み User モデルに存在しない追加のユーザー属性（例：phone_number、date_of_birth、company_id）が必要な場合。
• 認証識別子の変更: ユーザー名ではなくメールアドレスでユーザーがログインできるようにしたい場合。
• コアユーザー動作の変更: ユーザーの管理、作成、または識別方法を大幅にカスタマイズする必要がある場合。
• 1対1のプロフィールモデルの回避: 組み込み User にリンクされた UserProfile モデルを作成する代わりに、すべてのユーザーデータをカスタムユーザーモデルに直接配置できます。

例：AbstractUser の拡張

メールで認証し、phone_number フィールドを含むカスタムユーザーモデルを作成してみましょう。

# myapp/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    # 追加フィールドをここに追加
    phone_number = models.CharField(max_length=15, blank=True, null=True)
    # emailはAbstractUserからすでに提供されていますが、USERNAME_FIELDにしたいです
    # emailも一意にしたいです
    email = models.EmailField(unique=True) 

    # emailフィールドを認証に使用するようにDjangoに指示します
    USERNAME_FIELD = 'email'
    # REQUIRED_FIELDSは、createsuperuser via を介してユーザーを作成する際にプロンプトされます
    # これらのフィールドは、USERNAME_FIELDとパスワードに加えて存在する必要があります
    # USERNAME_FIELDまたはpasswordをここにリストしないように注意してください
    REQUIRED_FIELDS = ['username'] # usernameも収集したいです

    def __str__(self):
        return self.email

# settings.pyでは、カスタムユーザーモデルを指定する必要があります：
# AUTH_USER_MODEL = 'myapp.CustomUser'

重要事項: AUTH_USER_MODEL 設定は、プロジェクトの最初のマイグレーション（つまり、python manage.py migrate を実行する前）に設定する必要があります。デフォルトの auth.User でマイグレーションを実行した後でカスタムユーザーモデルに切り替えることにした場合は、これは大幅に複雑なプロセスであり、通常は慎重なデータマイグレーションまたは再開が必要です。そのため、プロジェクトのライフサイクルの早い段階でユーザーモデルを決定することが非常に重要です。

例：AbstractBaseUser の拡張

これは、完全な制御が必要で、ユーザーモデルをほぼゼロから構築したい場合のアプローチです。

# myapp/models.py
from django.contrib.auth.models import AbstractBaseUser, PermissionsMixin, BaseUserManager
from django.db import models
from django.utils import timezone

class CustomUserManager(BaseUserManager):
    def create_user(self, email, password=None, **extra_fields):
        if not email:
            raise ValueError('The Email field must be set')
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_superuser(self, email, password=None, **extra_fields):
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_superuser', True)
        extra_fields.setdefault('is_active', True)

        if extra_fields.get('is_staff') is not True:
            raise ValueError('Superuser must have is_staff=True.')
        if extra_fields.get('is_superuser') is not True:
            raise ValueError('Superuser must have is_superuser=True.')
        return self.create_user(email, password, **extra_fields)

class MinimalUser(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(unique=True)
    first_name = models.CharField(max_length=30, blank=True)
    last_name = models.CharField(max_length=30, blank=True)
    is_active = models.BooleanField(default=True)
    is_staff = models.BooleanField(default=False)
    date_joined = models.DateTimeField(default=timezone.now)

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['first_name', 'last_name']

    objects = CustomUserManager()

    def __str__(self):
        return self.email
    
    def get_full_name(self):
        return f"{self.first_name} {self.last_name}".strip()

    def get_short_name(self):
        return self.first_name

# settings.pyにて：
# AUTH_USER_MODEL = 'myapp.MinimalUser'

この MinimalUser の例では、次のことを行う必要がありました。

1. すべての基本的なフィールド（email、first_name、last_name、is_active、is_staff、date_joined）を定義しました。
2. is_superuser、groups、user_permissions フィールドを取得するために PermissionsMixin を継承しました。
3. USERNAME_FIELD を 'email' として定義しました。
4. REQUIRED_FIELDS を createsuperuser 用に定義しました。
5. ユーザーとスーパーユーザーの作成、およびメールの正規化を処理するカスタム UserManager （CustomUserManager）を作成しました。

ご覧のとおり、これにはかなりのボイラープレートが必要ですが、ユーザーモデルのスキーマと作成プロセスを完全に制御できます。

ユーザーモデル間の移行

初期マイグレーション後に AUTH_USER_MODEL を変更することが、単純な作業ではないことを強調することが極めて重要です。組み込み User で開始し、後でカスタムユーザーが必要になったと判断した場合、大きな課題に直面します。通常、次のことを行う必要があります。

1. カスタムユーザーモデルを作成します。
2. 古い auth.User テーブルから新しいカスタムユーザーモデルテーブルにデータを移行するためのマイグレーションファイルを​​手動で作成します。
3. auth.User を指していたすべての外部キーを AUTH_USER_MODEL を指すように慎重に更新します。
4. すべての参照が更新されたことを確認したら、auth アプリのすべてのマイグレーションと、場合によっては auth_user テーブル自体を削除します。

このプロセスは、細心の注意を払って実行されない場合、エラーやデータ損失が発生しやすくなります。したがって、最初の makemigrations および migrate コマンドを実行する前に、プロジェクトの開始時にユーザーモデルを決定することを常に推奨します。

結論

Djangoの組み込み User モデルとカスタムユーザーモデルの両方が、それぞれ独自の利点とユースケースを持つ、認証のための堅牢なソリューションを提供します。組み込みモデルは、標準的なユーザー要件を持つアプリケーションにとって、安全で効率的で、すぐに利用できるオプションであり、迅速な開発と堅牢なセキュリティをすぐに提供します。アプリケーションでユニークなユーザー属性、カスタム認証識別子（メールベースのログインなど）、またはより詳細なユーザー管理制御が必要な場合は、カスタムユーザーモデル（理想的には AbstractUser を拡張する）の実装が優れた選択肢となります。この決定は、理想的にはプロジェクトの開始時に下され、ユーザー管理システムの柔軟性とスケーラビリティを決定します。最終的に、正しい選択は、ユーザーのニーズを完全に満たす安全で適応性の高いDjangoアプリケーションを構築できるようにします。