デフォルトで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\nAn authentication backend is a class that implements two required methods:\nget_user(user_id) and authenticate(request, **credentials), as well as\na set of optional permission related authorization methods.
get_user メソッドは user_id -- ユーザー名、データベース上の ID 等何でも利用できますが、あなたが定義したユーザーオブジェクトの主キーである値 -- を取って一つのユーザーオブジェクトを返します。
The authenticate method takes a request argument and credentials as\nkeyword arguments. Most of the time, it'll just look like this:
class MyBackend(object):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\nBut it could also authenticate a token, like so:
\nclass MyBackend(object):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nEither way, authenticate() should check the credentials it gets and return\na user object that matches those credentials if the credentials are valid. If\nthey're not valid, it should return None.
request is an HttpRequest and may be None if it\nwasn't provided to authenticate() (which passes it\non to the backend).
The Django admin is tightly coupled to the Django User object. The best way to deal with this is to create a Django User\nobject for each user that exists for your backend (e.g., in your LDAP\ndirectory, your external SQL database, etc.) You can either write a script to\ndo this in advance, or your authenticate method can do it the first time a\nuser logs in.
Here's an example backend that authenticates against a username and password\nvariable defined in your settings.py file and creates a Django User\nobject the first time a user authenticates:
from django.conf import settings\nfrom django.contrib.auth.hashers import check_password\nfrom django.contrib.auth.models import User\n\nclass SettingsBackend(object):\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\nTo create custom permissions for a given model object, use the permissions\nmodel Meta attribute.
This example Task model creates three custom permissions, i.e., actions users\ncan or cannot do with Task instances, specific to your application:
\nclass Task(models.Model):\n ...\n class Meta:\n permissions = (\n ("view_task", "Can see available tasks"),\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 (viewing\ntasks, changing the status of tasks, closing tasks.) Continuing the above\nexample, the following checks if a user may view tasks:
user.has_perm('app.view_task')\nUser modelLink to this heading#There are two ways to extend the default\nUser model without substituting your own\nmodel. If the changes you need are purely behavioral, and don't require any\nchange to what is stored in the database, you can create a proxy model based on User. This\nallows for any of the features offered by proxy models including default\nordering, custom managers, or custom model methods.
If you wish to store information related to User, you can use a\nOneToOneField to a model containing the fields for\nadditional information. This one-to-one model is often called a profile model,\nas it might store non-auth related information about a site user. For example\nyou might create an Employee model:
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)\nAssuming an existing Employee Fred Smith who has both a User and Employee\nmodel, you can access the related information using Django's standard related\nmodel conventions:
\n>>> u = User.objects.get(username='fsmith')\n>>> freds_department = u.employee.department\nTo add a profile model's fields to the user page in the admin, define an\nInlineModelAdmin (for this example, we'll use a\nStackedInline) in your app's admin.py and\nadd it to a UserAdmin class which is registered with the\nUser class:
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)\nThese profile models are not special in any way - they are just Django models\nthat happen to have a one-to-one link with a user model. As such, they aren't\nauto created when a user is created, but\na django.db.models.signals.post_save could be used to create or update\nrelated models as appropriate.
Using related models results in additional queries or joins to retrieve the\nrelated data. Depending on your needs, a custom user model that includes the\nrelated fields may be your better option, however, existing relations to the\ndefault user model within your project's apps may justify the extra database\nload.
\nUser modelLink to this heading#Some kinds of projects may have authentication requirements for which Django's\nbuilt-in User model is not always\nappropriate. For instance, on some sites it makes more sense to use an email\naddress as your identification token instead of a username.
Django allows you to override the default user model by providing a value for\nthe AUTH_USER_MODEL setting that references a custom model:
AUTH_USER_MODEL = 'myapp.MyUser'\nThis dotted pair describes the name of the Django app (which must be in your\nINSTALLED_APPS), and the name of the Django model that you wish to\nuse as your user model.
If you're starting a new project, it's highly recommended to set up a custom\nuser model, even if the default User model\nis sufficient for you. This model behaves identically to the default user\nmodel, but you'll be able to customize it in the future if the need arises:
from django.contrib.auth.models import AbstractUser\n\nclass User(AbstractUser):\n pass\nDon't forget to point AUTH_USER_MODEL to it. Do this before creating\nany migrations or running manage.py migrate for the first time.
Also, register the model in the app's admin.py:
from django.contrib import admin\nfrom django.contrib.auth.admin import UserAdmin\nfrom .models import User\n\nadmin.site.register(User, UserAdmin)\nChanging AUTH_USER_MODEL after you've created database tables is\nsignificantly more difficult since it affects foreign keys and many-to-many\nrelationships, for example.
This change can't be done automatically and requires manually fixing your\nschema, moving your data from the old user table, and possibly manually\nreapplying some migrations. See #25313 for an outline of the steps.
\nDue to limitations of Django's dynamic dependency feature for swappable\nmodels, the model referenced by AUTH_USER_MODEL must be created in\nthe first migration of its app (usually called 0001_initial); otherwise,\nyou'll have dependency issues.
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)\nGenerally speaking, it's easiest to refer to the user model with the\nAUTH_USER_MODEL setting in code that's executed at import time,\nhowever, it's also possible to call get_user_model() while Django\nis importing models, so you could use\nmodels.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 expects your custom user model to meet some minimum requirements.
\nIf you use the default authentication backend, then your model must have a\nsingle unique field that can be used for identification purposes. This can\nbe a username, an email address, or any other unique attribute. A non-unique\nusername field is allowed if you use a custom authentication backend that\ncan support it.
Your model must provide a way to address the user in a "short" and\n"long" form. The most common interpretation of this would be to use\nthe user's given name as the "short" identifier, and the user's full\nname as the "long" identifier. However, there are no constraints on\nwhat these two methods return - if you want, they can return exactly\nthe same value.
The 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.
In the following example, the field identifier is used\nas the identifying field:
class MyUser(AbstractBaseUser):\n identifier = models.CharField(max_length=40, unique=True)\n ...\n USERNAME_FIELD = 'identifier'\nUSERNAME_FIELD now supports\nForeignKeys. Since there is no way to pass\nmodel instances during the createsuperuser prompt, expect the\nuser to enter the value of to_field\nvalue (the primary_key by default) of an\nexisting instance.
A string describing the name of the email field on the User model.\nThis value is returned by\nget_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']\nREQUIRED_FIELDS now supports\nForeignKeys. Since there is no way to pass\nmodel instances during the createsuperuser prompt, expect the\nuser to enter the value of to_field\nvalue (the primary_key by default) of an\nexisting instance.
A 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.
A longer formal identifier for the user. A common interpretation\nwould be the full name of the user, but it can be any string that\nidentifies the user.
\nA short, informal identifier for the user. A common interpretation\nwould be the first name of the user, but it can be any string that\nidentifies the user in an informal way. It may also return the same\nvalue as django.contrib.auth.models.User.get_full_name().
The following attributes and methods are available on any subclass of\nAbstractBaseUser:
Returns the value of the field nominated by USERNAME_FIELD.
Normalizes the username by calling normalize_username(). If you\noverride this method, be sure to call super() to retain the\nnormalization.
Returns the name of the email field specified by the\nEMAIL_FIELD attribute. Defaults to\n'email' if EMAIL_FIELD isn't specified.
Applies NFKC Unicode normalization to usernames so that visually\nidentical characters with different Unicode code points are considered\nidentical.
\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:
Normalizes the email by calling\nBaseUserManager.normalize_email(). If you override this method,\nbe sure to call super() to retain the normalization.
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.
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 Specifying a custom user model.\nAbstractUser provides the full implementation of the default\nUser as an abstract model.
Django's built-in forms and views make certain assumptions about the user model that they\nare working with.
\nThe following forms are compatible with any subclass of\nAbstractBaseUser:
AuthenticationForm: Uses the username\nfield specified by USERNAME_FIELD.
The following forms make assumptions about the user model and can be used as-is\nif those assumptions are met:
\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.
Finally, the following forms are tied to\nUser and need to be rewritten or extended\nto work with a custom user model:
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#If you want your custom user model to also work with the admin, your user model\nmust define some additional attributes and methods. These methods allow the\nadmin to control access of the user to admin content:
\nReturns True if the user is allowed to have access to the admin site.
Returns True if the user account is currently active.
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.
To make it easy to include Django's permission framework into your own user\nclass, Django provides PermissionsMixin.\nThis is an abstract model you can include in the class hierarchy for your user\nmodel, giving you all the methods and database fields necessary to support\nDjango's permission model.
PermissionsMixin provides the following\nmethods and attributes:
真偽値です。明示的にアサインすることなく全てのパーミッションを持たせるかどうかを指定します。
\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 the user is inactive, this method will\nalways return False.
obj が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。
ユーザが指定されたそれぞれのパーミッションを持っている場合、True を返します。各パーミッションは "<app label>.<permission codename>" 形式です。ユーザが非アクティブの場合、このメソッドは常に False を返します。
obj が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。
ユーザが指定されたパッケージ (Django のアプリケーションラベル)内の全パーミッションを持っている場合、True を返します。ユーザが非アクティブの場合、このメソッドは常に False を返します。
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 get_full_name(self):\n # The user is identified by their email address\n return self.email\n\n def get_short_name(self):\n # The user is identified by their email address\n return self.email\n\n def __str__(self): # __unicode__ on Python 2\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(UserCreationForm, self).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