Django の認証方法のカスタマイズ¶

認証バックエンドを指定する¶

内部的に、Django は認証を確認する「認証バックエンド」のリストを保持しています。django.contrib.auth.authenticate() を誰かがコールすると -- どのようにログインするか で記述されているように -- Django はその認証バックエンド全てに対して認証を試行します。最初の認証方法が失敗した場合、Django は次の方法、また次の方法といった具合に、全てのバックエンドに対して認証を試行します。

認証バックエンドとして利用するリストは AUTHENTICATION_BACKENDS に定義されています。この設定値は認証方法を定義している Python クラスを指定する Python パスのリスト型変数でなければなりません。これらのクラスはあなたの環境で有効な Python パスのどこにでも配置可能です。

初期状態では、AUTHENTICATION_BACKENDS は以下の値として定義されています。:

["django.contrib.auth.backends.ModelBackend"]

これは Django のユーザーデータベースを確認してビルトインの権限を照会する基本的な認証バックエンドです。このバックエンドにはログイン試行を制限することでブルートフォース攻撃を防御する仕組みは提供していません。独自に試行制限を実装した認証バックエンドを利用するか、多くのウェブサーバーで提供されている各種防御機構が利用可能です。

AUTHENTICATION_BACKENDS への順番は処理に影響し、同じユーザー名とパスワードによって複数のバックエンドで有効な認証と判定されれば、Django は最初に有効と判定した時点で処理を終了します。

ある認証バックエンドにおいて PermissionDenied 例外が発生した場合、認証処理は直ちに終了し、Django は続く認証バックエンドに対する認証判定を行いません。

認証バックエンドの実装¶

認証バックエンドは2つの必須メソッド: get_user(user_id) と authenticate(request, **credentials) を持ったクラスであり、 また、パーミッションに関連した省略可能な authorization methods を持ちます。

