Django認証システムの使用—Djangoドキュメント

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

Django認証システムの使用

このドキュメントでは、デフォルト構成でのDjangoの認証システムの使用法について説明します。 この構成は、最も一般的なプロジェクトのニーズに対応するように進化し、かなり広範囲のタスクを処理し、パスワードとアクセス許可を注意深く実装しています。 認証の必要性がデフォルトと異なるプロジェクトの場合、Djangoは認証の広範な拡張とカスタマイズをサポートします。

Django認証は、認証と承認の両方を一緒に提供し、これらの機能がいくらか結合されているため、一般に認証システムと呼ばれます。

Userオブジェクト

User オブジェクトは認証システムの中核です。 これらは通常、サイトを操作する人々を表し、アクセスの制限、ユーザープロファイルの登録、コンテンツの作成者への関連付けなどを可能にするために使用されます。 Djangoの認証フレームワークに存在するユーザーのクラスは1つだけです。つまり、 ' superusers ' またはadmin ' staff ' ユーザーは、特別な属性が設定された単なるユーザーオブジェクトです。 、異なるクラスのユーザーオブジェクトではありません。

デフォルトユーザーの主な属性は次のとおりです。

完全なリファレンスについては、完全なAPIドキュメントを参照してください。以下のドキュメントは、よりタスク指向です。

ユーザーの作成

ユーザーを作成する最も直接的な方法は、付属の create_user（）ヘルパー関数を使用することです。 

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', '[email protected]', 'johnpassword')

# At this point, user is a User object that has already been saved
# to the database. You can continue to change its attributes
# if you want to change other fields.
>>> user.last_name = 'Lennon'
>>> user.save()

Django管理者がインストールされている場合は、ユーザーをインタラクティブに作成することもできます。


スーパーユーザーの作成

：djadmin： `createsuperuser` コマンドを使用してスーパーユーザーを作成します。 

$ python manage.py createsuperuser --username=joe [email protected]

パスワードの入力を求められます。 入力すると、すぐにユーザーが作成されます。 --usernameまたは--emailオプションを省略した場合、それらの値の入力を求めるプロンプトが表示されます。


パスワードの変更

Djangoは、生の（クリアテキスト）パスワードをユーザーモデルに保存せず、ハッシュのみを保存します（詳細については、パスワードの管理方法に関するドキュメントを参照してください）。 このため、ユーザーのパスワード属性を直接操作しようとしないでください。 これが、ユーザーを作成するときにヘルパー関数が使用される理由です。

ユーザーのパスワードを変更するには、いくつかのオプションがあります。

：djadmin： `manage.py changepassword *ユーザー名* ` コマンドラインからユーザーのパスワードを変更する方法を提供します。 特定のユーザーのパスワードを変更するように求められますが、これは2回入力する必要があります。 両方が一致する場合、新しいパスワードはすぐに変更されます。 ユーザーを指定しない場合、コマンドは、ユーザー名が現在のシステムユーザーと一致するパスワードを変更しようとします。

set_password（）を使用して、プログラムでパスワードを変更することもできます。 

>>> from django.contrib.auth.models import User
>>> u = User.objects.get(username='john')
>>> u.set_password('new password')
>>> u.save()

Django管理者がインストールされている場合は、認証システムの管理ページでユーザーのパスワードを変更することもできます。

Djangoは、ユーザーが自分のパスワードを変更できるようにするために使用できるビューおよびフォームも提供します。

ユーザーのパスワードを変更すると、すべてのセッションがログアウトされます。 詳しくは、パスワード変更時のセッション無効化をご覧ください。


ユーザーの認証

authenticate(request=None, **credentials)

authenticate（）を使用して、一連の資格情報を確認します。 クレデンシャルをキーワード引数として受け取り、デフォルトの場合はusernameとpasswordで、各認証バックエンドと照合し、 User オブジェクトを返します。クレデンシャルはバックエンドに対して有効です。 クレデンシャルがどのバックエンドに対しても有効でない場合、またはバックエンドが PermissionDenied を発生させた場合、Noneを返します。 例えば：

from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    # A backend authenticated the credentials
else:
    # No backend authenticated the credentials

requestは、認証バックエンドのauthenticate()メソッドで渡されるオプションの HttpRequest です。

ノート

これは、一連の資格情報を認証するための低レベルの方法です。 たとえば、 RemoteUserMiddleware によって使用されます。 独自の認証システムを作成していない限り、おそらくこれを使用することはありません。 むしろ、ユーザーにログインする方法を探している場合は、 LoginView を使用してください。


権限と承認

Djangoには権限システムが組み込まれています。 特定のユーザーおよびユーザーのグループにアクセス許可を割り当てる方法を提供します。

Django管理サイトで使用されていますが、独自のコードで使用することもできます。

Django管理サイトは次のように権限を使用します：

  • ビューオブジェクトへのアクセスは、そのタイプのオブジェクトの「表示」または「変更」権限を持つユーザーに制限されています。
  • 「追加」フォームを表示してオブジェクトを追加するためのアクセスは、そのタイプのオブジェクトの「追加」権限を持つユーザーに制限されています。
  • 変更リストの表示、「変更」フォームの表示、およびオブジェクトの変更へのアクセスは、そのタイプのオブジェクトの「変更」権限を持つユーザーに制限されています。
  • オブジェクトを削除するためのアクセスは、そのタイプのオブジェクトの「削除」権限を持つユーザーに制限されています。

権限は、オブジェクトのタイプごとだけでなく、特定のオブジェクトインスタンスごとにも設定できます。 has_view_permission（）、 has_add_permission（）、 has_change_permission（）、 has_delete_permission（）メソッドを使用することにより、 ModelAdminが提供しますクラスでは、同じタイプの異なるオブジェクトインスタンスの権限をカスタマイズできます。

User オブジェクトには、groupsとuser_permissionsの2つの多対多フィールドがあります。 User オブジェクトは、他の Djangoモデルと同じ方法で、関連するオブジェクトにアクセスできます。 

myuser.groups.set([group_list])
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions.set([permission_list])
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()

デフォルトの権限

django.contrib.authが：setting： `INSTALLED_APPS` 設定にリストされている場合、追加、変更、削除、表示の4つのデフォルトの権限がで定義されたDjangoモデルごとに作成されます。インストールされているアプリケーションの1つ。

