django.contrib.auth —Djangoのドキュメント

提供：Dev Guides
< DjangoDjango/docs/3.2.x/ref/contrib/auth
移動先:案内、検索

django.contrib.auth

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

Userモデル

class models.User

田畑

class models.User

User オブジェクトには次のフィールドがあります。

username

必須。 150文字以下。 ユーザー名には、英数字、_、@、+、.、および-文字を含めることができます。

max_lengthは、多くのユースケースに十分なはずです。 より長い長さが必要な場合は、カスタムユーザーモデルを使用してください。 utf8mb4エンコーディング（適切なUnicodeサポートに推奨）でMySQLを使用する場合、MySQLはデフォルトで191文字の一意のインデックスしか作成できないため、最大でmax_length=191を指定します。

first_name

オプション（ blank = True ）。 150文字以下。

バージョン3.1で変更： max_lengthが30文字から150文字に増加しました。

last_name

オプション（ blank = True ）。 150文字以下。

email

オプション（ blank = True ）。 電子メールアドレス。

password

必須。 パスワードのハッシュとメタデータ。 （Djangoは生のパスワードを保存しません。）生のパスワードは任意の長さにすることができ、任意の文字を含めることができます。 パスワードのドキュメントを参照してください。

groups

グループとの多対多の関係

user_permissions

許可との多対多の関係

is_staff

ブール値。 このユーザーが管理サイトにアクセスできるかどうかを指定します。

is_active

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

これは、ユーザーがログインできるかどうかを必ずしも制御するものではありません。 認証バックエンドはis_activeフラグをチェックする必要はありませんが、デフォルトのバックエンド（ ModelBackend ）と RemoteUserBackend はチェックします。 非アクティブなユーザーのログインを許可する場合は、 AllowAllUsersModelBackend または AllowAllUsersRemoteUserBackend を使用できます。 この場合、 LoginView が非アクティブなユーザーを拒否するために使用する AuthenticationForm もカスタマイズする必要があります。 has_perm（）などの権限チェックメソッドとDjango管理者の認証はすべて、非アクティブなユーザーに対してFalseを返すことに注意してください。

is_superuser

ブール値。 このユーザーが明示的に割り当てずにすべての権限を持っていることを指定します。

last_login

ユーザーの最後のログインの日時。

date_joined

アカウントが作成された日時を指定する日時。 アカウントの作成時に、デフォルトで現在の日付/時刻に設定されます。


属性

class models.User
is_authenticated

常にTrueである読み取り専用属性（常にFalseであるAnonymousUser.is_authenticatedとは対照的）。 これは、ユーザーが認証されているかどうかを確認する方法です。 これは、権限を意味するものではなく、ユーザーがアクティブであるか、有効なセッションを持っているかどうかを確認しません。 通常、request.userでこの属性をチェックして、 AuthenticationMiddleware （現在ログインしているユーザーを表す）によって入力されているかどうかを確認しますが、この属性がTrue任意のユーザーインスタンス。

is_anonymous

常にFalseである読み取り専用属性。 これは、 User オブジェクトと AnonymousUser オブジェクトを区別する方法です。 通常、この属性よりも is_authenticated を使用することをお勧めします。


メソッド

class models.User
get_username()

ユーザーのユーザー名を返します。 Userモデルはスワップアウトできるため、ユーザー名属性を直接参照するのではなく、このメソッドを使用する必要があります。

get_full_name()

first_name と last_name を間にスペースを入れて返します。

get_short_name()

first_name を返します。

set_password(raw_password)

パスワードのハッシュを処理しながら、ユーザーのパスワードを指定された生の文字列に設定します。 User オブジェクトを保存しません。

raw_passwordがNoneの場合、 set_unusable_password（）が使用されたかのように、パスワードは使用できないパスワードに設定されます。

check_password(raw_password)

指定された生の文字列がユーザーの正しいパスワードである場合、Trueを返します。 （これにより、比較を行う際のパスワードハッシュが処理されます。）

set_unusable_password()

パスワードが設定されていないことをユーザーにマークします。 これは、パスワードに空白の文字列を使用することと同じではありません。 このユーザーの check_password（）は、Trueを返すことはありません。 User オブジェクトを保存しません。

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

has_usable_password()

このユーザーに対して set_unusable_password（）が呼び出された場合、Falseを返します。

get_user_permissions(obj=None)

ユーザーが直接持っている一連のアクセス許可文字列を返します。

objが渡された場合、この特定のオブジェクトのユーザー権限のみを返します。

get_group_permissions(obj=None)