get_user` メソッドは user_id -- ユーザー名、データベース上の ID 等、何でも利用できますが、あなたが定義したユーザーオブジェクトの主キーである値 -- を取って一つのユーザーオブジェクト、または``None``を返却します。

authenticate メソッドは request 引数と credentials キーワード引数を取ります。殆どの場合、これは次のようになります。

from django.contrib.auth.backends import BaseBackend


class MyBackend(BaseBackend):
    def authenticate(self, request, username=None, password=None):
        # Check the username/password and return a user.
        ...

一方、次のように認証トークンでも表せます。

from django.contrib.auth.backends import BaseBackend


class MyBackend(BaseBackend):
    def authenticate(self, request, token=None):
        # Check the token and return a user.
        ...

いずれの場合にせよ、 authenticate() は与えられた認証情報を確認し、それが有効であれば、認証情報とマッチしたユーザーオブジェクトを返すべきです。それが有効でなければ None を返すべきです。

request は HttpRequest で、 authenticate() が提供されていない場合は None となる可能性があります (バックエンドでこれを通過するため)。

Django の admin は Django の User object と強く結合しています。これを扱う最も良い方法は Django の User オブジェクトを、あなたのバックエンド（例えば、LDAP ディレクトリ、外部の SQL データベースなど）に存在するそれぞれのユーザーに対して作成することです。これを行うためのスクリプトを事前に記述しておくか、ユーザーが初めてログインするときに authenticate メソッドがこれを行えるようにしておくと良いでしょう。

次に示すのが、 settings.py で定義されたユーザー名とパスワードの変数に対して認証し、ユーザーの認証が初めてであった場合に Django の User オブジェクトを作成するバックエンドの例です。

from django.conf import settings
from django.contrib.auth.backends import BaseBackend
from django.contrib.auth.hashers import check_password
from django.contrib.auth.models import User


class SettingsBackend(BaseBackend):
    """
    Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.

    Use the login name and a hash of the password. For example:

    ADMIN_LOGIN = 'admin'
    ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='
    """

    def authenticate(self, request, username=None, password=None):
        login_valid = settings.ADMIN_LOGIN == username
        pwd_valid = check_password(password, settings.ADMIN_PASSWORD)
        if login_valid and pwd_valid:
            try:
                user = User.objects.get(username=username)
            except User.DoesNotExist:
                # Create a new user. There's no need to set a password
                # because only the password from settings.py is checked.
                user = User(username=username)
                user.is_staff = True
                user.is_superuser = True
                user.save()
            return user
        return None

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

カスタムバックエンドによる認可の扱い¶

カスタム認証バックエンドはそれら独自のパーミッションを提供することができます。

ユーザーモデルとそのマネージャは、ルックアップ関数を実装している認証バックエンドが何であっても、ルックアップ関数 (get_user_permissions()、get_group_permissions()、get_all_permissions()、has_perm()、has_module_perms()、with_perm()) に権限を移譲します。

これによりユーザーに与えられたパーミッションは全てのバックエンドが返すすべてのパーミッションの上位セットになります。つまり、Django はユーザーに、任意のバックエンドが付与するパーミッションを与えます。

もし例外 PermissionDenied を has_perm() か has_module_perms() の中でバックエンドが出した場合、認可は直ちに失敗し、 Django はそこから続くバックエンドを確認しません。

バックエンドは、魔法のような admin のパーミッションを次のように実装できます。

from django.contrib.auth.backends import BaseBackend


class MagicAdminBackend(BaseBackend):
    def has_perm(self, user_obj, perm, obj=None):
        return user_obj.username == settings.ADMIN_LOGIN

上記の例では、アクセスしたユーザーに全てのパーミッションを付与します。注意すべき点として、関数 django.contrib.auth.models.User  から関連して得られた同じ引数は、バックエンド認証関数は、匿名のユーザーを表すものも含んでいるかもしれない、全てのユーザーオブジェクトを引数として取る点があります。

認可の実装の完全なものは django/contrib/auth/backends.py の ModelBackend クラスにあり、これはデフォルトのバックエンドであり、ほとんどの場合 auth_permission テーブルを照会します。

プロジェクトの開始時にカスタムのユーザーモデルを使用する¶

新しくプロジェクトを始める場合は、デフォルトの User で十分である場合でも、カスタムユーザーモデルを作成することを強く推奨します。このモデルはデフォルトのユーザーモデルと同様に動作しますが、必要に応じて将来的にカスタマイズすることができます:

from django.contrib.auth.models import AbstractUser


class User(AbstractUser):
    pass

AUTH_USER_MODEL に指定することを忘れないでください。任意のマイグレーションの作成、また、最初に実行する manage.py migrate の前に行ってください。

そして、モデルをアプリの admin.py に登録してください:

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

admin.site.register(User, UserAdmin)

プロジェクト途中からのカスタムユーザーモデルへの変更¶

AUTH_USER_MODEL をデータベーステーブルの作成後に変更することは、たとえば、外部キーや多対多の関係に影響するため、非常に困難となります。

この変更は自動的には行うことができません。手動でのスキーマ修正、古いユーザーテーブルからのデータ移動、一部のマイグレーションの手動による再適用をする必要があります。ステップの概要は #25313 を参照してください。

スワップ可能なモデルという Django の動的依存性により、 AUTH_USER_MODEL によって参照されるモデルはアプリの初回のマイグレーションで作成されなければなりません（通常は 0001_initial と呼ばれます）。そうしない場合、依存関係の問題が発生します。

マイグレーション中に CircularDependencyError に遭遇するかもしれません。依存関係の動的な性質のため、Django は依存関係のループを自動的に断ち切ることができないためです。もしこのエラーを見た場合、ユーザーモデルが依存しているモデルを2回目のマイグレーションに移動することで、依存関係のループがなくなるようにしてください。(お互いに ForeignKey を持つ2つの通常のモデルを作ることで、makemigrations が循環依存関係を通常と同じように解決させることもできます。)

再利用可能なアプリと AUTH_USER_MODEL¶

再利用可能アプリはカスタムのユーザーモデルを実装するべきではありません。多数のアプリを使用するプロジェクトの場合、それぞれカスタムのユーザーモデルを実装した再利用可能アプリが2つあると、同時に使うことができなくなってしまいます。もしユーザー情報をアプリ度とに保存したい場合は、以下のように settings.AUTH_USER_MODEL に対して ForeignKey または OneToOneField を使用してください。

User モデルを参照する¶

User を直接参照する場合 (例えば外部キーで参照する場合)、AUTH_USER_MODEL 設定が異なるユーザモデルに変更されたプロジェクトでは正しく動作しません。

get_user_model()¶

User を直接参照する代わりに、django.contrib.auth.get_user_model() を使ってユーザモデルを参照すべきです。このメソッドは現在アクティブなユーザモデルを返します -- 指定されている場合はカスタムのユーザモデル、指定されていない場合は User です。

ユーザモデルに対して外部キーや多対多の関係を定義するときは、AUTH_USER_MODEL 設定を使ってカスタムのモデルを指定してください。例えば:

from django.conf import settings
from django.db import models


class Article(models.Model):
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.CASCADE,
    )

ユーザモデルによって送信されたシグナルと接続するときは、AUTH_USER_MODEL 設定を使ってカスタムのユーザモデルを指定してください。例えば:

from django.conf import settings
from django.db.models.signals import post_save


def post_save_receiver(sender, instance, created, **kwargs):
    pass


post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)

一般的に言って、最も簡単な方法は、インポート時に実行されるコードの中で AUTH_USER_MODEL 設定を用いてユーザーモデルを参照することです。しかし、Django がモデルをインポートするときに get_user_model() を呼ぶという方法もあります。こうすると、models.ForeignKey(get_user_model(), ...) という表記が可能です。

たとえば、@override_settings(AUTH_USER_MODEL=...) などを使用して、アプリが複数のユーザーモデルでテストされていて、get_user_model() の結果をモジュールレベルの変数にキャッシュしている場合、setting_changed シグナルを listen してキャッシュをクリアする必要があるかもしれません。そのためには、次のように書きます。

from django.apps import apps
from django.contrib.auth import get_user_model
from django.core.signals import setting_changed
from django.dispatch import receiver


@receiver(setting_changed)
def user_model_swapped(*, setting, **kwargs):
    if setting == "AUTH_USER_MODEL":
        apps.clear_cache()
        from myapp import some_module

        some_module.UserModel = get_user_model()

カスタムのユーザーモデルを指定する¶

プロジェクトの開始時にカスタムのユーザーモデルを使おうとしている場合、自分のプロジェクトにとってこの選択は本当に正しいのだろうか、と立ち止まってよく考えてください。

ユーザーに関連するすべての情報を1つのモデルに記録すれば、関連モデルを取得するために、追加のより複雑なデータベースクエリを書く必要がなくなります。しかし一方で、アプリ固有のユーザー情報は、カスタムのユーザーモデルに関連するモデルに記録した方がより適切かもしれません。そうすることにより、各アプリは、他のアプリと競合したりデータを破壊されたりする可能性を考えずに、自分のアプリに必要なユーザーデータのみを指定することができます。また、ユーザーモデルを、認証に焦点を絞った、可能な限りシンプルなものに保ち続けられるようになります。それはまた、Django がカスタムのユーザーモデルに期待する最小限の要求を満たすことにもなります。

デフォルトの認証バックエンドを使用している場合、モデルは必ず、認証のために使用できるユニークなフィールドを1つ持たなければなりません。このフィールドとしては、ユーザー名やメールアドレスなど、ユニークな属性ならば使用できます。ユニークでないユーザー名などのフィールドが使用できるのは、そのようなフィールドを扱えるカスタムの認証バックエンドだけです。

準拠したカスタムユーザーモデルを構築する最も簡単な方法は、AbstractBaseUser を継承することです。AbstractBaseUser はユーザーモデルのコアとなる実装を提供しており、その中には、ハッシュ化パスワードやトークン化されたパスワードリセットなどの機能が含まれます。このクラスの継承後、以下のように、キー実装の詳細を自分で記述する必要があります。

class models.CustomUser¶

USERNAME_FIELD¶

ユニークな ID として使用される、ユーザーモデルのフィールド名を説明する文字列。これは通常、ある種のユーザー名になりますが、メールアドレスや他のユニークな ID にすることもできます。非ユニークなユーザー名をサポートできるカスタムの認証バックエンドを使っていない限り、このフィールドは*必ず*ユニークである (たとえば、unique=True を定義内で設定する) 必要があります。

以下の例では、フィールドを一意に指定するために、identifier フィールドが使われています。

class MyUser(AbstractBaseUser):
    identifier = models.CharField(max_length=40, unique=True)
    ...
    USERNAME_FIELD = "identifier"

EMAIL_FIELD¶

ユーザーモデルにあるメールのフィールド名を文字列で記述します。この値は get_email_field_name() で返されます。

REQUIRED_FIELDS¶

createsuperuser 管理コマンド経由でユーザーを作成するときにプロンプトが表示されるフィールド名のリスト。ユーザーはこれらの各フィールドごとに値を入力するようにプロンプトが表示されます。blank が False または未定義のフィールドを含む必要があり、ユーザーが対話的に作成されるときにプロンプトを表示したい追加のフィールドを含むことができます。REQUIRED_FIELDS は、たとえば admin 上のユーザーの作成などの Django の他の部分では何も効果がありません。

たとえば、これは誕生日と身長の2つの必須フィールドを定義しているユーザーモデルの部分的な定義です。

class MyUser(AbstractBaseUser):
    ...
    date_of_birth = models.DateField()
    height = models.FloatField()
    ...
    REQUIRED_FIELDS = ["date_of_birth", "height"]

注釈

REQUIRED_FIELDS はユーザーモデルのすべての必須フィールドを含む必要がありますが、USERNAME_FIELD や password を含んでは*いけません*。これらのフィールドは常に入力を求められるためです。

is_active¶

ユーザーが "active" かどうかを示すブール属性。この属性は、デフォルトが True の AbstractBaseUser 上の属性として与えられます。実装時にどのような選択をするかは、選択した認証バックエンドの詳細によって変わります。詳細については、ビルトインのユーザーモデル上の is_active のドキュメントを読んでください。

get_full_name()¶

オプション。フルネームなどのユーザーに対するより長い正式の ID です。実装した場合、django.contrib.admin のオブジェクト履歴内でユーザー名とともに表示されます。

get_short_name()¶

オプション。ファーストネームなどのユーザーに対するより短い正式ではない ID です。実装した場合、django.contrib.admin のヘッダー内のユーザーへの挨拶内でユーザー名の代わりに使われます。

AbstractBaseUser のインポート

AbstractBaseUser と BaseUserManager は django.contrib.auth.base_user からインポートでき、 INSTALLED_APPS の中に django.contrib.auth をインクルードすることなくインポートできます。

次の属性とメソッドは AbstractBaseUser: の任意のサブクラスで利用可能です。

class models.AbstractBaseUser¶

get_username()¶

USERNAME_FIELD で指定されたフィールドの値を返します。

clean()¶

normalize_username() を呼び出し、username を正規化します。このメソッドをオーバーライドした場合、正規化を保持するために super() を呼び出すようにしてください。

classmethod get_email_field_name()¶

EMAIL_FIELD 属性で指定されたメールフィールドの名前を返します。EMAIL_FIELD の指定が無いとき、デフォルトは 'email' です。

classmethod normalize_username(username)¶

視覚的に同一であるが異なる Unicode の符号位置を持つ文字について、それらが同一とみなされるように、username に NFKC Unicode正規化を適用します。

is_authenticated¶

(AnonymousUser.is_authenticated が常に False なのとは対照的に) 常に True の読み取り専用属性です。ユーザが認証済みかどうかを知らせる方法です。これはパーミッションという意味ではなく、ユーザーがアクティブかどうか、また有効なセッションがあるかどうかをチェックするわけでもありません。 通常、request.user のこの属性をチェックして AuthenticationMiddleware (現在ログイン中のユーザを表します) によって格納されているかどうかを調べます。User のインスタンスの場合、この属性は True となります。

is_anonymous¶

常に False の読み取り専用属性です。User オブジェクトと AnonymousUser オブジェクトを区別する方法です。一般的に、is_authenticated を使う方が好ましいと言えます。

set_password(raw_password)¶

指定された生の文字列に、ユーザのパスワードをセットし、パスワードのハッシュ処理を行います。AbstractBaseUser は保存しません。

raw_password が None のとき、set_unusable_password() が使われるのと同じように、パスワードは使用に適さないパスワードになります。

check_password(raw_password)¶

与えられた生の文字列が、ユーザに対して正しいパスワードであれば True を返します。 (比較する際にはパスワードハッシュを処理します。)

set_unusable_password()¶

ユーザにパスワードが設定されていないものとしてマークします。これは、空の文字列のパスワードを設定することとは違います。このユーザに対する check_password() は True を返しません。AbstractBaseUser オブジェクトを保存しません。

アプリケーションの認証が LDAP ディレクトリなどの既存の外部ソースに対して行われている場合は、これが必要になることがあります。

has_usable_password()¶

ユーザに対して set_unusable_password() が呼ばれている場合、False を返します。

get_session_auth_hash()¶

パスワードフィールドの HAMC を返します。Session invalidation on password change のために利用されます。

get_session_auth_fallback_hash()¶

New in Django 4.1.8.

SECRET_KEY_FALLBACKS を使用しているパスワードフィールドの HMAC を yield します。get_user() で使用されます。

AbstractUser は AbstractBaseUser をサブクラス化します。

class models.AbstractUser¶

clean()¶

BaseUserManager.normalize_email() を呼び出し、メールを正規化します。このメソッドをオーバーライドした場合、正規化を保持するために必ず super() を呼び出すようにしてください。

カスタムユーザーモデルのためのマネージャーを書く¶

You should also define a custom manager for your user model. If your user model defines username, email, is_staff, is_active, is_superuser, last_login, and date_joined fields the same as Django's default user, you can install Django's UserManager; however, if your user model defines different fields, you'll need to define a custom manager that extends BaseUserManager providing two additional methods:

class models.CustomUserManager¶

create_user(username_field, password=None, **other_fields)¶

The prototype of create_user() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_user should be defined as:

def create_user(self, email, date_of_birth, password=None):
    # create user here
    ...

create_superuser(username_field, password=None, **other_fields)¶

The prototype of create_superuser() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_superuser should be defined as:

def create_superuser(self, email, date_of_birth, password=None):
    # create superuser here
    ...

For a ForeignKey in USERNAME_FIELD or REQUIRED_FIELDS, these methods receive the value of the to_field (the primary_key by default) of an existing instance.

BaseUserManager provides the following utility methods:

class models.BaseUserManager¶

classmethod normalize_email(email)¶

Normalizes email addresses by lowercasing the domain portion of the email address.

get_by_natural_key(username)¶

Retrieves a user instance using the contents of the field nominated by USERNAME_FIELD.

make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')¶

バージョン 4.2 で非推奨.

Returns a random password with the given length and given string of allowed characters. Note that the default value of allowed_chars doesn't contain letters that can cause user confusion, including:

• i, l, I と 1 (小文字の i、小文字の L、大文字の i、そして数字の 1)
• o, O と 0 (小文字の o、大文字の o、そして数字の 0)

Django 標準の User を拡張する¶

Django の User モデルに完全に満足しているものの、追加のプロフィール情報をいくつか追加したい場合、django.contrib.auth.models.AbstractUser をサブクラス化して、カスタムのプロフィールフィールドを追加することも可能ですが、カスタムのユーザーモデルを指定する で説明されているように、独立したモデルを作ることをおすすめします。AbstractUser は、デフォルトの User の完全な実装を:ref:`抽象モデル <abstract-base-classes>`として提供します。

カスタムのユーザーとビルトインの認証フォーム¶

Django のビルトインの forms と views は、協調して動作するユーザーモデルに対して、いくつかの前提を置いています。

以下のフォームは AbstractBaseUser のあらゆるサブクラスに互換性があります。

• AuthenticationForm: USERNAME_FIELD で指定したユーザー名フィールドを使用する。
• SetPasswordForm
• PasswordChangeForm
• AdminPasswordChangeForm

以下のフォームは、ユーザーモデルについて以下のようないくつか前提を置いています。これらの前提を満たしている場合、同じユーザーモデルとみなして使用することができます。

• PasswordResetForm: Assumes that the user model has a field that stores the user's email address with the name returned by get_email_field_name() (email by default) that can be used to identify the user and a boolean field named is_active to prevent password resets for inactive users.

最後に、以下のフォームは、User と固く結びついているため、カスタムのユーザーモデルとともに使用するには、書き換えや拡張が必要になります。

• UserCreationForm
• UserChangeForm

If your custom user model is a subclass of AbstractUser, then you can extend these forms in this manner:

from django.contrib.auth.forms import UserCreationForm
from myapp.models import CustomUser


class CustomUserCreationForm(UserCreationForm):
    class Meta(UserCreationForm.Meta):
        model = CustomUser
        fields = UserCreationForm.Meta.fields + ("custom_field",)

カスタムのユーザーと django.contrib.admin¶

カスタムのユーザーモデルを admin で動作させたい場合、ユーザーモデルにいくつかの追加の属性とメソッドを定義しなければなりません。これらのメソッドを定義することで、admin はユーザーへアクセスを制御して admin のコンテンツに合わせることができます。

class models.CustomUser

is_staff¶

ユーザーが admin サイトへのアクセス権を持っている時、True を返します。

is_active¶

ユーザーアカウントが現在アクティブな時、True を返します。

has_perm(perm, obj=None):

ユーザーが名前付きの権限を持っている時、True を返します。obj が提供された場合、特定のオブジェクトのインスタンスに対して権限をチェックする必要があります。

has_module_perms(app_label):

ユーザーが与えられたアプリ内のモデルへのアクセス権を持っている場合、True を返します。

また、カスタムユーザークラスを admin に登録する必要もあります。もしカスタムユーザーモデルが django.contrib.auth.models.AbstractUser を継承したものである場合、Django の既存の django.contrib.auth.admin.UserAdmin クラスがそのまま利用できます。しかし、ユーザーモデルが AbstractBaseUser を継承したものである場合には、カスタムの ModelAdmin クラスを定義する必要があります。デフォルトの django.contrib.auth.admin.UserAdmin をサブクラス化することも可能ですが、その場合には django.contrib.auth.models.AbstractUser 上のフィールドを参照する定義のうち、カスタムユーザークラス上にはない定義をすべてオーバーライドする必要があるでしょう。

from django.contrib.auth.admin import UserAdmin


class CustomUserAdmin(UserAdmin):
    ...
    fieldsets = UserAdmin.fieldsets + ((None, {"fields": ["custom_field"]}),)
    add_fieldsets = UserAdmin.add_fieldsets + ((None, {"fields": ["custom_field"]}),)

カスタムのユーザーとパーミッション¶

Django のパーミッションフレームワークをカスタムのユーザーモデルに簡単に取り入れられるように用意されているのが、Django の PermissionsMixin です。これはユーザーモデルの階層に取り入れることができる抽象モデルで、Django のパーミッションモデルをサポートするのに必要なすべてのメソッドとデーターベースのフィールドを使えるようにしてくれます。

PermissionsMixin は、以下のメソッドと属性を提供します。

class models.PermissionsMixin¶

is_superuser¶

真偽値です。明示的に与えられない場合でも、ユーザーがが全てのパーミッションを持っているかどうかを示します。

get_user_permissions(obj=None)¶

Returns a set of permission strings that the user has directly.

If obj is passed in, only returns the user permissions for this specific object.

get_group_permissions(obj=None)¶

ユーザがグループを通して持つパーミッションの文字列のセットを返します。

obj が渡されたとき、指定されたオブジェクトに対するグループパーミッションのみを返します。

get_all_permissions(obj=None)¶

ユーザがグループおよびユーザパーミッションを通して持つパーミッションの文字列のセットを返します。

obj が渡された場合、指定されたオブジェクトに対するパーミッションのみを返します。

has_perm(perm, obj=None)¶

ユーザーが指定したパーミッションを持っている場合、True を返します。ここで、perm は "<app label>.<permission codename>" という形式で指定します (permissions を参照)。もし、User.is_active と is_superuser が両方とも True だった場合、このメソッドは常に True を返します。

obj が渡された場合、このメソッドはモデルに対するパーミッションのチェックを行わず、指定されたオブジェクトに対して行います。

has_perms(perm_list, obj=None)¶

ユーザーが指定したパーミッションを持っている場合、True を返します。ここで、perm は "<app label>.<permission codename>" という形式で指定します。もし、User.is_active と is_superuser が両方とも True だった場合、このメソッドは常に True を返します。

obj が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。

has_module_perms(package_name)¶

Returns True if the user has any permissions in the given package (the Django app label). If User.is_active and is_superuser are both True, this method always returns True.

カスタムのユーザーと proxy モデル¶

One limitation of custom user models is that installing a custom user model will break any proxy model extending User. Proxy models must be based on a concrete base class; by defining a custom user model, you remove the ability of Django to reliably identify the base class.

If your project uses proxy models, you must either modify the proxy to extend the user model that's in use in your project, or merge your proxy's behavior into your User subclass.

完全な具体例¶

Here is an example of an admin-compliant custom user app. This user model uses an email address as the username, and has a required date of birth; it provides no permission checking beyond an admin flag on the user account. This model would be compatible with all the built-in auth forms and views, except for the user creation forms. This example illustrates how most of the components work together, but is not intended to be copied directly into projects for production use.

This code would all live in a models.py file for a custom authentication app:

from django.db import models
from django.contrib.auth.models import BaseUserManager, AbstractBaseUser


class MyUserManager(BaseUserManager):
    def create_user(self, email, date_of_birth, password=None):
        """
        Creates and saves a User with the given email, date of
        birth and password.
        """
        if not email:
            raise ValueError("Users must have an email address")

        user = self.model(
            email=self.normalize_email(email),
            date_of_birth=date_of_birth,
        )

        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_superuser(self, email, date_of_birth, password=None):
        """
        Creates and saves a superuser with the given email, date of
        birth and password.
        """
        user = self.create_user(
            email,
            password=password,
            date_of_birth=date_of_birth,
        )
        user.is_admin = True
        user.save(using=self._db)
        return user


class MyUser(AbstractBaseUser):
    email = models.EmailField(
        verbose_name="email address",
        max_length=255,
        unique=True,
    )
    date_of_birth = models.DateField()
    is_active = models.BooleanField(default=True)
    is_admin = models.BooleanField(default=False)

    objects = MyUserManager()

    USERNAME_FIELD = "email"
    REQUIRED_FIELDS = ["date_of_birth"]

    def __str__(self):
        return self.email

    def has_perm(self, perm, obj=None):
        "Does the user have a specific permission?"
        # Simplest possible answer: Yes, always
        return True

    def has_module_perms(self, app_label):
        "Does the user have permissions to view the app `app_label`?"
        # Simplest possible answer: Yes, always
        return True

    @property
    def is_staff(self):
        "Is the user a member of staff?"
        # Simplest possible answer: All admins are staff
        return self.is_admin

Then, to register this custom user model with Django's admin, the following code would be required in the app's admin.py file:

from django import forms
from django.contrib import admin
from django.contrib.auth.models import Group
from django.contrib.auth.admin import UserAdmin as BaseUserAdmin
from django.contrib.auth.forms import ReadOnlyPasswordHashField
from django.core.exceptions import ValidationError

from customauth.models import MyUser


class UserCreationForm(forms.ModelForm):
    """A form for creating new users. Includes all the required
    fields, plus a repeated password."""

    password1 = forms.CharField(label="Password", widget=forms.PasswordInput)
    password2 = forms.CharField(
        label="Password confirmation", widget=forms.PasswordInput
    )

    class Meta:
        model = MyUser
        fields = ["email", "date_of_birth"]

    def clean_password2(self):
        # Check that the two password entries match
        password1 = self.cleaned_data.get("password1")
        password2 = self.cleaned_data.get("password2")
        if password1 and password2 and password1 != password2:
            raise ValidationError("Passwords don't match")
        return password2

    def save(self, commit=True):
        # Save the provided password in hashed format
        user = super().save(commit=False)
        user.set_password(self.cleaned_data["password1"])
        if commit:
            user.save()
        return user


class UserChangeForm(forms.ModelForm):
    """A form for updating users. Includes all the fields on
    the user, but replaces the password field with admin's
    disabled password hash display field.
    """

    password = ReadOnlyPasswordHashField()

    class Meta:
        model = MyUser
        fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]


class UserAdmin(BaseUserAdmin):
    # The forms to add and change user instances
    form = UserChangeForm
    add_form = UserCreationForm

    # The fields to be used in displaying the User model.
    # These override the definitions on the base UserAdmin
    # that reference specific fields on auth.User.
    list_display = ["email", "date_of_birth", "is_admin"]
    list_filter = ["is_admin"]
    fieldsets = [
        (None, {"fields": ["email", "password"]}),
        ("Personal info", {"fields": ["date_of_birth"]}),
        ("Permissions", {"fields": ["is_admin"]}),
    ]
    # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin
    # overrides get_fieldsets to use this attribute when creating a user.
    add_fieldsets = [
        (
            None,
            {
                "classes": ["wide"],
                "fields": ["email", "date_of_birth", "password1", "password2"],
            },
        ),
    ]
    search_fields = ["email"]
    ordering = ["email"]
    filter_horizontal = []


# Now register the new UserAdmin...
admin.site.register(MyUser, UserAdmin)
# ... and, since we're not using Django's built-in permissions,
# unregister the Group model from admin.
admin.site.unregister(Group)

Finally, specify the custom model as the default user model for your project using the AUTH_USER_MODEL setting in your settings.py:

AUTH_USER_MODEL = "customauth.MyUser"