これらの権限は、実行時に作成されます ：djadmin： `manage.py移行 ` ; 初めて走るときmigrate追加後django.contrib.authに ：setting： `INSTALLED_APPS` 、デフォルトの権限は、以前にインストールされたすべてのモデルと、その時点でインストールされている新しいモデルに対して作成されます。 その後、実行するたびに新しいモデルのデフォルトの権限が作成されます ：djadmin： `manage.py移行 ` （権限を作成する関数はに接続されています post_migrate 信号）。

app_label fooとBarという名前のモデルを持つアプリケーションがあるとすると、基本的なアクセス許可をテストするには、次のものを使用する必要があります。

  • 追加：user.has_perm('foo.add_bar')
  • 変更：user.has_perm('foo.change_bar')
  • 削除：user.has_perm('foo.delete_bar')
  • ビュー：user.has_perm('foo.view_bar')

Permission モデルに直接アクセスすることはめったにありません。


グループ

django.contrib.auth.models.Group モデルは、ユーザーを分類する一般的な方法であるため、ユーザーに権限やその他のラベルを適用できます。 ユーザーは任意の数のグループに属することができます。

グループ内のユーザーには、そのグループに付与されたアクセス許可が自動的に付与されます。 たとえば、グループSite editorsに権限can_edit_home_pageがある場合、そのグループ内のすべてのユーザーにその権限があります。

グループは、権限を超えて、ユーザーを分類してラベルや拡張機能を与えるための便利な方法です。 たとえば、グループ'Special users'を作成し、サイトのメンバー専用部分へのアクセスを許可したり、メンバー専用の電子メールメッセージを送信したりできるコードを記述できます。


プログラムで権限を作成する

カスタムパーミッションはモデルのMetaクラス内で定義できますが、パーミッションを直接作成することもできます。 たとえば、myappでBlogPostモデルのcan_publish権限を作成できます。 

from myapp.models import BlogPost
from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(
    codename='can_publish',
    name='Can Publish Posts',
    content_type=content_type,
)

次に、[X61X] 属性を介して User に、またはpermissions属性を介して Group に権限を割り当てることができます。

プロキシモデルには独自のコンテンツタイプが必要です

プロキシモデルの権限を作成する場合は、for_concrete_model=Falseを ContentTypeManager.get_for_model（）に渡して、適切なContentTypeを取得します。 

content_type = ContentType.objects.get_for_model(BlogPostProxy, for_concrete_model=False)

権限のキャッシュ

ModelBackend は、パーミッションチェックのために最初にフェッチする必要があるときに、ユーザーオブジェクトのパーミッションをキャッシュします。 通常、アクセス許可は追加された直後（たとえば、管理者）にチェックされないため、これは通常、要求と応答のサイクルでは問題ありません。 たとえば、テストやビューでアクセス許可を追加してその直後に確認する場合、最も簡単な解決策は、データベースからユーザーを再フェッチすることです。 例えば： 

from django.contrib.auth.models import Permission, User
from django.contrib.contenttypes.models import ContentType
from django.shortcuts import get_object_or_404

from myapp.models import BlogPost

def user_gains_perms(request, user_id):
    user = get_object_or_404(User, pk=user_id)
    # any permission check will cache the current set of permissions
    user.has_perm('myapp.change_blogpost')

    content_type = ContentType.objects.get_for_model(BlogPost)
    permission = Permission.objects.get(
        codename='change_blogpost',
        content_type=content_type,
    )
    user.user_permissions.add(permission)

    # Checking the cached permission set
    user.has_perm('myapp.change_blogpost')  # False

    # Request new instance of User
    # Be aware that user.refresh_from_db() won't clear the cache.
    user = get_object_or_404(User, pk=user_id)

    # Permission cache is repopulated from the database
    user.has_perm('myapp.change_blogpost')  # True

    ...

プロキシモデル

プロキシモデルは、具象モデルとまったく同じように機能します。 権限は、プロキシモデルの独自のコンテンツタイプを使用して作成されます。 プロキシモデルは、サブクラス化する具象モデルの権限を継承しません。 

class Person(models.Model):
    class Meta:
        permissions = [('can_eat_pizzas', 'Can eat pizzas')]

class Student(Person):
    class Meta:
        proxy = True
        permissions = [('can_deliver_pizzas', 'Can deliver pizzas')]

>>> # Fetch the content type for the proxy model.
>>> content_type = ContentType.objects.get_for_model(Student, for_concrete_model=False)
>>> student_permissions = Permission.objects.filter(content_type=content_type)
>>> [p.codename for p in student_permissions]
['add_student', 'change_student', 'delete_student', 'view_student',
'can_deliver_pizzas']
>>> for permission in student_permissions:
...     user.user_permissions.add(permission)
>>> user.has_perm('app.add_person')
False
>>> user.has_perm('app.can_eat_pizzas')
False
>>> user.has_perms(('app.add_student', 'app.can_deliver_pizzas'))
True

Webリクエストでの認証

Djangoは、セッションとミドルウェアを使用して、認証システムをリクエストオブジェクトにフックします。

これらは、現在のユーザーを表すすべてのリクエストに request.user 属性を提供します。 現在のユーザーがログインしていない場合、この属性は AnonymousUser のインスタンスに設定されます。それ以外の場合は、 User のインスタンスになります。

次のように、 is_authenticated でそれらを区別できます。 

if request.user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

ユーザーをログインさせる方法

現在のセッションに接続する認証済みユーザーがいる場合、これは login（）関数を使用して実行されます。

login(request, user, backend=None)

ビューからユーザーにログインするには、 login（）を使用します。 HttpRequest オブジェクトと User オブジェクトを取ります。 login（）は、Djangoのセッションフレームワークを使用して、ユーザーのIDをセッションに保存します。

匿名セッション中のデータセットは、ユーザーがログインした後もセッションに保持されることに注意してください。

この例は、 authenticate（）と login（）の両方を使用する方法を示しています。

from django.contrib.auth import authenticate, login

def my_view(request):
    username = request.POST['username']
    password = request.POST['password']
    user = authenticate(request, username=username, password=password)
    if user is not None:
        login(request, user)
        # Redirect to a success page.
        ...
    else:
        # Return an 'invalid login' error message.
        ...

認証バックエンドの選択