グループを通じて、ユーザーが持っている一連のアクセス許可文字列を返します。

objが渡された場合、この特定のオブジェクトのグループ権限のみを返します。

get_all_permissions(obj=None)

グループ権限とユーザー権限の両方を通じて、ユーザーが持っている権限文字列のセットを返します。

objが渡された場合、この特定のオブジェクトのアクセス許可のみが返されます。

has_perm(perm, obj=None)

ユーザーが指定された権限を持っている場合、Trueを返します。ここで、permは"<app label>.<permission codename>"の形式です。 （権限に関するドキュメントを参照してください）。 ユーザーが非アクティブの場合、このメソッドは常にFalseを返します。 アクティブなスーパーユーザーの場合、このメソッドは常にTrueを返します。

objが渡された場合、このメソッドはモデルのアクセス許可をチェックしませんが、この特定のオブジェクトのアクセス許可をチェックします。

has_perms(perm_list, obj=None)

ユーザーが指定された各権限を持っている場合、Trueを返します。各権限は、"<app label>.<permission codename>"の形式です。 ユーザーが非アクティブの場合、このメソッドは常にFalseを返します。 アクティブなスーパーユーザーの場合、このメソッドは常にTrueを返します。

objが渡された場合、このメソッドはモデルの権限ではなく、特定のオブジェクトの権限を確認します。

has_module_perms(package_name)

ユーザーが指定されたパッケージ（Djangoアプリラベル）で何らかの権限を持っている場合、Trueを返します。 ユーザーが非アクティブの場合、このメソッドは常にFalseを返します。 アクティブなスーパーユーザーの場合、このメソッドは常にTrueを返します。

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

ユーザーにメールを送信します。 from_emailがNoneの場合、Djangoは：setting： `DEFAULT_FROM_EMAIL` を使用します。 **kwargsはすべて、基になる send_mail（）呼び出しに渡されます。


マネージャーメソッド

class models.UserManager

User モデルには、（ BaseUserManager によって提供されるメソッドに加えて）次のヘルパーメソッドを持つカスタムマネージャーがあります。

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

User を作成、保存、および返します。

ユーザー名とパスワードは指定どおりに設定されます。 email のドメイン部分は自動的に小文字に変換され、返される User オブジェクトの is_active はTrueに設定されます。

パスワードが指定されていない場合、 set_unusable_password（）が呼び出されます。

extra_fieldsキーワード引数は User の__init__メソッドに渡され、カスタムユーザーモデルに任意のフィールドを設定できるようになります。

使用例については、ユーザーの作成を参照してください。

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

create_user（）と同じですが、 is_staff および is_superuser をTrueに設定します。

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

"<app label>.<permission codename>"形式または Permission インスタンスとして指定された権限permを持つユーザーを返します。 permを持つユーザーが見つからない場合は、空のクエリセットを返します。

is_activeがTrue（デフォルト）の場合、アクティブなユーザーのみを返します。Falseの場合、非アクティブなユーザーのみを返します。 Noneを使用して、アクティブ状態に関係なくすべてのユーザーを返します。

include_superusersがTrue（デフォルト）の場合、結果にはスーパーユーザーが含まれます。

backendが渡され、：setting： `AUTHENTICATION_BACKENDS` で定義されている場合、このメソッドはそれを使用します。 それ以外の場合は、：setting： `AUTHENTICATION_BACKENDS` のbackendを使用するか、例外が発生します。


AnonymousUserオブジェクト

class models.AnonymousUser
django.contrib.auth.models.AnonymousUser は、 django.contrib.auth.models.User インターフェースを実装するクラスですが、次の違いがあります。

実際には、おそらく AnonymousUser オブジェクトを自分で使用する必要はありませんが、次のセクションで説明するように、これらはWeb要求によって使用されます。


Permissionモデル

class models.Permission

田畑

Permission オブジェクトには、次のフィールドがあります。

class models.Permission
name

必須。 255文字以下。 例：'Can vote'。

content_type

必須。 django_content_typeデータベーステーブルへの参照。これには、インストールされている各モデルのレコードが含まれています。

codename

必須。 100文字以下。 例：'can_vote'。


メソッド

Permission オブジェクトには、他の Djangoモデルと同様の標準のデータアクセス方法があります。


Groupモデル

class models.Group

田畑

Group オブジェクトには次のフィールドがあります。

class models.Group
name

必須。 150文字以下。 すべての文字が許可されます。 例：'Awesome Users'。

permissions

許可への多対多フィールド：

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


バリデーター

