---
title: "django.contrib.auth"
version: 4.1
locale: ja
source: https://docs.djangoproject.com/ja/4.1/ref/contrib/auth/
canonical: https://djangodocs.dev/ja/4.1/ref/contrib/auth/
---
# `django.contrib.auth`

このドキュメントでは、Django の 認証システムのコンポーネントの API リファレンス資料を提供しています。 これらのコンポーネントの使い方や、認証と承認をカスタマイズする方法の詳細は、 [認証トピックガイド](/ja/4.1/topics/auth/) を参照してください。

## `User` モデル

#### `class models.User`

### フィールド

#### `class models.User`

[`User`](#django.contrib.auth.models.User) オブジェクトには、以下のフィールドがあります:

#### `username`

必須です。150 文字以下です。英数字のほか、`_`、`@`、`+`、`.`、`-` が使えます。

`max_length` は多くの状況で十分のはずです。もしより長い文字数が必要な場合は、[独自のユーザモデル](/ja/4.1/topics/auth/customizing/#specifying-custom-user-model) を参照してください。`utf8mb4` エンコーディングで MySQL を使っている場合は (適切な Unicode をサポートするために推奨されています)、最大でも `max_length=191` としてください。なぜなら、MySQL は、でおフォルトでは 191 文字まででしかユニークインデックスを作成できないからです。

#### `first_name`

Optional ([`blank=True`](/ja/4.1/ref/models/fields/#django.db.models.Field.blank)). 150
characters or fewer.

#### `last_name`

Optional ([`blank=True`](/ja/4.1/ref/models/fields/#django.db.models.Field.blank)). 150
characters or fewer.

#### `email`

Optional ([`blank=True`](/ja/4.1/ref/models/fields/#django.db.models.Field.blank)). Email
address.

#### `password`

必須です。パスワードのハッシュであり、パスワードについてのメタデータでもあります。(Django は生のパスワードを保管しません。) 生のパスワードは、任意の長さで、あらゆる文字を使用可能です。詳しくは [password documentation](/ja/4.1/topics/auth/passwords/) を参照してください。

#### `groups`

[`Group`](#django.contrib.auth.models.Group) への多対多のリレーションシップです。

#### `user_permissions`

[`Permission`](#django.contrib.auth.models.Permission) への多対多のリレーションシップです。

#### `is_staff`

真偽値です。ユーザが admin サイトにアクセスできるかどうかを指定します。

#### `is_active`

真偽値です。 このユーザアカウントをアクティブと見なすかどうかを指定します。 アカウントを削除するのではなく、このフラグを `False` に設定することをお勧めします。 そうすれば、アプリケーションに外部キーがある場合でも、外部キーが破損しません。

This doesn't necessarily control whether or not the user can log in.
Authentication backends aren't required to check for the `is_active`
flag but the default backend
([`ModelBackend`](#django.contrib.auth.backends.ModelBackend)) and the
[`RemoteUserBackend`](#django.contrib.auth.backends.RemoteUserBackend) do. You can
use [`AllowAllUsersModelBackend`](#django.contrib.auth.backends.AllowAllUsersModelBackend)
or [`AllowAllUsersRemoteUserBackend`](#django.contrib.auth.backends.AllowAllUsersRemoteUserBackend)
if you want to allow inactive users to login. In this case, you'll also
want to customize the
[`AuthenticationForm`](/ja/4.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm) used by the
[`LoginView`](/ja/4.1/topics/auth/default/#django.contrib.auth.views.LoginView) as it rejects inactive
users. Be aware that the permission-checking methods such as
[`has_perm()`](#django.contrib.auth.models.User.has_perm) and the
authentication in the Django admin all return `False` for inactive
users.

#### `is_superuser`

真偽値です。明示的にアサインすることなく全てのパーミッションを持たせるかどうかを指定します。

#### `last_login`

ユーザーが最後にログインした日時です。

#### `date_joined`

いつアカウントが作成されたかを示す日時です。アカウントが作成されたとき、デフォルトでは現在の日時がセットされます。

### 属性

#### `class models.User`

#### `is_authenticated`

(`AnonymousUser.is_authenticated` が常に `False` なのとは対照的に) 常に `True` の読み取り専用属性です。ユーザが認証済みかどうかを知らせる方法です。これはパーミッションという意味ではなく、ユーザーがアクティブかどうか、また有効なセッションがあるかどうかをチェックするわけでもありません。 通常、`request.user` のこの属性をチェックして [`AuthenticationMiddleware`](/ja/4.1/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) (現在ログイン中のユーザを表します) によって格納されているかどうかを調べます。[`User`](#django.contrib.auth.models.User) のインスタンスの場合、この属性は `True` となります。

#### `is_anonymous`

常に `False` の読み取り専用属性です。[`User`](#django.contrib.auth.models.User) オブジェクトと [`AnonymousUser`](#django.contrib.auth.models.AnonymousUser) オブジェクトを区別する方法です。一般的に、[`is_authenticated`](#django.contrib.auth.models.User.is_authenticated) を使う方が好ましいと言えます。

### メソッド

#### `class models.User`

#### `get_username()`

ユーザのユーザ名を返します。`User` モデルはスワップアウトされることがあるので、ユーザ名を直接参照する代わりにこのメソッドを使う必要があります。

#### `get_full_name()`

[`first_name`](#django.contrib.auth.models.User.first_name) と [`last_name`](#django.contrib.auth.models.User.last_name) をスペースでつないだ文字列を返します。

#### `get_short_name()`

[`first_name`](#django.contrib.auth.models.User.first_name) を返します。

#### `set_password(raw_password)`

指定された生の文字列に、ユーザのパスワードをセットし、パスワードのハッシュ処理を行います。[`User`](#django.contrib.auth.models.User) は保存しません。

`raw_password` が `None` のとき、[`set_unusable_password()`](#django.contrib.auth.models.User.set_unusable_password) が使われるのと同じように、パスワードは使用に適さないパスワードになります。

#### `check_password(raw_password)`

与えられた生の文字列が、ユーザに対して正しいパスワードであれば `True` を返します。 (比較する際にはパスワードハッシュを処理します。)

#### `set_unusable_password()`

ユーザにパスワードが設定されていないものとしてマークします。これは、パスワードに空の文字列を付けることと同じではありません。ユーザに対する [`check_password()`](#django.contrib.auth.models.User.check_password) は `True` を返しません。[`User`](#django.contrib.auth.models.User) オブジェクトを保存しません。

アプリケーションの認証が LDAP ディレクトリなどの既存の外部ソースに対して行われている場合は、これが必要になることがあります。

#### `has_usable_password()`

ユーザに対して [`set_unusable_password()`](#django.contrib.auth.models.User.set_unusable_password) が呼ばれている場合、`False` を返します。

#### `get_user_permissions(obj=None)`

Returns a set of permission strings that the user has directly.

If `obj` is passed in, only returns the user permissions for this
specific object.

#### `get_group_permissions(obj=None)`

ユーザがグループを通して持つパーミッションの文字列のセットを返します。

`obj` が渡されたとき、指定されたオブジェクトに対するグループパーミッションのみを返します。

#### `get_all_permissions(obj=None)`

ユーザがグループおよびユーザパーミッションを通して持つパーミッションの文字列のセットを返します。

`obj` が渡された場合、指定されたオブジェクトに対するパーミッションのみを返します。

#### `has_perm(perm, obj=None)`

Returns `True` if the user has the specified permission, where perm
is in the format `"<app label>.<permission codename>"`. (see
documentation on [permissions](/ja/4.1/topics/auth/default/#topic-authorization)). If the user is
inactive, this method will always return `False`. For an active
superuser, this method will always return `True`.

`obj` が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。

#### `has_perms(perm_list, obj=None)`

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

`obj` が渡された場合、このメソッドは指定されたオブジェクトに対してパーミッションのチェックを行い、モデルに対しては行いません。

#### `has_module_perms(package_name)`

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`.

#### `email_user(subject, message, from_email=None, **kwargs)`

ユーザに E メール送信します。`from_email` が `None` の場合、Django は [`DEFAULT_FROM_EMAIL`](/ja/4.1/ref/settings/#std-setting-DEFAULT_FROM_EMAIL) を使用します。全ての `**kwargs` は元となる [`send_mail()`](/ja/4.1/topics/email/#django.core.mail.send_mail) 呼び出しに渡されます。

### マネージャメソッド

#### `class models.UserManager`

[`User`](#django.contrib.auth.models.User) モデルは、([`BaseUserManager`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.BaseUserManager) で提供されるメソッドに加えて) 以下のヘルパーメソッドを有する独自のマネージャを持っています:

#### `create_user(username, email=None, password=None, **extra_fields)`

[`User`](#django.contrib.auth.models.User) を作成、保存して返します。

The [`username`](#django.contrib.auth.models.User.username) and
[`password`](#django.contrib.auth.models.User.password) are set as given. The
domain portion of [`email`](#django.contrib.auth.models.User.email) is
automatically converted to lowercase, and the returned
[`User`](#django.contrib.auth.models.User) object will have
[`is_active`](#django.contrib.auth.models.User.is_active) set to `True`.

If no password is provided,
[`set_unusable_password()`](#django.contrib.auth.models.User.set_unusable_password) will
be called.

The `extra_fields` keyword arguments are passed through to the
[`User`](#django.contrib.auth.models.User)’s `__init__` method to
allow setting arbitrary fields on a [custom user model](/ja/4.1/topics/auth/customizing/#auth-custom-user).

See [Creating users](/ja/4.1/topics/auth/default/#topics-auth-creating-users) for example usage.

#### `create_superuser(username, email=None, password=None, **extra_fields)`

[`create_user()`](#django.contrib.auth.models.UserManager.create_user) と同じですが、[`is_staff`](#django.contrib.auth.models.User.is_staff) と [`is_superuser`](#django.contrib.auth.models.User.is_superuser) を `True` にセットします。

#### `with_perm(perm, is_active=True, include_superusers=True, backend=None, obj=None)`

Returns users that have the given permission `perm` either in the
`"<app label>.<permission codename>"` format or as a
[`Permission`](#django.contrib.auth.models.Permission) instance. Returns an
empty queryset if no users who have the `perm` found.

If `is_active` is `True` (default), returns only active users, or
if `False`, returns only inactive users. Use `None` to return all
users irrespective of active state.

If `include_superusers` is `True` (default), the result will
include superusers.

If `backend` is passed in and it's defined in
[`AUTHENTICATION_BACKENDS`](/ja/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), then this method will use it.
Otherwise, it will use the `backend` in
[`AUTHENTICATION_BACKENDS`](/ja/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), if there is only one, or raise an
exception.

## `AnonymousUser` オブジェクト

#### `class models.AnonymousUser`

[`django.contrib.auth.models.AnonymousUser`](#django.contrib.auth.models.AnonymousUser) は、[`django.contrib.auth.models.User`](#django.contrib.auth.models.User) インターフェースを実装するクラスで、以下の点が異なります。

- [id](/ja/4.1/topics/db/models/#automatic-primary-key-fields) が常に `None` です。
- [`username`](#django.contrib.auth.models.User.username) が常に空の文字列です。
- [`get_username()`](#django.contrib.auth.models.User.get_username) が常に空の文字列を返します。
- [`is_anonymous`](#django.contrib.auth.models.User.is_anonymous) が `False` ではなく `True` です。
- [`is_authenticated`](#django.contrib.auth.models.User.is_authenticated) が `False` ではなく `True` です。
- [`is_staff`](#django.contrib.auth.models.User.is_staff) と [`is_superuser`](#django.contrib.auth.models.User.is_superuser) が常に `False` です。
- [`is_active`](#django.contrib.auth.models.User.is_active) が常に `False` です。
- [`groups`](#django.contrib.auth.models.User.groups) と [`user_permissions`](#django.contrib.auth.models.User.user_permissions) が常に空です。
- [`set_password()`](#django.contrib.auth.models.User.set_password)、[`check_password()`](#django.contrib.auth.models.User.check_password)、[`save()`](/ja/4.1/ref/models/instances/#django.db.models.Model.save)、[`delete()`](/ja/4.1/ref/models/instances/#django.db.models.Model.delete) が [`NotImplementedError`](https://docs.python.org/3/library/exceptions.html#NotImplementedError) を投げます。

In practice, you probably won't need to use
[`AnonymousUser`](#django.contrib.auth.models.AnonymousUser) objects on your own, but
they're used by web requests, as explained in the next section.

## `Permission` モデル

#### `class models.Permission`

### フィールド

[`Permission`](#django.contrib.auth.models.Permission) オブジェクトには以下のフィールドがあります:

#### `class models.Permission`

#### `name`

必須です。255 文字以下です。例: `'Can vote'`。

#### `content_type`

必須です。`django_content_type` データベーステーブルへの参照で、インストールされた各モデルのレコードを含みます。

#### `codename`

必須です。100 文字以下です。例: `'can_vote'`。

### メソッド

他のあらゆる [Django モデル](/ja/4.1/ref/models/instances/) と同じように、 [`Permission`](#django.contrib.auth.models.Permission) オブジェクトも標準的なデータアクセスのメソッドが使えます。

## `Group` モデル

#### `class models.Group`

### フィールド

[`Group`](#django.contrib.auth.models.Group) オブジェクトには以下のフィールドがあります:

#### `class models.Group`

#### `name`

Required. 150 characters or fewer. Any characters are permitted.
Example: `'Awesome Users'`.

#### `permissions`

[`Permission`](#django.contrib.auth.models.Permission) への多対多のフィールドです:

```
group.permissions.set([permission_list])
group.permissions.add(permission, permission, ...)
group.permissions.remove(permission, permission, ...)
group.permissions.clear()
```

## バリデータ

#### `class validators.ASCIIUsernameValidator`

A field validator allowing only ASCII letters and numbers, in addition to
`@`, `.`, `+`, `-`, and `_`.

#### `class validators.UnicodeUsernameValidator`

A field validator allowing Unicode characters, in addition to `@`, `.`,
`+`, `-`, and `_`. The default validator for `User.username`.

## ログインとログアウトのシグナル

認証フレームワークは、ユーザーがログインやログアウトをしたときの通知に使うことができる、以下の [signals](/ja/4.1/topics/signals/) を使用します。

#### `user_logged_in`

ユーザがログインに成功したときに送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  たった今ログインしたユーザのクラスです。

**`request`**

  現在の [`HttpRequest`](/ja/4.1/ref/request-response/#django.http.HttpRequest) インスタンスです。

**`user`**

  たった今ログインしたユーザのインスタンスです。

#### `user_logged_out`

logout メソッドが呼ばれたときに送信されます。

**`sender`**

  上記の通り: たった今ログアウトしたユーザのクラス、もしくはユーザが認証されなかった場合は `None` となります。

**`request`**

  現在の [`HttpRequest`](/ja/4.1/ref/request-response/#django.http.HttpRequest) インスタンスです。

**`user`**

  たった今ログアウトしたユーザのインスタンスか、ユーザが認証されなかった場合は `None` です。

#### `user_login_failed`

ユーザがログインに失敗したときに送信されます。

**`sender`**

  認証のために使われるモジュールの名前です。

**`credentials`**

  [`authenticate()`](/ja/4.1/topics/auth/default/#django.contrib.auth.authenticate) か独自の認証バックエンドに渡されたユーザ資格情報を含む、キーワード引数のディクショナリです。'sensitive' パターンのセットに一致する (パスワードを含んだ) 資格情報は、シグナルの一部として明確には送信されません。

**`request`**

  The [`HttpRequest`](/ja/4.1/ref/request-response/#django.http.HttpRequest) object, if one was provided to
  [`authenticate()`](/ja/4.1/topics/auth/default/#django.contrib.auth.authenticate).

## 認証のバックエンド

このセクションでは、Django に付属する認証バックエンドについて詳しく説明します。 使用方法と独自の認証バックエンドの作成方法については、[ユーザ認証ガイド](/ja/4.1/topics/auth/) の [他の認証ソースのセクション](/ja/4.1/topics/auth/customizing/#authentication-backends) を参照してください。

### 利用可能な認証バックエンド

以下のバックエンドが [`django.contrib.auth.backends`](#module-django.contrib.auth.backends) 内で利用可能です:

#### `class BaseBackend`

A base class that provides default implementations for all required
methods. By default, it will reject any user and provide no permissions.

#### `get_user_permissions(user_obj, obj=None)`

Returns an empty set.

#### `get_group_permissions(user_obj, obj=None)`

Returns an empty set.

#### `get_all_permissions(user_obj, obj=None)`

Uses [`get_user_permissions()`](#django.contrib.auth.backends.BaseBackend.get_user_permissions) and [`get_group_permissions()`](#django.contrib.auth.backends.BaseBackend.get_group_permissions) to
get the set of permission strings the `user_obj` has.

#### `has_perm(user_obj, perm, obj=None)`

Uses [`get_all_permissions()`](#django.contrib.auth.backends.BaseBackend.get_all_permissions) to check if `user_obj` has the
permission string `perm`.

#### `class ModelBackend`

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](/ja/4.1/topics/auth/customizing/)).

It also handles the default permissions model as defined for
[`User`](#django.contrib.auth.models.User) and
[`PermissionsMixin`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.PermissionsMixin).

[`has_perm()`](#django.contrib.auth.backends.ModelBackend.has_perm), [`get_all_permissions()`](#django.contrib.auth.backends.ModelBackend.get_all_permissions), [`get_user_permissions()`](#django.contrib.auth.backends.ModelBackend.get_user_permissions),
and [`get_group_permissions()`](#django.contrib.auth.backends.ModelBackend.get_group_permissions) allow an object to be passed as a
parameter for object-specific permissions, but this backend does not
implement them other than returning an empty set of permissions if
`obj is not None`.

[`with_perm()`](#django.contrib.auth.backends.ModelBackend.with_perm) also allows an object to be passed as a parameter, but
unlike others methods it returns an empty queryset if `obj is not None`.

#### `authenticate(request, username=None, password=None, **kwargs)`

Tries to authenticate `username` with `password` by calling
[`User.check_password`](#django.contrib.auth.models.User.check_password). If no `username`
is provided, it tries to fetch a username from `kwargs` using the
key [`CustomUser.USERNAME_FIELD`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD). Returns an
authenticated user or `None`.

`request` は [`HttpRequest`](/ja/4.1/ref/request-response/#django.http.HttpRequest) で、  [`authenticate()`](/ja/4.1/topics/auth/default/#django.contrib.auth.authenticate) が提供されていない場合 `None`  となる可能性があります。(バックエンドでこれを通過するため).

#### `get_user_permissions(user_obj, obj=None)`

Returns the set of permission strings the `user_obj` has from their
own user permissions. Returns an empty set if
[`is_anonymous`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.is_anonymous) or
[`is_active`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active) is `False`.

#### `get_group_permissions(user_obj, obj=None)`

Returns the set of permission strings the `user_obj` has from the
permissions of the groups they belong. Returns an empty set if
[`is_anonymous`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.is_anonymous) or
[`is_active`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active)  is `False`.

#### `get_all_permissions(user_obj, obj=None)`

Returns the set of permission strings the `user_obj` has, including both
user permissions and group permissions. Returns an empty set if
[`is_anonymous`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.is_anonymous) or
[`is_active`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active) is `False`.

#### `has_perm(user_obj, perm, obj=None)`

Uses [`get_all_permissions()`](#django.contrib.auth.backends.ModelBackend.get_all_permissions) to check if `user_obj` has the
permission string `perm`. Returns `False` if the user is not
[`is_active`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active).

#### `has_module_perms(user_obj, app_label)`

Returns whether the `user_obj` has any permissions on the app
`app_label`.

#### `user_can_authenticate()`

Returns whether the user is allowed to authenticate. To match the
behavior of [`AuthenticationForm`](/ja/4.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm)
which [`prohibits inactive users from logging in`](/ja/4.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed),
this method returns `False` for users with [`is_active=False`](#django.contrib.auth.models.User.is_active). Custom user models that
don't have an [`is_active`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active)
field are allowed.

#### `with_perm(perm, is_active=True, include_superusers=True, obj=None)`

Returns all active users who have the permission `perm` either in
the form of `"<app label>.<permission codename>"` or a
[`Permission`](#django.contrib.auth.models.Permission) instance. Returns an
empty queryset if no users who have the `perm` found.

If `is_active` is `True` (default), returns only active users, or
if `False`, returns only inactive users. Use `None` to return all
users irrespective of active state.

If `include_superusers` is `True` (default), the result will
include superusers.

#### `class AllowAllUsersModelBackend`

Same as [`ModelBackend`](#django.contrib.auth.backends.ModelBackend) except that it doesn't reject inactive users
because [`user_can_authenticate()`](#django.contrib.auth.backends.ModelBackend.user_can_authenticate) always returns `True`.

When using this backend, you'll likely want to customize the
[`AuthenticationForm`](/ja/4.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm) used by the
[`LoginView`](/ja/4.1/topics/auth/default/#django.contrib.auth.views.LoginView) by overriding the
[`confirm_login_allowed()`](/ja/4.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed)
method as it rejects inactive users.

#### `class RemoteUserBackend`

Use this backend to take advantage of external-to-Django-handled
authentication.  It authenticates using usernames passed in
[`request.META['REMOTE_USER']`](/ja/4.1/ref/request-response/#django.http.HttpRequest.META).  See
the [Authenticating against REMOTE\_USER](/ja/4.1/howto/auth-remote-user/)
documentation.

If you need more control, you can create your own authentication backend
that inherits from this class and override these attributes or methods:

#### `create_unknown_user`

`True` or `False`. Determines whether or not a user object is
created if not already in the database  Defaults to `True`.

#### `authenticate(request, remote_user)`

The username passed as `remote_user` is considered trusted. This
method returns the user object with the given username, creating a new
user object if [`create_unknown_user`](#django.contrib.auth.backends.RemoteUserBackend.create_unknown_user) is
`True`.

Returns `None` if [`create_unknown_user`](#django.contrib.auth.backends.RemoteUserBackend.create_unknown_user) is
`False` and a `User` object with the given username is not found in
the database.

`request` は [`HttpRequest`](/ja/4.1/ref/request-response/#django.http.HttpRequest) で、  [`authenticate()`](/ja/4.1/topics/auth/default/#django.contrib.auth.authenticate) が提供されていない場合 `None`  となる可能性があります。(バックエンドでこれを通過するため).

#### `clean_username(username)`

Performs any cleaning on the `username` (e.g. stripping LDAP DN
information) prior to using it to get or create a user object. Returns
the cleaned username.

#### `configure_user(request, user, created=True)`

Configures the user on each authentication attempt. This method is
called immediately after fetching or creating the user being
authenticated, 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.

The setup can be performed either once when the user is created
(`created` is `True`) or on existing users (`created` is
`False`) as a way of synchronizing attributes between the remote and
the local systems.

`request` は [`HttpRequest`](/ja/4.1/ref/request-response/#django.http.HttpRequest) で、  [`authenticate()`](/ja/4.1/topics/auth/default/#django.contrib.auth.authenticate) が提供されていない場合 `None`  となる可能性があります。(バックエンドでこれを通過するため).

> **Changed in Django 4.1**
>
> The `created` argument was added.

#### `user_can_authenticate()`

Returns whether the user is allowed to authenticate. This method
returns `False` for users with [`is_active=False`](#django.contrib.auth.models.User.is_active). Custom user models that
don't have an [`is_active`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.is_active)
field are allowed.

#### `class AllowAllUsersRemoteUserBackend`

Same as [`RemoteUserBackend`](#django.contrib.auth.backends.RemoteUserBackend) except that it doesn't reject inactive
users because [`user_can_authenticate`](#django.contrib.auth.backends.RemoteUserBackend.user_can_authenticate) always
returns `True`.

## Utility functions

#### `get_user(request)`

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`](/ja/4.1/ref/settings/#std-setting-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()`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash)
method. If the verification fails and [`SECRET_KEY_FALLBACKS`](/ja/4.1/ref/settings/#std-setting-SECRET_KEY_FALLBACKS) are
provided, it verifies the session against each fallback key using
[`get_session_auth_fallback_hash()`](/ja/4.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_fallback_hash).

Returns an instance of [`AnonymousUser`](#django.contrib.auth.models.AnonymousUser)
if the authentication backend stored in the session is no longer in
[`AUTHENTICATION_BACKENDS`](/ja/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS), if a user isn't returned by the
backend's `get_user()` method, or if the session auth hash doesn't
validate.

> **Changed in Django 4.1.8**
>
> Fallback verification with [`SECRET_KEY_FALLBACKS`](/ja/4.1/ref/settings/#std-setting-SECRET_KEY_FALLBACKS) was added.