ユーザーがログインすると、ユーザーのIDと認証に使用されたバックエンドがユーザーのセッションに保存されます。 これにより、同じ認証バックエンドが将来のリクエストでユーザーの詳細を取得できるようになります。 セッションに保存する認証バックエンドは、次のように選択されます。

  1. オプションのbackend引数が指定されている場合は、その値を使用します。
  2. user.backend属性の値が存在する場合は、それを使用します。 これにより、 authenticate（）と login（）のペアリングが可能になります。 authenticate（）は、返すユーザーオブジェクトにuser.backend属性を設定します。
  3. ：setting： `AUTHENTICATION_BACKENDS` が1つしかない場合は、backendを使用します。
  4. それ以外の場合は、例外を発生させます。

ケース1と2の場合、backend引数またはuser.backend属性の値は、点線のインポートパス文字列である必要があります（：setting： `AUTHENTICATION_BACKENDS` にあるようなもの）。 ）、実際のバックエンドクラスではありません。


ユーザーをログアウトする方法

logout(request)

django.contrib.auth.login（）を介してログインしたユーザーをログアウトするには、ビュー内で django.contrib.auth.logout（）を使用します。 HttpRequest オブジェクトを受け取り、戻り値はありません。 例：

from django.contrib.auth import logout

def logout_view(request):
    logout(request)
    # Redirect to a success page.

logout（）は、ユーザーがログインしていない場合でもエラーをスローしないことに注意してください。

logout（）を呼び出すと、現在のリクエストのセッションデータが完全に消去されます。 既存のデータはすべて削除されます。 これは、他の人が同じWebブラウザーを使用してログインし、前のユーザーのセッションデータにアクセスできないようにするためです。 ログアウト直後にユーザーが利用できるものをセッションに入れたい場合は、 django.contrib.auth.logout（）を呼び出して後にを実行します。


ログインしたユーザーへのアクセスを制限する

生の方法

ページへのアクセスを制限する生の方法は、 request.user.is_authenticated を確認し、ログインページにリダイレクトすることです。 

from django.conf import settings
from django.shortcuts import redirect

def my_view(request):
    if not request.user.is_authenticated:
        return redirect('%s?next=%s' % (settings.LOGIN_URL, request.path))
    # ...

…またはエラーメッセージを表示します： 

from django.shortcuts import render

def my_view(request):
    if not request.user.is_authenticated:
        return render(request, 'myapp/login_error.html')
    # ...

login_requiredデコレータ

login_required(redirect_field_name='next', login_url=None)

ショートカットとして、便利な login_required（）デコレータを使用できます。

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required（）は次のことを行います。

  • ユーザーがログインしていない場合は、にリダイレクトします ：setting： `settings.LOGIN_URL ` 、クエリ文字列で現在の絶対パスを渡します。 例：/accounts/login/?next=/polls/3/。

  • ユーザーがログインしている場合は、通常どおりビューを実行します。 ビューコードは、ユーザーがログインしていることを前提としています。

デフォルトでは、認証が成功したときにユーザーがリダイレクトされるパスは、"next"というクエリ文字列パラメーターに格納されます。 このパラメーターに別の名前を使用する場合は、 login_required（）はオプションのredirect_field_nameパラメーターを取ります。

from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...

redirect_field_nameに値を指定する場合、リダイレクトパスを格納するテンプレートコンテキスト変数はredirect_field_nameの値を次のように使用するため、ログインテンプレートもカスタマイズする必要がある可能性が高いことに注意してください。 "next"（デフォルト）ではなく、そのキー。

login_required（）も、オプションのlogin_urlパラメーターを取ります。 例：

from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...

指定しない場合は注意してくださいlogin_urlパラメータ、あなたは次のことを確認する必要があります ：setting： `settings.LOGIN_URL ` ログインビューは適切に関連付けられています。 たとえば、デフォルトを使用して、URLconfに次の行を追加します。

from django.contrib.auth import views as auth_views

path('accounts/login/', auth_views.LoginView.as_view()),

NS ：setting： `settings.LOGIN_URL ` ビュー関数名も受け入れ、 名前付きURLパターン 。 これにより、設定を更新しなくても、URLconf内でログインビューを自由に再マップできます。

ノート

login_requiredデコレータは、ユーザーのis_activeフラグをチェックしませんが、デフォルトの：setting： `AUTHENTICATION_BACKENDS` は非アクティブなユーザーを拒否します。


も参照してください

Djangoの管理者用にカスタムビューを作成している場合（または組み込みビューが使用するのと同じ認証チェックが必要な場合）、 django.contrib.admin.views.decorators.staff_member_required（）デコレータaが見つかる場合があります。 login_required()の便利な代替手段。


LoginRequiredミックスイン

クラスベースビューを使用する場合、LoginRequiredMixinを使用すると、login_requiredと同じ動作を実現できます。 このミックスインは、継承リストの左端にある必要があります。

class LoginRequiredMixin

ビューがこのミックスインを使用している場合、 raise_exception パラメーターに応じて、認証されていないユーザーによるすべてのリクエストがログインページにリダイレクトされるか、HTTP 403Forbiddenエラーが表示されます。

AccessMixin の任意のパラメーターを設定して、許可されていないユーザーの処理をカスタマイズできます。

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

ノート

login_requiredデコレータと同様に、このミックスインはユーザーのis_activeフラグをチェックしませんが、デフォルトの：setting： `AUTHENTICATION_BACKENDS` は非アクティブなユーザーを拒否します。


テストに合格したログインユーザーへのアクセスを制限する

特定のアクセス許可またはその他のテストに基づいてアクセスを制限するには、前のセクションで説明したのと基本的に同じことを行います。

ビューの request.user で直接テストを実行できます。 たとえば、このビューは、ユーザーが目的のドメインに電子メールを持っていることを確認し、持っていない場合は、ログインページにリダイレクトします。 

from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...
user_passes_test(test_func, login_url=None, redirect_field_name='next')

ショートカットとして、呼び出し可能オブジェクトがFalseを返すときにリダイレクトを実行する便利なuser_passes_testデコレータを使用できます。

from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...

user_passes_test（）は、必須の引数を取ります。 User オブジェクトを受け取り、ユーザーがページの表示を許可されている場合はTrueを返す呼び出し可能オブジェクトです。 user_passes_test（）は、 User が匿名でないことを自動的にチェックしないことに注意してください。

user_passes_test（）は、2つのオプションの引数を取ります。

login_url