class validators.ASCIIUsernameValidator
@、.、+、-、および_に加えて、ASCII文字と数字のみを許可するフィールドバリデーター。
class validators.UnicodeUsernameValidator
@、.、+、-、および_に加えて、Unicode文字を許可するフィールドバリデーター。 User.usernameのデフォルトのバリデーター。


ログインおよびログアウト信号

認証フレームワークは、ユーザーがログインまたはログアウトしたときの通知に使用できる次のシグナルを使用します。

user_logged_in()

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

このシグナルで送信される引数：

sender

ログインしたばかりのユーザーのクラス。

request

現在の HttpRequest インスタンス。

user

ログインしたばかりのユーザーインスタンス。

user_logged_out()
ログアウトメソッドが呼び出されたときに送信されます。
sender
上記のように：ログアウトしたばかりのユーザーのクラス、またはユーザーが認証されていない場合はNone。
request
現在の HttpRequest インスタンス。
user
ログアウトしたばかりのユーザーインスタンス、またはユーザーが認証されていない場合はNone。
user_login_failed()
ユーザーが正常にログインできなかった場合に送信されます
sender
認証に使用されるモジュールの名前。
credentials
authenticate（）または独自のカスタム認証バックエンドに渡されたユーザー資格情報を含むキーワード引数の辞書。 一連の「機密」パターンに一致するクレデンシャル（パスワードを含む）は、シグナルの一部として平文で送信されません。
request
HttpRequest オブジェクト（ authenticate（）に提供された場合）。


認証バックエンド

このセクションでは、Djangoに付属する認証バックエンドについて詳しく説明します。 それらの使用方法と独自の認証バックエンドの作成方法については、ユーザー認証ガイドのその他の認証ソースセクションを参照してください。

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

django.contrib.auth.backends では次のバックエンドを利用できます。

class BaseBackend

必要なすべてのメソッドのデフォルトの実装を提供する基本クラス。 デフォルトでは、ユーザーを拒否し、権限を提供しません。

get_user_permissions(user_obj, obj=None)

空のセットを返します。

get_group_permissions(user_obj, obj=None)

空のセットを返します。

get_all_permissions(user_obj, obj=None)

get_user_permissions（）および get_group_permissions（）を使用して、user_objが持つアクセス許可文字列のセットを取得します。

has_perm(user_obj, perm, obj=None)

get_all_permissions（）を使用して、user_objにアクセス許可文字列permがあるかどうかを確認します。

class ModelBackend

これは、Djangoで使用されるデフォルトの認証バックエンドです。 ユーザー識別子とパスワードで構成される資格情報を使用して認証します。 Djangoのデフォルトのユーザーモデルの場合、ユーザー識別子はユーザー名であり、カスタムユーザーモデルの場合は、USERNAME_FIELDで指定されたフィールドです（ユーザーのカスタマイズと認証を参照）。

また、 User および PermissionsMixin に対して定義されているデフォルトのアクセス許可モデルも処理します。

has_perm（）、 get_all_permissions（）、 get_user_permissions（）、および get_group_permissions（）を使用すると、オブジェクトをパラメーターとして渡すことができます。オブジェクト固有のアクセス許可。ただし、obj is not Noneの場合、このバックエンドは空のアクセス許可セットを返す以外は実装しません。

with_perm（）では、オブジェクトをパラメーターとして渡すこともできますが、他のメソッドとは異なり、obj is not Noneの場合は空のクエリセットを返します。

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

User.check_password を呼び出して、passwordでusernameの認証を試みます。 usernameが指定されていない場合、キー CustomUser.USERNAME_FIELD を使用して、kwargsからユーザー名をフェッチしようとします。 認証されたユーザーまたはNoneを返します。

requestは HttpRequest であり、 authenticate（）（バックエンドに渡される）に提供されなかった場合はNoneになる可能性があります。

get_user_permissions(user_obj, obj=None)

user_objが独自のユーザー権限から持っている権限文字列のセットを返します。 is_anonymous または is_active がFalseの場合、空のセットを返します。

get_group_permissions(user_obj, obj=None)

user_objが属するグループのアクセス許可から、アクセス許可文字列のセットを返します。 is_anonymous または is_active がFalseの場合、空のセットを返します。

get_all_permissions(user_obj, obj=None)

user_objが持つ権限文字列のセットを返します。これには、ユーザー権限とグループ権限の両方が含まれます。 is_anonymous または is_active がFalseの場合、空のセットを返します。

has_perm(user_obj, perm, obj=None)

