The authentication that comes with Django is good enough for most common cases,\nbut you may have needs not met by the out-of-the-box defaults. Customizing\nauthentication in your projects requires understanding what points of the\nprovided system are extensible or replaceable. This document provides details\nabout how the auth system can be customized.
\nAuthentication backends provide an extensible\nsystem for when a username and password stored with the user model need to be\nauthenticated against a different service than Django’s default.
\nPuede asignarle a sus modelos permisos personalizados que pueden ser comprobados mediante el sistema de autorización de Django.
\nYou can extend the default User model, or\nsubstitute a completely customized model.
A veces necesita trabajar en el código de otro sistema de autenticación, esto es, otra fuente de usuarios y contraseñas o métodos de autenticación.
\nPor ejemplo, tu compañía ya posee configurado un LDAP que almacena usuario y contraseña para cada empleado. Sería una molestia para los administradores y usuarios si los usuarios tuvieran cuentas separadas en LDAP y en las aplicaciones de Django.
\nSo, to handle situations like this, the Django authentication system lets you\nplug in other authentication sources. You can override Django’s default\ndatabase-based scheme, or you can use the default system in tandem with other\nsystems.
\nVea la guía de backends de autenticación para ver información sobre los backends de autenticación que trae Django.
\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.
The list of authentication backends to use is specified in the\nAUTHENTICATION_BACKENDS setting. This should be a list of Python\npath names that point to Python classes that know how to authenticate. These\nclasses can be anywhere on your Python path.
Por omisión, AUTHENTICATION_BACKENDS tiene como valor:
["django.contrib.auth.backends.ModelBackend"]\nThat’s the basic authentication backend that checks the Django users database\nand queries the built-in permissions. It does not provide protection against\nbrute force attacks via any rate limiting mechanism. You may either implement\nyour own rate limiting mechanism in a custom auth backend, or use the\nmechanisms provided by most web servers.
\nEl orden en AUTHENTICATION_BACKENDS importa, así que si el usuario y la contraseña son válidos en múltiples backends, la comprobación se detendrá en el primero que haya coincidencia.
Si un backend lanza una excepción PermissionDenied, la autenticación fallará inmediatamente. Django no comprobará el backend que sigue.
An 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.
The get_user method takes a user_id – which could be a username,\ndatabase ID or whatever, but has to be the primary key of your user object –\nand returns a user object or None.
The authenticate method takes a request argument and credentials as\nkeyword arguments. Most of the time, it’ll look like this:
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 ...\nPero también podría autenticar un token, de la siguiente manera:
\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 ...\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. For example, for a user to access the admin,\nUser.is_staff and User.is_active must be True (see\nAdminSite.has_permission() for details).
The best way to deal with this is to create a Django User object for each\nuser that exists for your backend (e.g., in your LDAP directory, your external\nSQL database, etc.). You can either write a script to do this in advance, or\nyour authenticate method can do it the first time a user 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. In this example, the created Django\nUser object is a superuser who will have full access to the admin:
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\nTo create custom permissions for a given model object, use the permissions\nmodel Meta attribute.
This example Task model creates two custom permissions, i.e., actions users\ncan or cannot do with Task instances, specific to your application:
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 ]\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 existenteLink 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\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\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)\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 personalizadoLink 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 label of the\nDjango app (which must be in your INSTALLED_APPS), and the name of\nthe Django model that you wish to use as your user model.
If you’re starting a new project, you can set up a custom user model that\nbehaves identically to the default user model by subclassing\nAbstractUser:
from django.contrib.auth.models import AbstractUser\n\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\npossible, but can be complex, 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.)
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.
UserLink 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,\nor User 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\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 the\ncustom model using the AUTH_USER_MODEL setting. For example:
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)\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\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()\nUser personalizadoLink to this heading#When you start your project with a custom user model, stop to consider if this\nis the right choice for your project.
\nKeeping all user related information in one model removes the need for\nadditional or more complex database queries to retrieve related models. On the\nother hand, it may be more suitable to store app-specific user information in a\nmodel that has a relation with your custom user model. That allows each app to\nspecify its own user data requirements without potentially conflicting or\nbreaking assumptions by other apps. It also means that you would keep your user\nmodel as simple as possible, focused on authentication, and following the\nminimum requirements Django expects custom user models to meet.
\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.
\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 (e.g. 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"\nA 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"]\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.
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\nAnonymousUser objects. Generally, you should prefer\nusing is_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.
Asynchronous version: acheck_password()
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\nthis user will 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()\nhas been called for this user.
Returns an HMAC of the password field. Used for\nSession invalidation on password change.
\nYields the HMAC of the password field using\nSECRET_KEY_FALLBACKS. Used by get_user().
AbstractUser 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 install Django’s UserManager;\nhowever, if your user model defines different fields, you’ll need to define a\ncustom manager that extends\nBaseUserManager providing two additional\nmethods:
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=None):\n # create superuser here\n ...\nFor 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.
\nAsynchronous version: aget_by_natural_key()
Retrieves a user instance using the contents of the field\nnominated by USERNAME_FIELD.
UserLink to this heading#If you’re entirely happy with Django’s\nUser model, but you want to add some\nadditional profile information, you could subclass\ndjango.contrib.auth.models.AbstractUser and add your custom profile\nfields, although we’d recommend a separate model as described in\nEspecificar un modelo de User personalizado. AbstractUser provides the full\nimplementation of the default User as an\nabstract 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 subclass of AbstractUser, then you can\nextend these forms in this manner:
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#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 directly.
\nIf obj is passed in, only returns the user permissions for this\nspecific object.
Returns 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 User.is_active\nand is_superuser are both True, this method always\nreturns True.
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 User.is_active and\nis_superuser are both True, this method always\nreturns True.
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 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 an admin flag on the user account.\nThis model would be compatible with all the built-in auth forms and views,\nexcept for the user creation forms. This example illustrates how most of the\ncomponents 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 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\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\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)\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"\nTo optimize performance when called from an async context authentication,\nbackends can implement async versions of each function - aget_user(user_id)\nand aauthenticate(request, **credentials). When an authentication backend\nextends BaseBackend and async versions of these functions are not provided,\nthey will be automatically synthesized with sync_to_async. This has\nperformance penalties.
While an async interface is optional, a synchronous interface is always\nrequired. There is no automatic synthesis for a synchronous interface if an\nasync interface is implemented.
\nDjango’s out-of-the-box authentication backends have native async support. If\nthese native backends are extended take special care to make sure the async\nversions of modified functions are modified as well.
\n