Django がデフォルトで提供する認証機能は、ほとんどの一般的なケースでは十分なものですが、デフォルトではニーズにマッチしない場合もあると思います。自分のプロジェクトで認証のカスタマイズを行うためには、Django が提供する認証システムをどの場所で拡張・置換できるかという知識が必要です。このドキュメントでは、認証システムをカスタマイズする方法の詳細について説明します。
\n認証バックエンド を利用すると、ユーザーモデルに保存されたユーザー名とパスワードを用いて異なるサービス間での認証を行う必要が生じた場合に Django 標準よりも高い拡張性を持たせることができます。
\nモデルには、Django の認可システムで検証可能な カスタムパーミッション を組み込むことができます。
\nデフォルトの User モデルを 拡張 したり、完全にカスタマイズしたモデルと 置換 したりできます。
別の認証ソース、つまり、ユーザー名とパスワード、または他の認証方法を持つ別のソースにフックする必要がある場合があるかも知れません。
\nたとえば、あなたの会社ですでに全ての従業員のユーザ名とパスワードを記録しているLDAP認証があるとしましょう。もしユーザがLDAP認証とDjangoアプリケーションで異なるアカウントだとしたらネットワーク管理者とユーザで口論になるでしょう。
\nそこでこのような状況に対応するためにDjangoの認証システムは他の認証システムのリソースと接続できます。あなたはDjangoのデフォルトのデータベーススキーマをオーバーライドするか、他のシステムを連携するためにデフォルトシステムを使うことができます。
\nDjango に含まれている認証バックエンドに関する情報は 認証バックエンドリファレンス を参照してください。
\nBehind the scenes, Django maintains a list of "authentication backends" that it\nchecks for authentication. When somebody calls\ndjango.contrib.auth.authenticate() -- as described in How to log\na user in -- Django tries authenticating across\nall of its authentication backends. If the first authentication method fails,\nDjango tries the second one, and so on, until all backends have been attempted.
認証バックエンドとして利用するリストは AUTHENTICATION_BACKENDS に定義されています。この設定値は認証方法を定義している Python クラスを指定する Python パスのリスト型変数でなければなりません。これらのクラスはあなたの環境で有効な Python パスのどこにでも配置可能です。
初期状態では、AUTHENTICATION_BACKENDS は以下の値として定義されています。:
["django.contrib.auth.backends.ModelBackend"]\nこれは Django のユーザーデータベースを確認してビルトインの権限を照会する基本的な認証バックエンドです。このバックエンドにはログイン試行を制限することでブルートフォース攻撃を防御する仕組みは提供していません。独自に試行制限を実装した認証バックエンドを利用するか、多くのウェブサーバーで提供されている各種防御機構が利用可能です。
\nAUTHENTICATION_BACKENDS への順番は処理に影響し、同じユーザー名とパスワードによって複数のバックエンドで有効な認証と判定されれば、Django は最初に有効と判定した時点で処理を終了します。
ある認証バックエンドにおいて PermissionDenied 例外が発生した場合、認証処理は直ちに終了し、Django は続く認証バックエンドに対する認証判定を行いません。
認証 (authentication) バックエンドは、2つの必須メソッド: get_user(user_id) と authenticate(request, **credentials) を実装したクラスであり、パーミッションに関連した省略可能な 認可 (authorization) メソッド もあります。
get_user メソッドは user_id 引数を取ります。これはユーザーネーム、データベースID、またはその他何でもかまいませんが、ユーザーオブジェクトの主キーである必要があります。そして、ユーザーオブジェクトまたは None を返します。
authenticate メソッドは request 引数と credentials キーワード引数を取ります。殆どの場合、これは次のようになります。
from django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\n一方、次のように認証トークンでも表せます。
\nfrom django.contrib.auth.backends import BaseBackend\n\n\nclass MyBackend(BaseBackend):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nいずれの場合にせよ、 authenticate() は与えられた認証情報を確認し、それが有効であれば、認証情報とマッチしたユーザーオブジェクトを返すべきです。それが有効でなければ None を返すべきです。
request は HttpRequest で、 authenticate() が提供されていない場合は None となる可能性があります (バックエンドでこれを通過するため)。
Djangoの管理サイトはDjangoの Userオブジェクト と密接に連携しています。たとえば、ユーザーが管理サイトにアクセスするには、User.is_staff および User.is_active が True である必要があります（詳細は AdminSite.has_permission() を参照してください）。
これを実現する最善の方法は、バックエンド（例：LDAPディレクトリ、外部SQLデータベースなど）に存在する各ユーザーに対してDjangoの User オブジェクトを作成することです。事前にスクリプトを書いて作成するか、ユーザーが初めてログインした際に authenticate メソッドで自動的に作成する方法もあります。
以下は、settings.py ファイル内で定義されたユーザー名とパスワード変数を使って認証を行い、ユーザーが初めて認証した際にDjangoの User オブジェクトを作成するバックエンドの例です。この例では、作成されたDjango User オブジェクトはスーパーユーザーとして設定され、管理サイトへの完全なアクセス権を持ちます。
from django.conf import settings\nfrom django.contrib.auth.backends import BaseBackend\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\n\nclass SettingsBackend(BaseBackend):\n """\n Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.\n\n Use the login name and a hash of the password. For example:\n\n ADMIN_LOGIN = 'admin'\n ADMIN_PASSWORD = 'pbkdf2_sha256$30000$Vo0VlMnkR4Bk$qEvtdyZRWTcOsCnI/oQ7fVOu1XAURIZYoOZ3iq8Dr4M='\n """\n\n def authenticate(self, request, username=None, password=None):\n login_valid = settings.ADMIN_LOGIN == username\n pwd_valid = check_password(password, settings.ADMIN_PASSWORD)\n if login_valid and pwd_valid:\n try:\n user = User.objects.get(username=username)\n except User.DoesNotExist:\n # Create a new user. There's no need to set a password\n # because only the password from settings.py is checked.\n user = User(username=username) # is_active defaults to True.\n user.is_staff = True\n user.is_superuser = True\n user.save()\n return user\n return None\n\n def get_user(self, user_id):\n try:\n return User.objects.get(pk=user_id)\n except User.DoesNotExist:\n return None\nモデルオブジェクトに対してカスタムパーミッションを作成したい場合は モデルの Meta 属性 permissions を使用してください。
この例の Task モデルは、2つのカスタムパーミッションを作成します。すなわち、このアプリケーションにおいて、ユーザーが Task インスタンスに関係して、できることとできないことを規定します。
class Task(models.Model):\n ...\n\n class Meta:\n permissions = [\n ("change_task_status", "Can change the status of tasks"),\n ("close_task", "Can remove a task by setting its status as closed"),\n ]\nこれは manage.py migrate を実行したときに、追加のパーミッションを作成するだけです (パーミッションを作成する関数は post_migrate シグナルに接続されています)。あなたがコード内でやることは、ユーザがアプリケーションの提供する機能(タスクのステータスを変更したり、タスクを閉じたり)にアクセスしようとしたときに、これらのパーミッションの値をチェックすることです。上記の例の続きで、次のコードはユーザーがタスクを閉じることができるかどうかをチェックします:
user.has_perm("app.close_task")\nUser モデルを拡張するLink to this heading#独自のモデルを使用することなく、デフォルトのモデル User を拡張する方法が2つあります。振る舞いのみを変更し、データベースに格納されている内容を変更する必要がない場合は User に基づいて プロキシモデル を作成できます。これにより、デフォルトの並び順、カスタムマネージャ、カスタムモデルメソッドなど、プロキシモデルによって提供される機能を利用可能です。
User に関連した情報を格納したい場合は、 OneToOneField を追加する情報のフィールドを持ったモデルに使用します。この一対一モデルはサイトユーザーに関する、認証には関連しない情報を格納することがあるため、しばしばプロファイルモデルと呼ばれます。たとえば、次のような Employee モデルを作ります:
from django.contrib.auth.models import User\n\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nUser モデルと Employee モデルの両方を持つ既存の Employee Fred Smith を想定すると、 Django の標準的なリレーション先モデルの規約を使って、関連情報にアクセスできます:
\n>>> u = User.objects.get(username="fsmith")\n>>> freds_department = u.employee.department\nadmin のユーザーページにプロファイルモデルのフィールドを追加する場合は、InlineModelAdmin (この例では、StackedInline を使用しています) をあなたの admin.py に定義し、それを User クラスで追加した UserAdmin クラスに追加します。
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.models import User\n\nfrom my_user_profile_app.models import Employee\n\n\n# Define an inline admin descriptor for Employee model\n# which acts a bit like a singleton\nclass EmployeeInline(admin.StackedInline):\n model = Employee\n can_delete = False\n verbose_name_plural = "employee"\n\n\n# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = [EmployeeInline]\n\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nこれらのプロファイルモデルは、特別な方法で処理される Django モデルではありません。ユーザーモデルと一対一のリンクを持っているだけです。したがって、ユーザーが作成されたときに自動的に作成されることはありませんが、django.db.models.signals.post_save を使って、適切にリレーション先モデルを作成または更新できます。
関連づけされたモデルを使用した場合、関連するデータを検索するための追加のクエリ実行や結合が行われます。あなたの必要性に応じて、関連づけされたフィールドをカスタムユーザーモデルにインクルードすることは適した選択肢となるでしょう。しかしながら、デフォルトのユーザーモデルとプロジェクトのアプリケーションに組み込み済みの連携は追加のデータベース負荷を正当化するでしょう。
\nUser モデルを置き換えるLink to this heading#Django にビルトインされている User モデルは、必ずしもプロジェクトが必要とする認証のモデルと合致するわけではありません。たとえば、サイトによってはユーザー名の代わりにメールアドレスを識別トークンとして使用する方が適した場合があります。
Django では、カスタムモデルを参照するように AUTH_USER_MODEL の値を設定することにより、デフォルトのユーザーモデルをオーバーライドできます:
AUTH_USER_MODEL = "myapp.MyUser"\nこのドットで区切られたペアは、Django app の label (INSTALLED_APPS に含まれている必要があります) と、ユーザーモデルとして使用したい Django モデルの名前です。
新しいプロジェクトを開始する場合、AbstractUser をサブクラス化することで、デフォルトのユーザーモデルと同じように動作するカスタムユーザーモデルを設定できます。
from django.contrib.auth.models import AbstractUser\n\n\nclass User(AbstractUser):\n pass\nAUTH_USER_MODEL に指定することを忘れないでください。任意のマイグレーションの作成、また、最初に実行する manage.py migrate の前に行ってください。
そして、モデルをアプリの admin.py に登録してください:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nAUTH_USER_MODEL をデータベーステーブルを作成した後に変更することも可能ですが、外部キーや多対多の関係などに影響を与えることがあるため、変更作業は複雑になるかもしれません。
この変更は自動的には行うことができません。手動でのスキーマ修正、古いユーザーテーブルからのデータ移動、一部のマイグレーションの手動による再適用をする必要があります。ステップの概要は #25313 を参照してください。
\nスワップ可能なモデルという Django の動的依存性により、 AUTH_USER_MODEL によって参照されるモデルはアプリの初回のマイグレーションで作成されなければなりません（通常は 0001_initial と呼ばれます）。そうしない場合、依存関係の問題が発生します。
マイグレーション中に CircularDependencyError に遭遇するかもしれません。依存関係の動的な性質のため、Django は依存関係のループを自動的に断ち切ることができないためです。もしこのエラーを見た場合、ユーザーモデルが依存しているモデルを2回目のマイグレーションに移動することで、依存関係のループがなくなるようにしてください。(お互いに ForeignKey を持つ2つの通常のモデルを作ることで、makemigrations が循環依存関係を通常と同じように解決させることもできます。)
AUTH_USER_MODELLink to this heading#再利用可能アプリはカスタムのユーザーモデルを実装するべきではありません。多数のアプリを使用するプロジェクトの場合、それぞれカスタムのユーザーモデルを実装した再利用可能アプリが2つあると、同時に使うことができなくなってしまいます。もしユーザー情報をアプリ度とに保存したい場合は、以下のように settings.AUTH_USER_MODEL に対して ForeignKey または OneToOneField を使用してください。
User モデルを参照するLink to this heading#User を直接参照する場合 (たとえば外部キーで参照する場合)、AUTH_USER_MODEL 設定が異なるユーザモデルに変更されたプロジェクトでは正しく動作しません。
User を直接参照する代わりに、django.contrib.auth.get_user_model() を使ってユーザモデルを参照すべきです。このメソッドは現在アクティブなユーザモデルを返します -- 指定されている場合はカスタムのユーザモデル、指定されていない場合は User です。
ユーザモデルに対して外部キーや多対多の関係を定義するときは、AUTH_USER_MODEL 設定を使ってカスタムのモデルを指定してください。例えば:
from django.conf import settings\nfrom django.db import models\n\n\nclass Article(models.Model):\n author = models.ForeignKey(\n settings.AUTH_USER_MODEL,\n on_delete=models.CASCADE,\n )\nユーザモデルによって送信されたシグナルと接続するときは、AUTH_USER_MODEL 設定を使ってカスタムのユーザモデルを指定してください。例えば:
from django.conf import settings\nfrom django.db.models.signals import post_save\n\n\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\n\n\npost_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)\n一般的に言って、最も簡単な方法は、インポート時に実行されるコードの中で 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\nfrom django.contrib.auth import get_user_model\nfrom django.core.signals import setting_changed\nfrom django.dispatch import receiver\n\n\n@receiver(setting_changed)\ndef user_model_swapped(*, setting, **kwargs):\n if setting == "AUTH_USER_MODEL":\n apps.clear_cache()\n from myapp import some_module\n\n some_module.UserModel = get_user_model()\nプロジェクトの開始時にカスタムのユーザーモデルを使おうとしている場合、自分のプロジェクトにとってこの選択は本当に正しいのだろうか、と立ち止まってよく考えてください。
\nユーザーに関連するすべての情報を1つのモデルに記録すれば、関連モデルを取得するために、追加のより複雑なデータベースクエリを書く必要がなくなります。しかし一方で、アプリ固有のユーザー情報は、カスタムのユーザーモデルに関連するモデルに記録した方がより適切かもしれません。そうすることにより、各アプリは、他のアプリと競合したりデータを破壊されたりする可能性を考えずに、自分のアプリに必要なユーザーデータのみを指定できます。また、ユーザーモデルを、認証に焦点を絞った、可能な限りシンプルなものに保ち続けられるようになります。それはまた、Django がカスタムのユーザーモデルに期待する最小限の要求を満たすことにもなります。
\nデフォルトの認証バックエンドを使用している場合、モデルは必ず、認証のために使用できるユニークなフィールドを1つ持たなければなりません。このフィールドとしては、ユーザー名やメールアドレスなど、ユニークな属性ならば使用できます。ユニークでないユーザー名などのフィールドが使用できるのは、そのようなフィールドを扱えるカスタムの認証バックエンドだけです。
\n準拠したカスタムユーザーモデルを構築する最も簡単な方法は、AbstractBaseUser を継承することです。AbstractBaseUser はユーザーモデルのコアとなる実装を提供しており、その中には、ハッシュ化パスワードやトークン化されたパスワードリセットなどの機能が含まれます。このクラスの継承後、以下のように、キー実装の詳細を自分で記述する必要があります。
ユニークな ID として使用される、ユーザーモデルのフィールド名を説明する文字列。これは通常、ある種のユーザー名になりますが、メールアドレスや他のユニークな ID にすることもできます。非ユニークなユーザー名をサポートできるカスタムの認証バックエンドを使っていない限り、このフィールドは 必ず ユニークである (たとえば、unique=True を定義内で設定する) 必要があります。
以下の例では、フィールドを一意に指定するために、identifier フィールドが使われています。
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = "identifier"\nユーザーモデルにあるメールのフィールド名を文字列で記述します。この値は get_email_field_name() で返されます。
createsuperuser 管理コマンド経由でユーザーを作成するときにプロンプトが表示されるフィールド名のリスト。ユーザーはこれらの各フィールドごとに値を入力するようにプロンプトが表示されます。blank が False または未定義のフィールドを含む必要があり、ユーザーが対話的に作成されるときにプロンプトを表示したい追加のフィールドを含むことができます。REQUIRED_FIELDS は、たとえば admin 上のユーザーの作成などの Django の他の部分では何も効果がありません。
たとえば、これは誕生日と身長の2つの必須フィールドを定義しているユーザーモデルの部分的な定義です。
\nclass MyUser(AbstractBaseUser):\n ...\n date_of_birth = models.DateField()\n height = models.FloatField()\n ...\n REQUIRED_FIELDS = ["date_of_birth", "height"]\nA boolean attribute that indicates whether the user is considered\n"active". This attribute is provided as an attribute on\nAbstractBaseUser defaulting to True. How you choose to\nimplement it will depend on the details of your chosen auth backends.\nSee the documentation of the is_active attribute on the built-in\nuser model for details.
オプション。フルネームなどのユーザーに対するより長い正式の ID です。実装した場合、django.contrib.admin のオブジェクト履歴内でユーザー名とともに表示されます。
オプション。ファーストネームなどのユーザーに対するより短い正式ではない ID です。実装した場合、django.contrib.admin のヘッダー内のユーザーへの挨拶内でユーザー名の代わりに使われます。
次の属性とメソッドは AbstractBaseUser: の任意のサブクラスで利用可能です。
USERNAME_FIELD で指定されたフィールドの値を返します。
normalize_username() を呼び出し、username を正規化します。このメソッドをオーバーライドした場合、正規化を保持するために super() を呼び出すようにしてください。
EMAIL_FIELD 属性で指定されたメールフィールドの名前を返します。EMAIL_FIELD の指定が無いとき、デフォルトは 'email' です。
視覚的に同一であるが異なる Unicode の符号位置を持つ文字について、それらが同一とみなされるように、username に NFKC Unicode正規化を適用します。
\n(AnonymousUser.is_authenticated が常に False なのとは対照的に) 常に True の読み取り専用属性です。ユーザが認証済みかどうかを知らせる方法です。これはパーミッションという意味ではなく、ユーザーがアクティブかどうか、また有効なセッションがあるかどうかをチェックするわけでもありません。 通常、request.user のこの属性をチェックして AuthenticationMiddleware (現在ログイン中のユーザを表します) によって格納されているかどうかを調べます。User のインスタンスの場合、この属性は True となります。
常に False の読み取り専用属性です。User オブジェクトと AnonymousUser オブジェクトを区別する方法です。一般的に、is_authenticated を使う方が好ましいと言えます。
指定された生の文字列に、ユーザのパスワードをセットし、パスワードのハッシュ処理を行います。AbstractBaseUser は保存しません。
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
非同期バージョン: acheck_password()
与えられた生の文字列が、ユーザに対して正しいパスワードであれば True を返します。 (比較する際にはパスワードハッシュを処理します。)
Marks the user as having no password set. This isn't the same as\nhaving a blank string for a password.\ncheck_password() for\nthis user will never return True. Doesn't save the\nAbstractBaseUser object.
アプリケーションの認証が LDAP ディレクトリなどの既存の外部ソースに対して行われている場合は、これが必要になることがあります。
\nReturns False if\nset_unusable_password()\nhas been called for this user.
パスワードフィールドの HAMC を返します。パスワード変更時にセッションを無効化する ために利用されます。
\nSECRET_KEY_FALLBACKS を使用しているパスワードフィールドの HMAC を yield します。get_user() で使用されます。
AbstractUser は AbstractBaseUser をサブクラス化します。
BaseUserManager.normalize_email() を呼び出し、メールを正規化します。このメソッドをオーバーライドした場合、正規化を保持するために必ず super() を呼び出すようにしてください。
また、ユーザモデルに対してカスタムマネージャを定義する必要があります。ユーザモデルが username, email, is_staff, is_active, is_superuser, last_login, date_joined フィールドを Django のデフォルトユーザと同じように定義している場合、 Django の UserManager をインストールできます。しかし、ユーザモデルが異なるフィールドを定義している場合は、 BaseUserManager を継承して、さらに 2 つのメソッドを提供するカスタムマネージャを定義する必要があります:
create_user() のプロトタイプは、ユーザ名フィールドとすべての必須フィールドを引数として受け取る必要があります。たとえば、ユーザーモデルがユーザー名フィールドとして email を使用し、必須フィールドとして date_of_birth を持つ場合、 create_user は次のように定義します:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\ncreate_superuser() のプロトタイプは、ユーザ名フィールドとすべての必須フィールドを引数として受け取る必要があります。たとえば、ユーザーモデルがユーザー名フィールドとして email を使用し、必須フィールドとして date_of_birth を持つ場合、 create_superuser は次のように定義します:
def create_superuser(self, email, date_of_birth, password=None):\n # create superuser here\n ...\nForeignKey の USERNAME_FIELD または REQUIRED_FIELDS の場合、これらのメソッドは既存のインスタンスの to_field (デフォルトでは primary_key) の値を受け取ります。
BaseUserManager は以下のユーティリティメソッドを提供します:
メールアドレスのドメイン部分を小文字にすることで、メールアドレスを正規化します。
\n非同期バージョン: aget_by_natural_key()
USERNAME_FIELD で指定されたフィールドの内容を使用してユーザーインスタンスを取得します。
User を拡張するLink to this heading#Django の User モデルに完全に満足しているものの、追加のプロフィール情報をいくつか追加したい場合、django.contrib.auth.models.AbstractUser をサブクラス化して、カスタムのプロフィールフィールドを追加することも可能ですが、カスタムのユーザーモデルを指定する で説明されているように、独立したモデルを作ることをおすすめします。AbstractUser は、デフォルトの User の完全な実装を 抽象モデル として提供します。
Django のビルトインの フォーム と ビュー は、協調して動作するユーザーモデルに対して、いくつかの前提を置いています。
\n以下のフォームは AbstractBaseUser のあらゆるサブクラスに互換性があります。
AuthenticationForm: USERNAME_FIELD で指定したユーザー名フィールドを使用する。
以下のフォームは、ユーザーモデルについて以下のようないくつか前提を置いています。これらの前提を満たしている場合、同じユーザーモデルとみなして使用できます。
\nPasswordResetForm: ユーザモデルには、ユーザのメールアドレスを格納するフィールドがあり、 get_email_field_name() (デフォルトでは email) によって返される名前がユーザを識別するために使用され、 is_active という真偽値フィールドがアクティブでないユーザのパスワードリセットを防ぐために使用されると仮定します。
最後に、以下のフォームは、User と固く結びついているため、カスタムのユーザーモデルとともに使用するには、書き換えや拡張が必要になります。
カスタムユーザモデルが AbstractUser のサブクラスであれば、次ようにフォームを拡張できます:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\n\nclass CustomUserCreationForm(UserCreationForm):\n class Meta(UserCreationForm.Meta):\n model = CustomUser\n fields = UserCreationForm.Meta.fields + ("custom_field",)\ndjango.contrib.adminLink to this heading#カスタムのユーザーモデルを admin で動作させたい場合、ユーザーモデルにいくつかの追加の属性とメソッドを定義しなければなりません。これらのメソッドを定義することで、admin はユーザーへアクセスを制御して admin のコンテンツに合わせることができます。
\nユーザーが admin サイトへのアクセス権を持っている時、True を返します。
ユーザーアカウントが現在アクティブな時、True を返します。
ユーザーが名前付きの権限を持っている時、True を返します。obj が提供された場合、特定のオブジェクトのインスタンスに対して権限をチェックする必要があります。
ユーザーが与えられたアプリ内のモデルへのアクセス権を持っている場合、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 上のフィールドを参照する定義のうち、カスタムユーザークラス上にはない定義をすべてオーバーライドする必要があるでしょう。
Django のパーミッションフレームワークをカスタムのユーザーモデルに簡単に取り入れられるように用意されているのが、Django の PermissionsMixin です。これはユーザーモデルの階層に取り入れることができる抽象モデルで、Django のパーミッションモデルをサポートするのに必要なすべてのメソッドとデーターベースのフィールドを使えるようにしてくれます。
PermissionsMixin は、以下のメソッドと属性を提供します。
真偽値です。明示的に与えられない場合でも、ユーザーがが全てのパーミッションを持っているかどうかを示します。
\nユーザーが直接持っているパーミッション文字列のセットを返します。
\nもし obj が渡された場合、この特定のオブジェクトのユーザパーミッションのみを返します。
ユーザがグループを通して持つパーミッションの文字列のセットを返します。
\nobj が渡されたとき、指定されたオブジェクトに対するグループパーミッションのみを返します。
ユーザがグループおよびユーザパーミッションを通して持つパーミッションの文字列のセットを返します。
\nobj が渡された場合、指定されたオブジェクトに対するパーミッションのみを返します。
ユーザーが指定したパーミッションを持っている場合、True を返します。ここで、perm は "<app label>.<permission codename>" という形式で指定します (パーミッション を参照)。もし、User.is_active と is_superuser が両方とも True だった場合、このメソッドは常に True を返します。
obj が渡された場合、このメソッドはモデルに対するパーミッションのチェックを行わず、指定されたオブジェクトに対して行います。
ユーザーが指定したパーミッションを持っている場合、True を返します。ここで、perm は "<app label>.<permission codename>" という形式で指定します。もし、User.is_active と is_superuser が両方とも True だった場合、このメソッドは常に True を返します。
obj が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。
ユーザが指定されたパッケージ（Django アプリのラベル）に何らかのパーミッションを持っている場合、 True を返します。 User.is_active と is_superuser が両方 True なら、このメソッドは常に True を返します。
カスタムユーザモデルの制限の一つは、カスタムユーザモデルをインストールすると、 User を拡張するプロキシモデルが壊れてしまうことです。プロキシモデルは具象基底クラスを継承している必要があります。カスタムユーザモデルを定義すると、 Django が基底クラスを確実に識別する方法を奪ってしまいます。
プロジェクトでプロキシモデルを使用している場合、プロキシを変更してプロジェクトで使用しているユーザーモデルを拡張するか、プロキシの動作を User サブクラスにマージする必要があります。
以下は admin に準拠したカスタムユーザーアプリの例です。このユーザモデルはユーザ名としてメールアドレスを使用し、生年月日を必須とします。ユーザーアカウントに admin フラグを立てるだけで、権限のチェックは行いません。このモデルはユーザー作成フォームを除く、すべての組み込みの認証フォームとビューと互換性があります。このサンプルはほとんどのコンポーネントがどう連携して動作するかの例であり、実運用のためのプロジェクトに直接コピーされることを想定したものではありません。
このコードはすべてカスタム認証アプリの models.py ファイルに格納されます:
from django.db import models\nfrom django.contrib.auth.models import BaseUserManager, AbstractBaseUser\n\n\nclass MyUserManager(BaseUserManager):\n def create_user(self, email, date_of_birth, password=None):\n """\n Creates and saves a User with the given email, date of\n birth and password.\n """\n if not email:\n raise ValueError("Users must have an email address")\n\n user = self.model(\n email=self.normalize_email(email),\n date_of_birth=date_of_birth,\n )\n\n user.set_password(password)\n user.save(using=self._db)\n return user\n\n def create_superuser(self, email, date_of_birth, password=None):\n """\n Creates and saves a superuser with the given email, date of\n birth and password.\n """\n user = self.create_user(\n email,\n password=password,\n date_of_birth=date_of_birth,\n )\n user.is_admin = True\n user.save(using=self._db)\n return user\n\n\nclass MyUser(AbstractBaseUser):\n email = models.EmailField(\n verbose_name="email address",\n max_length=255,\n unique=True,\n )\n date_of_birth = models.DateField()\n is_active = models.BooleanField(default=True)\n is_admin = models.BooleanField(default=False)\n\n objects = MyUserManager()\n\n USERNAME_FIELD = "email"\n REQUIRED_FIELDS = ["date_of_birth"]\n\n def __str__(self):\n return self.email\n\n def has_perm(self, perm, obj=None):\n "Does the user have a specific permission?"\n # Simplest possible answer: Yes, always\n return True\n\n def has_module_perms(self, app_label):\n "Does the user have permissions to view the app `app_label`?"\n # Simplest possible answer: Yes, always\n return True\n\n @property\n def is_staff(self):\n "Is the user a member of staff?"\n # Simplest possible answer: All admins are staff\n return self.is_admin\nそして、このカスタムユーザモデルを Django の admin に登録するには、アプリの admin.py ファイルに以下のコードが必要になります:
from django import forms\nfrom django.contrib import admin\nfrom django.contrib.auth.models import Group\nfrom django.contrib.auth.admin import UserAdmin as BaseUserAdmin\nfrom django.contrib.auth.forms import ReadOnlyPasswordHashField\nfrom django.core.exceptions import ValidationError\n\nfrom customauth.models import MyUser\n\n\nclass UserCreationForm(forms.ModelForm):\n """A form for creating new users. Includes all the required\n fields, plus a repeated password."""\n\n password1 = forms.CharField(label="Password", widget=forms.PasswordInput)\n password2 = forms.CharField(\n label="Password confirmation", widget=forms.PasswordInput\n )\n\n class Meta:\n model = MyUser\n fields = ["email", "date_of_birth"]\n\n def clean_password2(self):\n # Check that the two password entries match\n password1 = self.cleaned_data.get("password1")\n password2 = self.cleaned_data.get("password2")\n if password1 and password2 and password1 != password2:\n raise ValidationError("Passwords don't match")\n return password2\n\n def save(self, commit=True):\n # Save the provided password in hashed format\n user = super().save(commit=False)\n user.set_password(self.cleaned_data["password1"])\n if commit:\n user.save()\n return user\n\n\nclass UserChangeForm(forms.ModelForm):\n """A form for updating users. Includes all the fields on\n the user, but replaces the password field with admin's\n disabled password hash display field.\n """\n\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ["email", "password", "date_of_birth", "is_active", "is_admin"]\n\n\nclass UserAdmin(BaseUserAdmin):\n # The forms to add and change user instances\n form = UserChangeForm\n add_form = UserCreationForm\n\n # The fields to be used in displaying the User model.\n # These override the definitions on the base UserAdmin\n # that reference specific fields on auth.User.\n list_display = ["email", "date_of_birth", "is_admin"]\n list_filter = ["is_admin"]\n fieldsets = [\n (None, {"fields": ["email", "password"]}),\n ("Personal info", {"fields": ["date_of_birth"]}),\n ("Permissions", {"fields": ["is_admin"]}),\n ]\n # add_fieldsets is not a standard ModelAdmin attribute. UserAdmin\n # overrides get_fieldsets to use this attribute when creating a user.\n add_fieldsets = [\n (\n None,\n {\n "classes": ["wide"],\n "fields": ["email", "date_of_birth", "password1", "password2"],\n },\n ),\n ]\n search_fields = ["email"]\n ordering = ["email"]\n filter_horizontal = []\n\n\n# Now register the new UserAdmin...\nadmin.site.register(MyUser, UserAdmin)\n# ... and, since we're not using Django's built-in permissions,\n# unregister the Group model from admin.\nadmin.site.unregister(Group)\n最後に、 settings.py: の AUTH_USER_MODEL 設定を使用して、カスタムモデルをプロジェクトのデフォルトのユーザーモデルとして指定します:
AUTH_USER_MODEL = "customauth.MyUser"\n非同期コンテキストから呼び出される際のパフォーマンスを最適化するために、認証バックエンドは各関数の非同期版 ( aget_user(user_id) および aauthenticate(request, **credentials) ) を実装できます。認証バックエンドが BaseBackend を継承していて、これらの非同期関数を提供していない場合は、自動的に sync_to_async でラップされます。ただし、この方法には パフォーマンスペナルティ が伴います。
非同期インターフェースの実装は任意ですが、同期インターフェースは常に必要です。非同期インターフェースを実装していても、同期インターフェースが自動的に補完されることはありません。
\nDjango に標準で用意されている認証バックエンドは、ネイティブで非同期処理に対応しています。これらのバックエンドを継承して機能を拡張する場合は、変更した関数の非同期版も忘れずに対応させるよう注意してください。
\n