get_all_permissions（）を使用して、user_objにアクセス許可文字列permがあるかどうかを確認します。 ユーザーが is_active でない場合、Falseを返します。

has_module_perms(user_obj, app_label)

user_objにアプリapp_labelに対する権限があるかどうかを返します。

user_can_authenticate()

ユーザーが認証を許可されているかどうかを返します。 が非アクティブなユーザーのへのログインを禁止する AuthenticationForm の動作と一致させるために、このメソッドは is_active = False のユーザーに対してFalseを返します。 is_active フィールドを持たないカスタムユーザーモデルが許可されます。

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

"<app label>.<permission codename>"または Permission インスタンスのいずれかの形式で権限permを持つすべてのアクティブユーザーを返します。 permを持つユーザーが見つからない場合は、空のクエリセットを返します。

is_activeがTrue（デフォルト）の場合、アクティブなユーザーのみを返します。Falseの場合、非アクティブなユーザーのみを返します。 Noneを使用して、アクティブ状態に関係なくすべてのユーザーを返します。

include_superusersがTrue（デフォルト）の場合、結果にはスーパーユーザーが含まれます。

class AllowAllUsersModelBackend

user_can_authenticate（）は常にTrueを返すため、非アクティブなユーザーを拒否しないことを除いて、 ModelBackend と同じです。

このバックエンドを使用する場合は、[X131X] LoginView で使用される AuthenticationForm をカスタマイズして、 confirm_login_allowed（）メソッドをオーバーライドして非アクティブなユーザーを拒否することをお勧めします。

class RemoteUserBackend

このバックエンドを使用して、外部からDjangoで処理される認証を利用します。 request.META [' REMOTE_USER '] で渡されたユーザー名を使用して認証します。 REMOTE_USER に対する認証のドキュメントを参照してください。

さらに制御が必要な場合は、このクラスから継承する独自の認証バックエンドを作成し、次の属性またはメソッドをオーバーライドできます。

create_unknown_user

TrueまたはFalse。 データベースにまだ存在しない場合にユーザーオブジェクトを作成するかどうかを決定します。デフォルトはTrueです。

authenticate(request, remote_user)

remote_userとして渡されたユーザー名は信頼できると見なされます。 このメソッドは、指定されたユーザー名のユーザーオブジェクトを返し、 create_unknown_user がTrueの場合に新しいユーザーオブジェクトを作成します。

create_unknown_user がFalseであり、指定されたユーザー名のUserオブジェクトがデータベースに見つからない場合、Noneを返します。

requestは HttpRequest であり、 authenticate（）（バックエンドに渡される）に提供されなかった場合はNoneになる可能性があります。

clean_username(username)

usernameのクリーニングを実行します（例： LDAP DN情報を削除してから、ユーザーオブジェクトを取得または作成します。 クリーンアップされたユーザー名を返します。

configure_user(request, user)

新しく作成されたユーザーを構成します。 このメソッドは、新しいユーザーが作成された直後に呼び出され、LDAPディレクトリの属性に基づいてユーザーのグループを設定するなどのカスタムセットアップアクションを実行するために使用できます。 ユーザーオブジェクトを返します。

requestは HttpRequest であり、 authenticate（）（バックエンドに渡される）に提供されなかった場合はNoneになる可能性があります。

user_can_authenticate()

ユーザーが認証を許可されているかどうかを返します。 このメソッドは、 is_active = False のユーザーに対してFalseを返します。 is_active フィールドを持たないカスタムユーザーモデルが許可されます。

class AllowAllUsersRemoteUserBackend
user_can_authenticate は常にTrueを返すため、非アクティブなユーザーを拒否しないことを除いて、 RemoteUserBackend と同じです。


ユーティリティ機能

get_user(request)

指定されたrequestのセッションに関連付けられているユーザーモデルインスタンスを返します。

セッションに保存されている認証バックエンドが：setting： `AUTHENTICATION_BACKENDS` に存在するかどうかを確認します。 その場合、バックエンドのget_user()メソッドを使用してユーザーモデルインスタンスを取得し、ユーザーモデルの get_session_auth_hash（）メソッドを呼び出してセッションを検証します。

セッションに保存されている認証バックエンドが：setting： `AUTHENTICATION_BACKENDS` にない場合、ユーザーがバックエンドの [によって返されない場合、 AnonymousUser のインスタンスを返します。 X205X]メソッド、またはセッション認証ハッシュが検証されない場合。



「https://www.finddevguides.com/index.php?title=Django/docs/3.2.x/ref/contrib/auth&oldid=96162」から取得
Powered by MediaWiki