テストに合格しなかったユーザーがリダイレクトされるURLを指定できます。 ログインページである可能性があり、デフォルトは ：setting： `settings.LOGIN_URL ` 指定しない場合。

redirect_field_name

login_required（）の場合と同じです。 Noneに設定すると、URLから削除されます。これは、テストに合格しなかったユーザーを「次のページ」がない非ログインページにリダイレクトする場合に実行することをお勧めします。

例えば：

@user_passes_test(email_check, login_url='/login/')
def my_view(request):
    ...
class UserPassesTestMixin

クラスベースのビューを使用する場合、UserPassesTestMixinを使用してこれを行うことができます。

test_func()

実行されるテストを提供するには、クラスのtest_func()メソッドをオーバーライドする必要があります。 さらに、 AccessMixin の任意のパラメーターを設定して、許可されていないユーザーの処理をカスタマイズできます。

from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')
get_test_func()

get_test_func()メソッドをオーバーライドして、ミックスインがチェックに（ test_func（）の代わりに）別の名前の関数を使用するようにすることもできます。

スタッキングUserPassesTestMixin

UserPassesTestMixinの実装方法により、継承リストにスタックすることはできません。 以下は機能しません。

class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith('@example.com')

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith('django')

class MyView(TestMixin1, TestMixin2, View):
    ...

TestMixin1がsuper()を呼び出し、その結果を考慮に入れると、TestMixin1はスタンドアロンでは機能しなくなります。


permission_requiredデコレータ

permission_required(perm, login_url=None, raise_exception=False)

ユーザーが特定の権限を持っているかどうかを確認することは、比較的一般的なタスクです。 そのため、Djangoはその場合のショートカットを提供します： permit_required（）デコレータ。：

from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice')
def my_view(request):
    ...

has_perm（）メソッドと同様に、権限名は"<app label>.<permission codename>"（つまり、 polls.add_choiceは、pollsアプリケーションのモデルに対する許可を求めます）。

デコレータは反復可能な権限を取得する場合もあります。その場合、ユーザーはビューにアクセスするためにすべての権限を持っている必要があります。

permit_required（）もオプションのlogin_urlパラメーターを受け取ることに注意してください。

from django.contrib.auth.decorators import permission_required

@permission_required('polls.add_choice', login_url='/loginpage/')
def my_view(request):
    ...

のようにログインが必要です（） デコレータ、login_url デフォルトは ：setting： `settings.LOGIN_URL ` 。

raise_exceptionパラメーターが指定されている場合、デコレーターは PermissionDenied を発生させ、ログインページにリダイレクトする代わりに、 403（HTTP Forbidden）ビューを要求します。

raise_exceptionを使用するだけでなく、ユーザーに最初にログインする機会を与える場合は、 login_required（）デコレータを追加できます。

from django.contrib.auth.decorators import login_required, permission_required

@login_required
@permission_required('polls.add_choice', raise_exception=True)
def my_view(request):
    ...

これにより、 LoginView のredirect_authenticated_user=Trueで、ログインしたユーザーが必要なすべての権限を持っていない場合のリダイレクトループも回避されます。


PermissionRequiredMixinミックスイン

クラスベースのビューに権限チェックを適用するには、PermissionRequiredMixinを使用できます。

class PermissionRequiredMixin

このミックスインは、permission_requiredデコレータと同様に、ビューにアクセスするユーザーにすべての権限が付与されているかどうかを確認します。 permission_requiredパラメーターを使用して、アクセス許可（またはアクセス許可の反復可能）を指定する必要があります。

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.add_choice'
    # Or multiple of permissions:
    permission_required = ('polls.view_choice', 'polls.change_choice')

AccessMixin の任意のパラメーターを設定して、許可されていないユーザーの処理をカスタマイズできます。

これらのメソッドをオーバーライドすることもできます。

get_permission_required()

ミックスインで使用されるイテラブルのパーミッション名を返します。 デフォルトはpermission_required属性で、必要に応じてタプルに変換されます。

has_permission()

現在のユーザーが装飾されたビューを実行する権限を持っているかどうかを示すブール値を返します。 デフォルトでは、これは、 get_permission_required（）によって返されるアクセス許可のリストを使用して has_perms（）を呼び出した結果を返します。


クラスベースのビューでの不正なリクエストのリダイレクト

クラスベースのビューでのアクセス制限の処理を容易にするために、AccessMixinを使用して、アクセスが拒否されたときのビューの動作を構成できます。 認証されたユーザーは、HTTP 403Forbidden応答でアクセスを拒否されます。 raise_exception 属性に応じて、匿名ユーザーはログインページにリダイレクトされるか、HTTP 403Forbidden応答が表示されます。

class AccessMixin
login_url

get_login_url（）のデフォルトの戻り値。 デフォルトはNoneその場合 get_login_url（） にフォールバック ：setting： `settings.LOGIN_URL ` 。

permission_denied_message

get_permission_denied_message（）のデフォルトの戻り値。 デフォルトは空の文字列です。

redirect_field_name

get_redirect_field_name（）のデフォルトの戻り値。 デフォルトは"next"です。

raise_exception

この属性がTrueに設定されている場合、条件が満たされないときに PermissionDenied 例外が発生します。 False（デフォルト）の場合、匿名ユーザーはログインページにリダイレクトされます。

get_login_url()

テストに合格しなかったユーザーがリダイレクトされるURLを返します。 戻り値 login_url 設定されている場合、または ：setting： `settings.LOGIN_URL ` それ以外は。

get_permission_denied_message()

raise_exception がTrueの場合、このメソッドを使用して、ユーザーに表示するためにエラーハンドラーに渡されるエラーメッセージを制御できます。 デフォルトで permission_denied_message 属性を返します。

get_redirect_field_name()

ログインに成功した後にユーザーがリダイレクトされるURLを含むクエリパラメータの名前を返します。 これをNoneに設定すると、クエリパラメータは追加されません。 デフォルトで redirect_field_name 属性を返します。

handle_no_permission()

raise_exceptionの値に応じて、メソッドは PermissionDenied 例外を発生させるか、ユーザーをlogin_urlにリダイレクトします。オプションで、redirect_field_nameを含めます。設定。

パスワード変更時のセッション無効化

