This document provides API reference material for the components of Django’s
authentication system. For more details on the usage of these components or
how to customize authentication and authorization see the authentication
topic guide.

The max_length should be sufficient for many use cases. If you need
a longer length, please use a custom user model. If you use MySQL with the utf8mb4
encoding (recommended for proper Unicode support), specify at most
max_length=191 because MySQL can only create unique indexes with
191 characters in that case by default.

Usernames and Unicode

Django originally accepted only ASCII letters and numbers in
usernames. Although it wasn’t a deliberate choice, Unicode
characters have always been accepted when using Python 3. Django
1.10 officially added Unicode support in usernames, keeping the
ASCII-only behavior on Python 2.

Boolean. Designates whether this user account should be considered
active. We recommend that you set this flag to False instead of
deleting accounts; that way, if your applications have any foreign keys
to users, the foreign keys won’t break.

Read-only attribute which is always True (as opposed to
AnonymousUser.is_authenticated which is always False). This is
a way to tell if the user has been authenticated. This does not imply
any permissions and doesn’t check if the user is active or has a valid
session. Even though normally you will check this attribute on
request.user to find out whether it has been populated by the
AuthenticationMiddleware
(representing the currently logged-in user), you should know this
attribute is True for any User instance.

In older versions, this also returns False if the password is
None or an empty string, or if the password uses a hasher
that’s not in the PASSWORD_HASHERS setting. That
behavior is considered a bug as it prevents users with such
passwords from requesting a password reset.

Returns True if the user has the specified permission, where perm
is in the format "<applabel>.<permissioncodename>". (see
documentation on permissions). If the user is
inactive, this method will always return False. For an active
superuser, this method will always return True.

If obj is passed in, this method won’t check for a permission for
the model, but for this specific object.

Returns True if the user has each of the specified permissions,
where each perm is in the format
"<applabel>.<permissioncodename>". If the user is inactive,
this method will always return False. For an active superuser, this
method will always return True.

If obj is passed in, this method won’t check for permissions for
the model, but for the specific object.

Returns True if the user has any permissions in the given package
(the Django app label). If the user is inactive, this method will
always return False. For an active superuser, this method will
always return True.

A dictionary of keyword arguments containing the user credentials that were
passed to authenticate() or your own custom
authentication backend. Credentials matching a set of ‘sensitive’ patterns,
(including password) will not be sent in the clear as part of the signal.

This is the default authentication backend used by Django. It
authenticates using credentials consisting of a user identifier and
password. For Django’s default user model, the user identifier is the
username, for custom user models it is the field specified by
USERNAME_FIELD (see Customizing Users and authentication).

Tries to authenticate username with password by calling
User.check_password. If no username
is provided, it tries to fetch a username from kwargs using the
key CustomUser.USERNAME_FIELD. Returns an
authenticated user or None.

Configures a newly created user. This method is called immediately
after a new user is created, and can be used to perform custom setup
actions, such as setting the user’s groups based on attributes in an
LDAP directory. Returns the user object.

Returns the user model instance associated with the given request’s
session.

It checks if the authentication backend stored in the session is present in
AUTHENTICATION_BACKENDS. If so, it uses the backend’s
get_user() method to retrieve the user model instance and then verifies
the session by calling the user model’s
get_session_auth_hash()
method.

Returns an instance of AnonymousUser
if the authentication backend stored in the session is no longer in
AUTHENTICATION_BACKENDS, if a user isn’t returned by the
backend’s get_user() method, or if the session auth hash doesn’t
validate.