Uwierzytelnianie, które domyślnie jest dane w Django jest wystarczająco dobre dla większości powszechnych przypadków, ale możesz mieć potrzeby nie zaspokojone przez rozwiązanie out-of-the-box. Zmiana uwierzyteniania w twoich projektach wymaga zrozumienia, które punkty dostarczonego systemu są rozszerzalne lub wymienialne. Ten dokument zawiera szczegóły, jak system uwierzytelniania może być dostosowany.
\nBackendy uwierzytelniania dostarczają rozszerzalny system wtedy, gdy nazwa użytkownika i hasło przechowywane z modelem użytkownika muszą być uwierzytelnione w innej usłudze niż domyślna Django.
\nMożesz nadać swoim modelom własne uprawnienia, które mogą być sprawdzane przez system uwierzytelniania Django.
\nMożesz rozszerzyć domyślny model User lub zastąpić go zupełnie zmienionym modelem.
\nMoże się zdarzyć, że będziesz potrzebował wpiąć się w inne źródło uwierzytelniania – to znaczy, inne źródło nazw użytkownika i haseł lub metod uwierzytelniania.
\nNa przykład twoja firma może ma już uruchomione LDAP, które przechowuje nazwę użytkownika i hasło dla każdego pracownika. Byłoby mordęgą zarówno dla administratora sieci jak i samych użytkowników, jeśli mieliby oni oddzielne konta w LDAP i w aplikacjach opartych o Django.
\nAby obsłużyć takie sytuacje ja ta, system uwierzytelniania Django pozwala ci wpiąć inne źródła uwierzytelniania. Możesz nadpisać domyślny oparty na bazie danych schemat Django lub możesz użyć domyślnego systemu w zestawie z innymi systemami.
\nZobacz dokumentację backendów uwierzytelniania po informacje na temat backendów uwierzytelniania zawartych w Django.
\nPod maską, Django zarządza listą „backendów uwierzytelniania”, którą sprawdza dla uwierzytelnienia. Kiedy ktoś wywołuje django.contrib.auth.authenticate() – jak jest opisane w Jak zalogować użytkownika – Django próbuje uwierzytelnić przez wszystkie swoje backendy uwierzytelniania. Jeśli pierwsza metoda uwierzytelnienia zawiedzie, Django próbuję drugiej, i tak dalej, ąz wypróbuje wszystkie backendy.
Lista backendów uwierzytelniania do użycia jest wyspecyfikowana w ustawieniu AUTHENTICATION_BACKENDS. Powinna być to lista nazw ścieżek Pythona, które wskazują na klasy Pythona, które wiedzą jak uwierzytelniać. Te klasy mogą być gdziekolwiek na twojej ścieżce Pythona.
Domyślnie AUTHENTICATION_BACKENDS jest ustawione na:
['django.contrib.auth.backends.ModelBackend']\nTo podstawowy backend uwierzytelniający, który sprawdza bazę danych użytkowników Django i sprawdza wbudowane uprawnienia. Nie zawiera ochrony przeciwko atakom brute force przez żaden mechanizm ograniczania częstotliwości. Możesz albo zaimplementować swój własny mechanizm ograniczania częstotliwości we własnym backendzie auth lub użyć mechanizmów dostarczanych przez większość serwerów web.
\nKolejność w AUTHENTICATION_BACKENDS ma znaczenie, więc jeśli ta sama nazwa użytkownika i hasło są poprawne w wielu backendach, Django przestanie przetwarzać przy pierwszej udanej weryfikacji.
Jeśli backend zgłasza wyjątek PermissionDenied, uwierzytelnienie nie powiedzie się w sposób natychmiastowy. Django nie będzie sprawdzało następnych backendów.
Back-end autentykacji jest klasą, która implementuje dwie wymagane metody: get_user(user_id) i authenticate(request, **credentials) oraz zestaw związanych z prawami dostępu, opcjonalnych metod uwierzytelniających.
Metoda get_user przyjmuje user_id – które może być nazwą użytkownika, ID bazy danych lub czymkolwiek, ale musi być kluczem głównym twojego obiektu użytkownika – i zwraca obiekt użytkownika.
Metoda authenticate przyjmuje argument request i dane uwierzytelniające jako argumenty nazwane. W większości przypadków, będzie wyglądała dokładnie tak:
class MyBackend(object):\n def authenticate(self, request, username=None, password=None):\n # Check the username/password and return a user.\n ...\nAle może też autentykować token, w ten sposób:
\nclass MyBackend(object):\n def authenticate(self, request, token=None):\n # Check the token and return a user.\n ...\nOboma sposobami, authenticate() powinno sprawdzić dane autentykujące, które dostaje i zwrócić obiekt użytkownika, który zgadza się z tymi danymi, jeżeli są one poprawne. Jeśli nie są poprawne, authenticate() powinno zwrócić None.
request to obiekt klasy HttpRequest i może mieć wartość None, jeżeli nie został podany do authenticate() (które przekazuje go do back-endu).
Panel administracyjny Django jest ściśle związany z obiektem User Django. Najlepszym sposobem na to jest tworzenie obiektu User Django dla każdego użytkownika, który istnieje dla twojego backendu (np. w twoim katalogu LDAP, twojej zewnętrznej bazie SQL itp.) Możesz albo napisać skrypt, który zrobi to za jednym razem lub twoja metoda authenticate może zrobić to podczas pierwszego logowania się użytkownika.
Przykładowy backend, który autentykuje w oparciu o zmienne nazwę użytkownika i hasło określone w twoim pliku settings.py i tworzy obiekt User Django, w momencie, kiedy użytkownika autentykuje się po raz pierwszy:
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 modelLink to this heading#If you reference User directly (for\nexample, by referring to it in a foreign key), your code will not work in\nprojects where the AUTH_USER_MODEL setting has been changed to a\ndifferent user model.
Instead of referring to User directly,\nyou should reference the user model using\ndjango.contrib.auth.get_user_model(). This method will return the\ncurrently active user model – the custom user model if one is specified, or\nUser otherwise.
When you define a foreign key or many-to-many relations to the user model,\nyou should specify the custom model using the AUTH_USER_MODEL\nsetting. For example:
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 )\nWhen connecting to signals sent by the user model, you should specify\nthe custom model using the AUTH_USER_MODEL setting. For example:
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.
\nRead-only attribute which is always True (as opposed to\nAnonymousUser.is_authenticated which is always False).\nThis is a way to tell if the user has been authenticated. This does not\nimply any permissions and doesn’t check if the user is active or has\na valid session. Even though normally you will check this attribute on\nrequest.user to find out whether it has been populated by the\nAuthenticationMiddleware\n(representing the currently logged-in user), you should know this\nattribute is True for any User instance.
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.
Returns True if the given raw string is the correct password for\nthe user. (This takes care of the password hashing in making the\ncomparison.)
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.
You may need this if authentication for your application takes place\nagainst an existing external source such as an LDAP directory.
\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:
Boolean. Designates that this user has all permissions without\nexplicitly assigning them.
\nReturns a set of permission strings that the user has, through their\ngroups.
\nIf obj is passed in, only returns the group permissions for\nthis specific object.
Returns a set of permission strings that the user has, both through\ngroup and user permissions.
\nIf obj is passed in, only returns the permissions for this\nspecific object.
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.
If obj is passed in, this method won’t check for a permission for\nthe model, but for this specific object.
Returns True if the user has each of the specified permissions,\nwhere each perm is in the format\n"<app label>.<permission codename>". If the user is inactive,\nthis method will always return False.
If obj is passed in, this method won’t check for permissions for\nthe model, but for the specific object.
Returns True if the user has any permissions in the given package\n(the Django app label). If the user is inactive, this method will\nalways return 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