Django がデフォルトで提供する認証機能は、ほとんどの一般的なケースでは十分なものですが、デフォルトではニーズにマッチしない場合もあると思います。自分のプロジェクトで認証のカスタマイズを行うためには、Django が提供する認証システムをどの場所で拡張・置換できるかという知識が必要です。このドキュメントでは、認証システムをカスタマイズする方法の詳細について説明します。
\n認証バックエンド を利用すると、ユーザーモデルに保存されたユーザー名とパスワードを用いて異なるサービス間での認証を行う必要が生じた場合に Django 標準よりも高い拡張性を持たせることができます。
\nあなたはDjango認証システムを通した認証による改良したパーミッション<custom-permission>をあなたのユーザモデルに組み込むことができるでしょう。
\nあなたは標準の User モデルを 拡張、もしくは完全にカスタマイズしたモデルを 代わりに用いる 事ができます。
もしかしたらあなたは，他の認証元からユーザネームとパスワード，もしくは認証方式のため，別の認証元にhookする必要があるかもしれません。
\n例えばあなたの会社ですでに全ての従業員のユーザ名とパスワードを記録しているLDAP認証があるとしましょう。もしユーザがLDAP認証とdjangoアプリケーションで異なるアカウントだとしたらネットワーク管理者とユーザで口論になるでしょう。
\nそこでこのような状況に対応するためにDjangoの認証システムは他の認証システムのリソースと接続できます。あなたはDjangoのデフォルトのデータベーススキーマをオーバーライドするか、他のシステムを連携するためにデフォルトシステムを使うことができます。
\nDjango に含まれている認証バックエンドに関する情報は 認証バックエンドリファレンス を参照してください。
\n内部的に、Django は認証を確認する「認証バックエンド」のリストを保持しています。django.contrib.auth.authenticate() を誰かがコールすると -- どのようにログインするか で記述されているように -- Django はその認証バックエンド全てに対して認証を試行します。最初の認証方法が失敗した場合、Django は次の方法、また次の方法といった具合に、全てのバックエンドに対して認証を試行します。
認証バックエンドとして利用するリストは AUTHENTICATION_BACKENDS に定義されています。この設定値は認証方法を定義している Python クラスを指定する Python パスのリスト型変数でなければなりません。これらのクラスはあなたの環境で有効な Python パスのどこにでも配置可能です。
初期状態では、AUTHENTICATION_BACKENDS は以下の値として定義されています。:
['django.contrib.auth.backends.ModelBackend']\nこれは Django のユーザーデータベースを確認してビルトインの権限を照会する基本的な認証バックエンドです。このバックエンドにはログイン試行を制限することでブルートフォース攻撃を防御する仕組みは提供していません。独自に試行制限を実装した認証バックエンドを利用するか、多くのウェブサーバーで提供されている各種防御機構が利用可能です。
\nAUTHENTICATION_BACKENDS への順番は処理に影響し、同じユーザー名とパスワードによって複数のバックエンドで有効な認証と判定されれば、Django は最初に有効と判定した時点で処理を終了します。
ある認証バックエンドにおいて PermissionDenied 例外が発生した場合、認証処理は直ちに終了し、Django は続く認証バックエンドに対する認証判定を行いません。
\n\n認証バックエンドは2つの必須メソッド: get_user(user_id) と authenticate(request, **credentials) を持ったクラスであり、 また、パーミッションに関連した省略可能な authorization methods を持ちます。
get_user` メソッドは user_id -- ユーザー名、データベース上の ID 等、何でも利用できますが、あなたが定義したユーザーオブジェクトの主キーである値 -- を取って一つのユーザーオブジェクト、または``None``を返却します。
authenticate メソッドは request 引数と、キーワード引数として認証情報を持ちます。多くの場合、次のように表されます:
class MyBackend:\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\n一方、次のように認証トークンでも表せます:
\nclass MyBackend:\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nいずれの場合にせよ、 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\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\nclass SettingsBackend:\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)\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モデルオブジェクトに対してカスタムパーミッションを作成したい場合は model Meta attribute の``permissions`` を使用してください。
\nこの例の Task モデルは、2つのカスタムパーミッションを作成します。すなわち、このアプリケーションにおいて、ユーザーが Task インスタンスに関係して、できることとできないことを規定します。
class Task(models.Model):\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 )\nThe only thing this does is create those extra permissions when you run\nmanage.py migrate (the function that creates permissions\nis connected to the post_migrate signal).\nYour code is in charge of checking the value of these permissions when a user\nis trying to access the functionality provided by the application (changing the\nstatus of tasks or closing tasks.) Continuing the above example, the following\nchecks if a user may close tasks:
user.has_perm('app.close_task')\nUser モデルを拡張するLink to this heading#独自のモデルを使用することなく、デフォルトのモデル User を拡張する方法が2つあります。振る舞いのみを変更し、データベースに格納されている内容を変更する必要がない場合は User に基づいて proxy model を作成できます。これにより、デフォルトの並び順、カスタムマネージャ、カスタムモデルメソッドなど、プロキシモデルによって提供される機能を利用可能です。
User に関連した情報を格納したい場合は、 OneToOneField を追加する情報のフィールドを持ったモデルに使用することができます。この1対1モデルはサイトユーザーに関する、認証には関連しない情報を格納することがあるため、しばしばプロファイルモデルと呼ばれます。たとえば、次のような Employee モデルを作ります:
from django.contrib.auth.models import User\n\nclass Employee(models.Model):\n user = models.OneToOneField(User, on_delete=models.CASCADE)\n department = models.CharField(max_length=100)\nUser モデルと 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# 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# Define a new User admin\nclass UserAdmin(BaseUserAdmin):\n inlines = (EmployeeInline,)\n\n# Re-register UserAdmin\nadmin.site.unregister(User)\nadmin.site.register(User, UserAdmin)\nこれらのプロファイルモデルは特殊なものではありませんー単純にユーザーモデルと1体1でリンクされた 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 の名前 ( INSTALLED_APPS に含まれている必要があります) とあなたがユーザーモデルとして使用したい Django モデルの名前です。
新しくプロジェクトを始める場合は、デフォルトの User で十分である場合でも、カスタムユーザーモデルを作成することを強く推奨します。このモデルはデフォルトのユーザーモデルと同様に動作しますが、必要に応じて将来的にカスタマイズすることができます:
from django.contrib.auth.models import AbstractUser\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 と呼ばれます）。そうしない場合、依存関係の問題が発生します。
In addition, you may run into a CircularDependencyError when running your\nmigrations as Django won't be able to automatically break the dependency loop\ndue to the dynamic dependency. If you see this error, you should break the loop\nby moving the models depended on by your user model into a second migration.\n(You can try making two normal models that have a ForeignKey to each other\nand seeing how makemigrations resolves that circular dependency if you want\nto see how it's usually done.)
AUTH_USER_MODELLink to this heading#Reusable apps shouldn't implement a custom user model. A project may use many\napps, and two reusable apps that implemented a custom user model couldn't be\nused together. If you need to store per user information in your app, use\na ForeignKey or\nOneToOneField to settings.AUTH_USER_MODEL\nas described below.
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\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\ndef post_save_receiver(sender, instance, created, **kwargs):\n pass\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(), ...) という表記が可能です。
If your app is tested with multiple user models, using\n@override_settings(AUTH_USER_MODEL=...) for example, and you cache the\nresult of get_user_model() in a module-level variable, you may need to\nlisten to the setting_changed signal to clear\nthe cache. For example:
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@receiver(setting_changed)\ndef user_model_swapped(**kwargs):\n if kwargs['setting'] == 'AUTH_USER_MODEL':\n apps.clear_cache()\n from myapp import some_module\n some_module.UserModel = get_user_model()\nDjango は、カスタムのユーザーモデルがいくつかの最低限の要件を満たしていることを期待します。
\nデフォルトの認証バックエンドを使用している場合、モデルは必ず、認証のために使用できるユニークなフィールドを1つ持たなければなりません。このフィールドとしては、ユーザー名やメールアドレスなど、ユニークな属性ならば使用できます。ユニークでないユーザー名などのフィールドが使用できるのは、そのようなフィールドを扱えるカスタムの認証バックエンドだけです。
\nThe easiest way to construct a compliant custom user model is to inherit from\nAbstractBaseUser.\nAbstractBaseUser provides the core\nimplementation of a user model, including hashed passwords and tokenized\npassword resets. You must then provide some key implementation details:
A string describing the name of the field on the user model that is\nused as the unique identifier. This will usually be a username of some\nkind, but it can also be an email address, or any other unique\nidentifier. The field must be unique (i.e., have unique=True set\nin its definition), unless you use a custom authentication backend that\ncan support non-unique usernames.
以下の例では、フィールドを一意に指定するために、identifier フィールドが使われています。
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = 'identifier'\nユーザーモデルにあるメールのフィールド名を文字列で記述します。この値は get_email_field_name() で返されます。
A list of the field names that will be prompted for when creating a\nuser via the createsuperuser management command. The user\nwill be prompted to supply a value for each of these fields. It must\ninclude any field for which blank is\nFalse or undefined and may include additional fields you want\nprompted for when a user is created interactively.\nREQUIRED_FIELDS has no effect in other parts of Django, like\ncreating a user in the admin.
For example, here is the partial definition for a user model that\ndefines two required fields - a date of birth and height:
\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.
Optional. A longer formal identifier for the user such as their full\nname. If implemented, this appears alongside the username in an\nobject's history in django.contrib.admin.
Optional. A short, informal identifier for the user such as their\nfirst name. If implemented, this replaces the username in the greeting\nto the user in the header of 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 となります。
Read-only attribute which is always False. This is a way of\ndifferentiating User and AnonymousUser\nobjects. Generally, you should prefer using\nis_authenticated to this attribute.
Sets the user's password to the given raw string, taking care of the\npassword hashing. Doesn't save the\nAbstractBaseUser object.
When the raw_password is None, the password will be set to an\nunusable password, as if\nset_unusable_password()\nwere used.
与えられた生の文字列が、ユーザに対して正しいパスワードであれば 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 this user\nwill never return True. Doesn't save the\nAbstractBaseUser object.
アプリケーションの認証が LDAP ディレクトリなどの既存の外部ソースに対して行われている場合は、これが必要になることがあります。
\nReturns False if\nset_unusable_password() has\nbeen called for this user.
Returns an HMAC of the password field. Used for\nSession invalidation on password change.
\nAbstractUser subclasses AbstractBaseUser:
BaseUserManager.normalize_email() を呼び出し、メールを正規化します。このメソッドをオーバーライドした場合、正規化を保持するために必ず super() を呼び出すようにしてください。
You should also define a custom manager for your user model. If your user model\ndefines username, email, is_staff, is_active, is_superuser,\nlast_login, and date_joined fields the same as Django's default user,\nyou can just install Django's UserManager;\nhowever, if your user model defines different fields, you'll need to define a\ncustom manager that extends BaseUserManager\nproviding two additional methods:
The prototype of create_user() should accept the username field,\nplus all required fields as arguments. For example, if your user model\nuses email as the username field, and has date_of_birth as a\nrequired field, then create_user should be defined as:
def create_user(self, email, date_of_birth, password=None):\n # create user here\n ...\nThe prototype of create_superuser() should accept the username\nfield, plus all required fields as arguments. For example, if your user\nmodel uses email as the username field, and has date_of_birth\nas a required field, then create_superuser should be defined as:
def create_superuser(self, email, date_of_birth, password):\n # create superuser here\n ...\nUnlike create_user(), create_superuser() must require the\ncaller to provide a password.
For a ForeignKey in USERNAME_FIELD or\nREQUIRED_FIELDS, these methods receive the value of the\nto_field (the primary_key\nby default) of an existing instance.
BaseUserManager provides the following\nutility methods:
Normalizes email addresses by lowercasing the domain portion of the\nemail address.
\nRetrieves a user instance using the contents of the field\nnominated by USERNAME_FIELD.
Returns a random password with the given length and given string of\nallowed characters. Note that the default value of allowed_chars\ndoesn't contain letters that can cause user confusion, including:
i, l, I, and 1 (lowercase letter i, lowercase\nletter L, uppercase letter i, and the number one)
o, O, and 0 (lowercase letter o, uppercase letter o,\nand zero)
UserLink to this heading#If you're entirely happy with Django's User\nmodel and you just want to add some additional profile information, you could\nsimply subclass django.contrib.auth.models.AbstractUser and add your\ncustom profile fields, although we'd recommend a separate model as described in\nthe "Model design considerations" note of カスタムのユーザーモデルを指定する.\nAbstractUser provides the full implementation of the default\nUser as an abstract model.
Django のビルトインの forms と views は、協調して動作するユーザーモデルに対して、いくつかの前提を置いています。
\n以下のフォームは AbstractBaseUser のあらゆるサブクラスに互換性があります。
AuthenticationForm: USERNAME_FIELD で指定したユーザー名フィールドを使用する。
以下のフォームは、ユーザーモデルについて以下のようないくつか前提を置いています。これらの前提を満たしている場合、同じユーザーモデルとみなして使用することができます。
\nPasswordResetForm: Assumes that the user\nmodel has a field that stores the user's email address with the name returned\nby get_email_field_name() (email by\ndefault) that can be used to identify the user and a boolean field named\nis_active to prevent password resets for inactive users.
最後に、以下のフォームは、User と固く結びついているため、カスタムのユーザーモデルとともに使用するには、書き換えや拡張が必要になります。
If your custom user model is a simple subclass of AbstractUser, then you\ncan extend these forms in this manner:
from django.contrib.auth.forms import UserCreationForm\nfrom myapp.models import CustomUser\n\nclass CustomUserCreationForm(UserCreationForm):\n\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 を返します。
Returns True if the user has the named permission. If obj is\nprovided, the permission needs to be checked against a specific object\ninstance.
Returns True if the user has permission to access models in\nthe given app.
You will also need to register your custom user model with the admin. If\nyour custom user model extends django.contrib.auth.models.AbstractUser,\nyou can use Django's existing django.contrib.auth.admin.UserAdmin\nclass. However, if your user model extends\nAbstractBaseUser, you'll need to define\na custom ModelAdmin class. It may be possible to subclass the default\ndjango.contrib.auth.admin.UserAdmin; however, you'll need to\noverride any of the definitions that refer to fields on\ndjango.contrib.auth.models.AbstractUser that aren't on your\ncustom user class.
Django のパーミッションフレームワークをカスタムのユーザーモデルに簡単に取り入れられるように用意されているのが、Django の PermissionsMixin です。これはユーザーモデルの階層に取り入れることができる抽象モデルで、Django のパーミッションモデルをサポートするのに必要なすべてのメソッドとデーターベースのフィールドを使えるようにしてくれます。
PermissionsMixin は、以下のメソッドと属性を提供します。
真偽値です。明示的に与えられない場合でも、ユーザーがが全てのパーミッションを持っているかどうかを示します。
\nユーザがグループを通して持つパーミッションの文字列のセットを返します。
\nobj が渡されたとき、指定されたオブジェクトに対するグループパーミッションのみを返します。
ユーザがグループおよびユーザパーミッションを通して持つパーミッションの文字列のセットを返します。
\nobj が渡された場合、指定されたオブジェクトに対するパーミッションのみを返します。
Returns True if the user has the specified permission, where\nperm is in the format "<app label>.<permission codename>" (see\npermissions). If User.is_active\nand is_superuser are both True, this method always\nreturns True.
obj が渡された場合、このメソッドはモデルに対するパーミッションのチェックを行わず、指定されたオブジェクトに対して行います。
Returns True if the user has each of the specified permissions,\nwhere each perm is in the format\n"<app label>.<permission codename>". If User.is_active and\nis_superuser are both True, this method always\nreturns True.
obj が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。
Returns True if the user has any permissions in the given package\n(the Django app label). If User.is_active and\nis_superuser are both True, this method always\nreturns True.
One limitation of custom user models is that installing a custom user model\nwill break any proxy model extending User.\nProxy models must be based on a concrete base class; by defining a custom user\nmodel, 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\nthe user model that's in use in your project, or merge your proxy's behavior\ninto your User subclass.
Here is an example of an admin-compliant custom user app. This user model uses\nan email address as the username, and has a required date of birth; it\nprovides no permission checking, beyond a simple admin flag on the user\naccount. This model would be compatible with all the built-in auth forms and\nviews, except for the user creation forms. This example illustrates how most of\nthe components work together, but is not intended to be copied directly into\nprojects for production use.
This code would all live in a models.py file for a custom\nauthentication app:
from django.db import models\nfrom django.contrib.auth.models import (\n BaseUserManager, AbstractBaseUser\n)\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):\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\nThen, to register this custom user model with Django's admin, the following\ncode would be required in the app's admin.py file:
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\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 password1 = forms.CharField(label='Password', widget=forms.PasswordInput)\n password2 = forms.CharField(label='Password confirmation', widget=forms.PasswordInput)\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 forms.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 password hash display field.\n """\n password = ReadOnlyPasswordHashField()\n\n class Meta:\n model = MyUser\n fields = ('email', 'password', 'date_of_birth', 'is_active', 'is_admin')\n\n def clean_password(self):\n # Regardless of what the user provides, return the initial value.\n # This is done here, rather than on the field, because the\n # field does not have access to the initial value\n return self.initial["password"]\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 (None, {\n 'classes': ('wide',),\n 'fields': ('email', 'date_of_birth', 'password1', 'password2')}\n ),\n )\n search_fields = ('email',)\n ordering = ('email',)\n filter_horizontal = ()\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)\nFinally, specify the custom model as the default user model for your project\nusing the AUTH_USER_MODEL setting in your settings.py:
AUTH_USER_MODEL = 'customauth.MyUser'\n