：setting： `AUTH_USER_MODEL` が AbstractBaseUser を継承するか、独自の get_session_auth_hash（）メソッドを実装する場合、認証されたセッションには、この関数によって返されるハッシュが含まれます。 AbstractBaseUser の場合、これはパスワードフィールドのHMACです。 Djangoは、各リクエストのセッション内のハッシュが、リクエスト中に計算されたハッシュと一致することを確認します。 これにより、ユーザーはパスワードを変更してすべてのセッションからログアウトできます。

Djangoに含まれているデフォルトのパスワード変更ビュー、 PasswordChangeView 、および django.contrib.auth 管理者のuser_change_passwordビューは、新しいパスワードハッシュでセッションを更新します。自分のパスワードを変更したユーザーは、自分自身をログアウトしません。 カスタムパスワード変更ビューがあり、同様の動作をしたい場合は、 update_session_auth_hash（）関数を使用してください。

update_session_auth_hash(request, user)

この関数は、現在のリクエストと、新しいセッションハッシュの派生元となる更新されたユーザーオブジェクトを受け取り、セッションハッシュを適切に更新します。 また、セッションキーをローテーションして、盗まれたセッションCookieが無効になるようにします。

使用例：

from django.contrib.auth import update_session_auth_hash

def password_change(request):
    if request.method == 'POST':
        form = PasswordChangeForm(user=request.user, data=request.POST)
        if form.is_valid():
            form.save()
            update_session_auth_hash(request, form.user)
    else:
        ...

ノート

get_session_auth_hash（）は：setting： `SECRET_KEY` に基づいているため、新しいシークレットを使用するようにサイトを更新すると、既存のすべてのセッションが無効になります。


認証ビュー

Djangoは、ログイン、ログアウト、およびパスワード管理の処理に使用できるいくつかのビューを提供します。 これらはストック認証フォームを利用しますが、独自のフォームを渡すこともできます。

Djangoは、認証ビューのデフォルトテンプレートを提供していません。 使用するビュー用に独自のテンプレートを作成する必要があります。 テンプレートコンテキストは各ビューに文書化されています。すべての認証ビューを参照してください。

ビューの使用

これらのビューをプロジェクトに実装するには、さまざまな方法があります。 最も簡単な方法は、提供されたURLconfをdjango.contrib.auth.urlsの独自のURLconfに含めることです。次に例を示します。 

urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
]

これには、次のURLパターンが含まれます。 

accounts/login/ [name='login']
accounts/logout/ [name='logout']
accounts/password_change/ [name='password_change']
accounts/password_change/done/ [name='password_change_done']
accounts/password_reset/ [name='password_reset']
accounts/password_reset/done/ [name='password_reset_done']
accounts/reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/reset/done/ [name='password_reset_complete']

ビューは、参照しやすいようにURL名を提供します。 名前付きURLパターンの使用の詳細については、 URLドキュメントを参照してください。

URLをより細かく制御したい場合は、URLconfで特定のビューを参照できます。 

from django.contrib.auth import views as auth_views

urlpatterns = [
    path('change-password/', auth_views.PasswordChangeView.as_view()),
]

ビューには、ビューの動作を変更するために使用できるオプションの引数があります。 たとえば、ビューが使用するテンプレート名を変更する場合は、template_name引数を指定できます。 これを行う方法は、URLconfにキーワード引数を指定することです。これらはビューに渡されます。 例えば： 

urlpatterns = [
    path(
        'change-password/',
        auth_views.PasswordChangeView.as_view(template_name='change-password.html'),
    ),
]

すべてのビューはクラスベースであり、サブクラス化することで簡単にカスタマイズできます。


すべての認証ビュー

これは、django.contrib.authが提供するすべてのビューのリストです。 実装の詳細については、ビューの使用を参照してください。

class LoginView

URL名： login

名前付きURLパターンの使用の詳細については、 URLドキュメントを参照してください。

属性：

  • template_name：ユーザーのログインに使用されるビューに表示するテンプレートの名前。 デフォルトはregistration/login.htmlです。

  • redirect_field_name：ログイン後にリダイレクトするURLを含むGETフィールドの名前。 デフォルトはnextです。

  • authentication_form：認証に使用する呼び出し可能オブジェクト（通常はフォームクラス）。 デフォルトは AuthenticationForm です。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

  • redirect_authenticated_user：ログインページにアクセスする認証済みユーザーが、ログインに成功したかのようにリダイレクトされるかどうかを制御するブール値。 デフォルトはFalseです。

    警告

    redirect_authenticated_userを有効にすると、他のWebサイトは、Webサイト上の画像ファイルへのリダイレクトURLを要求することにより、訪問者がサイトで認証されているかどうかを判断できます。 この「ソーシャルメディアフィンガープリント」情報の漏洩を回避するには、すべての画像とファビコンを別のドメインでホストします。

    redirect_authenticated_userを有効にすると、raise_exceptionパラメーターが使用されていない限り、 permit_required（）デコレーターを使用するときにリダイレクトループが発生する可能性もあります。

  • success_url_allowed_hosts： request.get_host（）に加えて、ログイン後にリダイレクトしても安全なホストのset。 デフォルトは空のsetです。

LoginViewの機能は次のとおりです。

  • GETを介して呼び出された場合、同じURLにPOSTするログインフォームが表示されます。 これについてはもう少し詳しく説明します。

  • POSTを介してユーザーが送信した資格情報を使用して呼び出された場合、ユーザーはにログインしようとします。 ログインに成功すると、ビューはnextで指定されたURLにリダイレクトされます。 もしもnext提供されていない場合は、にリダイレクトされます ：setting： `settings.LOGIN_REDIRECT_URL ` （デフォルトは/accounts/profile/ ）。 ログインに失敗すると、ログインフォームが再表示されます。

デフォルトでregistration/login.htmlと呼ばれるログインテンプレートのhtmlを提供するのはあなたの責任です。 このテンプレートには、次の4つのテンプレートコンテキスト変数が渡されます。

  • form： AuthenticationForm を表す Form オブジェクト。

  • next：ログインに成功した後にリダイレクトするURL。 これにはクエリ文字列も含まれる場合があります。

  • site：：setting： `SITE_ID` 設定に従った、現在の Site 。 サイトフレームワークがインストールされていない場合、これは RequestSite のインスタンスに設定されます。これは、現在の HttpRequest からサイト名とドメインを取得します。

  • site_name：site.nameのエイリアス。 サイトフレームワークがインストールされていない場合、これは request.META [' SERVER_NAME '] の値に設定されます。 サイトの詳細については、「サイト」フレームワークを参照してください。

テンプレートregistration/login.htmlを呼び出さない場合は、URLconfのas_viewメソッドに追加の引数を介してtemplate_nameパラメーターを渡すことができます。 たとえば、このURLconf行は代わりにmyapp/login.htmlを使用します。

path('accounts/login/', auth_views.LoginView.as_view(template_name='myapp/login.html')),

redirect_field_nameを使用して、ログイン後にリダイレクトするURLを含むGETフィールドの名前を指定することもできます。 デフォルトでは、フィールドはnextと呼ばれます。

これは、開始点として使用できるサンプルregistration/login.htmlテンプレートです。 contentブロックを定義するbase.htmlテンプレートがあることを前提としています。

{% extends "base.html" %}

{% block content %}

{% if form.errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
    {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
    {% else %}
    <p>Please login to see this page.</p>
    {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>
<tr>
    <td>{{ form.username.label_tag }}</td>
    <td>{{ form.username }}</td>
</tr>
<tr>
    <td>{{ form.password.label_tag }}</td>
    <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login">
<input type="hidden" name="next" value="{{ next }}">
</form>

{# Assumes you setup the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

認証をカスタマイズしている場合（認証のカスタマイズを参照）、authentication_form属性を設定することでカスタム認証フォームを使用できます。 このフォームは、__init__()メソッドでrequestキーワード引数を受け入れ、認証されたユーザーオブジェクトを返すget_user()メソッドを提供する必要があります（このメソッドは、フォームの検証が成功した後にのみ呼び出されます） 。

class LogoutView

ユーザーをログアウトします。

URL名： logout

属性：

  • next_page：ログアウト後にリダイレクトするURL。 デフォルトは ：setting： `settings.LOGOUT_REDIRECT_URL ` 。

  • template_name：ユーザーのログアウト後に表示するテンプレートのフルネーム。 デフォルトはregistration/logged_out.htmlです。

  • redirect_field_name：ログアウト後にリダイレクトするURLを含むGETフィールドの名前。 デフォルトはnextです。 指定されたGETパラメーターが渡された場合、next_page URLをオーバーライドします。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

  • success_url_allowed_hosts： request.get_host（）に加えて、ログアウト後にリダイレクトしても安全なホストのset。 デフォルトは空のsetです。

テンプレートコンテキスト：

  • title：ローカライズされた文字列「ログアウト」。

  • site：：setting： `SITE_ID` 設定に従った、現在の Site 。 サイトフレームワークがインストールされていない場合、これは RequestSite のインスタンスに設定されます。これは、現在の HttpRequest からサイト名とドメインを取得します。

  • site_name：site.nameのエイリアス。 サイトフレームワークがインストールされていない場合、これは request.META [' SERVER_NAME '] の値に設定されます。 サイトの詳細については、「サイト」フレームワークを参照してください。

logout_then_login(request, login_url=None)

ユーザーをログアウトしてから、ログインページにリダイレクトします。

URL名：デフォルトのURLは提供されていません

オプションの引数：

class PasswordChangeView

URL名： password_change

ユーザーがパスワードを変更できるようにします。

属性：

  • template_name：パスワード変更フォームの表示に使用するテンプレートのフルネーム。 指定しない場合、デフォルトはregistration/password_change_form.htmlです。

  • success_url：パスワードの変更が成功した後にリダイレクトするURL。 デフォルトは'password_change_done'です。

  • form_class：userキーワード引数を受け入れる必要があるカスタムの「パスワード変更」フォーム。 フォームは、実際にユーザーのパスワードを変更する責任があります。 デフォルトは PasswordChangeForm です。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

テンプレートコンテキスト：

  • form：パスワード変更フォーム（上記のform_classを参照）。

class PasswordChangeDoneView

URL名： password_change_done

ユーザーがパスワードを変更した後に表示されるページ。

属性：

  • template_name：使用するテンプレートのフルネーム。 指定しない場合、デフォルトはregistration/password_change_done.htmlです。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

class PasswordResetView

URL名： password_reset

パスワードのリセットに使用できる1回限りのリンクを生成し、そのリンクをユーザーの登録済み電子メールアドレスに送信することにより、ユーザーがパスワードをリセットできるようにします。

指定された電子メールアドレスがシステムに存在しない場合、このビューは電子メールを送信しませんが、ユーザーはエラーメッセージも受信しません。 これにより、潜在的な攻撃者への情報漏えいを防ぎます。 この場合にエラーメッセージを表示する場合は、 PasswordResetForm をサブクラス化し、form_class属性を使用できます。

ノート

電子メールの送信には余分な時間がかかるため、既存の電子メールアドレスのリセット要求の期間と存在しない電子メールアドレスのリセット要求の期間が異なるため、電子メールアドレスの列挙タイミング攻撃に対して脆弱になる可能性があることに注意してください。 オーバーヘッドを減らすために、非同期で電子メールを送信できるサードパーティのパッケージを使用できます。 django-mailer 。

使用できないパスワードでフラグが付けられたユーザー（ set_unusable_password（）を参照）は、LDAPなどの外部認証ソースを使用する場合の誤用を防ぐためにパスワードのリセットを要求することはできません。 アカウントの存在が明らかになるため、エラーメッセージは表示されませんが、メールも送信されないことに注意してください。

属性：

  • template_name：パスワードリセットフォームの表示に使用するテンプレートのフルネーム。 指定しない場合、デフォルトはregistration/password_reset_form.htmlです。

  • form_class：パスワードをリセットするためのユーザーの電子メールを取得するために使用されるフォーム。 デフォルトは PasswordResetForm です。

  • email_template_name：パスワードのリセットリンクを含む電子メールの生成に使用するテンプレートのフルネーム。 指定しない場合、デフォルトはregistration/password_reset_email.htmlです。

  • subject_template_name：パスワードのリセットリンクを含む電子メールの件名に使用するテンプレートのフルネーム。 指定しない場合、デフォルトはregistration/password_reset_subject.txtです。

  • token_generator：ワンタイムリンクをチェックするクラスのインスタンス。 これはデフォルトでdefault_token_generatorになり、django.contrib.auth.tokens.PasswordResetTokenGeneratorのインスタンスです。

  • success_url：パスワードリセットリクエストが成功した後にリダイレクトするURL。 デフォルトは'password_reset_done'です。

  • from_email：有効なメールアドレス。 デフォルトでは、Djangoは：setting： `DEFAULT_FROM_EMAIL` を使用します。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

  • html_email_template_name：パスワードリセットリンク付きの text / html マルチパート電子メールの生成に使用するテンプレートのフルネーム。 デフォルトでは、HTMLメールは送信されません。

  • extra_email_context：メールテンプレートで利用できるコンテキストデータの辞書。 以下にリストされているデフォルトのテンプレートコンテキスト値をオーバーライドするために使用できます。 domain。

テンプレートコンテキスト：

  • form：ユーザーのパスワードをリセットするためのフォーム（上記のform_classを参照）。

メールテンプレートのコンテキスト：

  • email：user.emailのエイリアス

  • user：emailフォームフィールドによる、現在のユーザー。 パスワードをリセットできるのはアクティブユーザーのみです（User.is_active is True）。

  • site_name：site.nameのエイリアス。 サイトフレームワークがインストールされていない場合、これは request.META [' SERVER_NAME '] の値に設定されます。 サイトの詳細については、「サイト」フレームワークを参照してください。

  • domain：site.domainのエイリアス。 サイトフレームワークがインストールされていない場合、これはrequest.get_host()の値に設定されます。

  • protocol：httpまたはhttps

  • uid：Base64でエンコードされたユーザーの主キー。

  • token：リセットリンクが有効であることを確認するためのトークン。

サンプルregistration/password_reset_email.html（メール本文テンプレート）：

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

同じテンプレートコンテキストがサブジェクトテンプレートに使用されます。 件名は1行のプレーンテキスト文字列である必要があります。

class PasswordResetDoneView

URL名： password_reset_done

ユーザーにパスワードをリセットするためのリンクが電子メールで送信された後に表示されるページ。 PasswordResetView に明示的なsuccess_url URLが設定されていない場合、このビューはデフォルトで呼び出されます。

ノート

指定された電子メールアドレスがシステムに存在しない場合、ユーザーが非アクティブであるか、使用できないパスワードを持っている場合でも、ユーザーはこのビューにリダイレクトされますが、電子メールは送信されません。

属性：

  • template_name：使用するテンプレートのフルネーム。 指定しない場合、デフォルトはregistration/password_reset_done.htmlです。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

class PasswordResetConfirmView

URL名： password_reset_confirm

新しいパスワードを入力するためのフォームを表示します。

URLからのキーワード引数：

  • uidb64：Base64でエンコードされたユーザーのID。

  • token：パスワードが有効であることを確認するためのトークン。

属性：

  • template_name：パスワード確認ビューを表示するためのテンプレートのフルネーム。 デフォルト値はregistration/password_reset_confirm.htmlです。

  • token_generator：パスワードをチェックするクラスのインスタンス。 これはデフォルトでdefault_token_generatorになり、django.contrib.auth.tokens.PasswordResetTokenGeneratorのインスタンスです。

  • post_reset_login：パスワードのリセットが成功した後、ユーザーを自動的に認証する必要があるかどうかを示すブール値。 デフォルトはFalseです。

  • post_reset_login_backend：post_reset_loginがTrueの場合に、ユーザーを認証するときに使用する認証バックエンドへの点線のパス。 複数の：setting： `AUTHENTICATION_BACKENDS` が構成されている場合にのみ必要です。 デフォルトはNoneです。

  • form_class：パスワードの設定に使用されるフォーム。 デフォルトは SetPasswordForm です。

  • success_url：パスワードのリセットが行われた後にリダイレクトするURL。 デフォルトは'password_reset_complete'です。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。

  • reset_url_token：パスワードリセットURLのコンポーネントとして表示されるトークンパラメーター。 デフォルトは'set-password'です。

テンプレートコンテキスト：

  • form：新しいユーザーのパスワードを設定するためのフォーム（上記のform_classを参照）。

  • validlink：ブール値。リンク（uidb64とtokenの組み合わせ）が有効または未使用の場合はTrue。

class PasswordResetCompleteView

URL名： password_reset_complete

パスワードが正常に変更されたことをユーザーに通知するビューを表示します。

属性：

  • template_name：ビューを表示するためのテンプレートのフルネーム。 デフォルトはregistration/password_reset_complete.htmlです。

  • extra_context：テンプレートに渡されるデフォルトのコンテキストデータに追加されるコンテキストデータの辞書。


ヘルパー関数

redirect_to_login(next, login_url=None, redirect_field_name='next')

ログインページにリダイレクトし、ログインに成功すると別のURLに戻ります。

必須の引数：

  • next：ログインに成功した後にリダイレクトするURL。

オプションの引数：

  • login_url：リダイレクト先のログインページのURL。 デフォルトは ：setting： `settings.LOGIN_URL ` 提供されていない場合。

  • redirect_field_name：ログアウト後にリダイレクトするURLを含むGETフィールドの名前。 指定されたGETパラメーターが渡された場合、nextをオーバーライドします。


ビルトインフォーム

組み込みのビューを使用したくないが、この機能のフォームを作成する必要がないという利便性が必要な場合、認証システムは django.contrib.auth.forms [にあるいくつかの組み込みのフォームを提供します。 X221X]：

ノート

組み込みの認証フォームは、使用しているユーザーモデルについて特定の前提条件を設定します。 カスタムユーザーモデルを使用している場合は、認証システム用に独自のフォームを定義する必要がある場合があります。 詳細については、カスタムユーザーモデルでの組み込み認証フォームの使用に関するドキュメントを参照してください。


class AdminPasswordChangeForm

ユーザーのパスワードを変更するために管理インターフェースで使用されるフォーム。

userを最初の位置引数として取ります。

class AuthenticationForm

にユーザーをログインするためのフォーム。

requestを最初の位置引数として取り、サブクラスで使用するためにフォームインスタンスに格納されます。

confirm_login_allowed(user)

デフォルトでは、AuthenticationFormは、is_activeフラグがFalseに設定されているユーザーを拒否します。 この動作をカスタムポリシーでオーバーライドして、ログインできるユーザーを決定できます。 これは、AuthenticationFormをサブクラス化し、confirm_login_allowed()メソッドをオーバーライドするカスタムフォームを使用して行います。 指定されたユーザーがログインできない場合、このメソッドは ValidationError を発生させる必要があります。

たとえば、「アクティブ」ステータスに関係なく、すべてのユーザーがログインできるようにするには、次のようにします。

from django.contrib.auth.forms import AuthenticationForm

class AuthenticationFormWithInactiveUsersOkay(AuthenticationForm):
    def confirm_login_allowed(self, user):
        pass

（この場合、 AllowAllUsersModelBackend など、非アクティブなユーザーを許可する認証バックエンドも使用する必要があります。）

または、一部のアクティブユーザーのみにログインを許可するには：

class PickyAuthenticationForm(AuthenticationForm):
    def confirm_login_allowed(self, user):
        if not user.is_active:
            raise ValidationError(
                _("This account is inactive."),
                code='inactive',
            )
        if user.username.startswith('b'):
            raise ValidationError(
                _("Sorry, accounts starting with 'b' aren't welcome here."),
                code='no_b_users',
            )
class PasswordChangeForm
ユーザーがパスワードを変更できるようにするためのフォーム。
class PasswordResetForm

ユーザーのパスワードをリセットするための1回限りの使用リンクを生成して電子メールで送信するためのフォーム。

send_mail(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)

引数を使用してEmailMultiAlternativesを送信します。 電子メールがユーザーに送信される方法をカスタマイズするためにオーバーライドできます。

パラメーター

  • subject_template_name –サブジェクトのテンプレート。

  • email_template_name –メール本文のテンプレート。

  • context – subject_template、email_template、およびhtml_email_templateに渡されるコンテキスト（Noneでない場合）。

  • from_email –送信者の電子メール。

  • to_email –リクエスターのEメール。

  • html_email_template_name –HTML本文のテンプレート。 デフォルトはNoneです。この場合、プレーンテキストの電子メールが送信されます。

デフォルトでは、save()は、contextに PasswordResetView が電子メールコンテキストに渡すのと同じ変数を設定します。

class SetPasswordForm
ユーザーが古いパスワードを入力せずにパスワードを変更できるフォーム。
class UserChangeForm
ユーザーの情報と権限を変更するために管理インターフェースで使用されるフォーム。
class UserCreationForm

新しいユーザーを作成するための ModelForm 。

username（ユーザーモデルから）、password1、およびpassword2の3つのフィールドがあります。 password1とpassword2が一致することを確認し、 validate_password（）を使用してパスワードを検証し、 set_password（）を使用してユーザーのパスワードを設定します。


テンプレートの認証データ

RequestContext を使用すると、現在ログインしているユーザーとその権限がテンプレートコンテキストで利用できるようになります。

専門性

技術的には、これらの変数は、 RequestContext を使用し、'django.contrib.auth.context_processors.auth'コンテキストプロセッサが有効になっている場合にのみ、テンプレートコンテキストで使用可能になります。 これは、デフォルトで生成された設定ファイルにあります。 詳細については、 RequestContextドキュメントを参照してください。


ユーザー

テンプレート RequestContext をレンダリングすると、現在ログインしているユーザー（ User インスタンスまたは AnonymousUser インスタンス）がテンプレート変数 [に格納されます。 X192X]： 

{% if user.is_authenticated %}
    <p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
    <p>Welcome, new user. Please log in.</p>
{% endif %}

RequestContextが使用されていない場合、このテンプレートコンテキスト変数は使用できません。


権限

現在ログインしているユーザーの権限は、テンプレート変数テンプレート:Permsに保存されます。 これはdjango.contrib.auth.context_processors.PermWrapperのインスタンスであり、テンプレートに適した権限のプロキシです。

テンプレート:Permsの単一属性ルックアップをブール値として評価することは、 User.has_module_perms（）のプロキシです。 たとえば、ログインしたユーザーがfooアプリで権限を持っているかどうかを確認するには次のようにします。 

{% if perms.foo %}

2レベル属性ルックアップをブール値として評価することは、 User.has_perm（）のプロキシです。 たとえば、ログインしたユーザーにfoo.add_vote権限があるかどうかを確認するには次のようにします。 

{% if perms.foo.add_vote %}

テンプレートの権限を確認するより完全な例を次に示します。 

{% if perms.foo %}
    <p>You have permission to do something in the foo app.</p>
    {% if perms.foo.add_vote %}
        <p>You can vote!</p>
    {% endif %}
    {% if perms.foo.add_driving %}
        <p>You can drive!</p>
    {% endif %}
{% else %}
    <p>You don't have permission to do anything in the foo app.</p>
{% endif %}

{% if in %}ステートメントで権限を検索することもできます。 例えば： 

{% if 'foo' in perms %}
    {% if 'foo.add_vote' in perms %}
        <p>In lookup works, too.</p>
    {% endif %}
{% endif %}

管理者でのユーザーの管理

django.contrib.adminとdjango.contrib.authの両方がインストールされている場合、管理者はユーザー、グループ、および権限を表示および管理するための便利な方法を提供します。 ユーザーは、他のDjangoモデルと同じように作成および削除できます。 グループを作成し、ユーザーまたはグループに権限を割り当てることができます。 管理者内で行われたモデルに対するユーザー編集のログも保存され、表示されます。

ユーザーの作成

メインの管理者インデックスページの「認証」セクションに「ユーザー」へのリンクが表示されます。 「ユーザーの追加」管理ページは、ユーザーの残りのフィールドを編集する前にユーザー名とパスワードを選択する必要があるという点で、標準の管理ページとは異なります。

また、ユーザーアカウントでDjango管理サイトを使用してユーザーを作成できるようにする場合は、ユーザーの追加およびユーザーの変更（つまり、「ユーザーの追加」および「ユーザーの変更」権限）。 アカウントにユーザーを追加する権限はあるが変更はできない場合、そのアカウントはユーザーを追加できません。 どうして？ ユーザーを追加する権限がある場合は、スーパーユーザーを作成する権限があり、スーパーユーザーは他のユーザーを変更できます。 そのため、Djangoでは、わずかなセキュリティ対策として、との変更権限を追加する必要があります。

ユーザーに権限の管理を許可する方法について慎重に検討してください。 スーパーユーザー以外のユーザーにユーザーを編集する機能を与えると、スーパーユーザーに自分自身を含むユーザーの権限を昇格させることができるため、最終的にはスーパーユーザーのステータスを与えることと同じになります。


パスワードの変更

ユーザーパスワードは管理者には表示されません（データベースにも保存されません）が、パスワードストレージの詳細は表示されます。 この情報の表示には、管理者がユーザーパスワードを変更できるパスワード変更フォームへのリンクが含まれています。



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