Djangoの認証システムを使用する¶

ユーザを作成する¶

ユーザを作成するための最も直接的な方法は、組み込まれている create_user() というヘルパー関数を利用することです。

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', '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 adminをインストールしている場合は、 インタラクティブにユーザを作成する こともできます。

スーパーユーザを作成する¶

Create superusers using the createsuperuser command:

$ python manage.py createsuperuser --username=joe --email=joe@example.com

パスワードを入力するように促されます。入力後、ただちにユーザが作成されます。 --username または --email オプションを使用しなければ、これらの値を入力するように促されます。

パスワードを変更する¶

Djangoはユーザモデルに未加工の (単なるテキストの) パスワードは保存せず、ハッシュ値でのみ保存します (詳細は、パスワードは管理方法に関するドキュメント を参照してください)。したがって、ユーザのパスワード属性を直接操作しないでください。これが、ユーザを作成する際にヘルパー関数を使用する理由です。

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

manage.py changepassword *username* は、コマンドラインからユーザのパスワードを変更する方法を提供します。ユーザのパスワードを変更するよう促されたら、パスワードを 2 回入力してください。2 つのパスワードが一致した場合、新しいパスワードが直ちに有効になります。ユーザを指定しない場合、コマンドは、現在のシステムユーザとユーザ名が一致するユーザのパスワードを変更するよう試みます。

set_password() を使用することで、プログラムでパスワードを変更することもできます:

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

Django admin がインストールされていれば、 認証システムのadminページ にて、ユーザのパスワードを変更することも可能です。

また、Djangoはユーザ自身のパスワードを変更するための ビュー と フォーム を提供します。

ユーザーのパスワード変更を行う事とそのユーザーのセッションは全てログアウトされます。詳細は Session invalidation on password change を参照してください。

ユーザを認証する¶

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 はオプションで、HttpRequest のインスタンスを取ります。このインスタンスは認証バックエンドの authenticate() メソッドに渡されます。

注釈

This is a low level way to authenticate a set of credentials; for example, it's used by the RemoteUserMiddleware. Unless you are writing your own authentication system, you probably won't use this. Rather if you're looking for a way to login a user, use the LoginView.

デフォルトの権限¶

When django.contrib.auth is listed in your INSTALLED_APPS setting, it will ensure that four default permissions -- add, change, delete, and view -- are created for each Django model defined in one of your installed applications.

これらの権限は manage.py migrate 実行時に作成されます。INSTALLED_APPS に django.contrib.auth を追加後初めての migrate を実行した場合は、新たにインストールされるモデルに対してと同様、それまでに作成されたモデルに対してもデフォルトの権限が作成されます。以後 manage.py migrate (この権限を作成する関数は post_migrate シグナルに接続されています)を実行する度作成されるモデルに対してデフォルトの権限が作成されます。

app_label が foo でモデルが Bar であるアプリケーションを想定し、デフォルトの権限を試すには以下を利用する必要が有ります:

• 追加: user.has_perm('foo.add_bar')
• 変更: user.has_perm('foo.change_bar')
• 削除: user.has_perm('foo.delete_bar')
• view: 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,
)

この権限は user_permissions 属性を介して User に、あるいは permissions 属性を介して Group に割り当てられます。

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

    ...

プロキシモデル¶

Proxy models work exactly the same way as concrete models. Permissions are created using the own content type of the proxy model. Proxy models don't inherit the permissions of the concrete model they subclass:

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

ユーザーをログインさせるには¶

現在のセッションにおいて認証を有効としたいユーザーがいる場合 - 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.
        ...

ユーザーをログアウトさせるには¶

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() を呼び出すと、現在処理しているリクエストに対応したセッション情報は完全に破棄されます。その時点までに存在している全てのデータが削除されます。これは、別の人物が同じウェブブラウザを利用してログインし、前のユーザーのセッションにアクセスして使用してしまう事態を防ぐためです。ログアウトした直後でも利用できる何らかの情報をセッションに保存したい場合は、django.contrib.auth.logout() を呼び出した 後 に行ってください。

ログインしているユーザーにアクセスを制限する¶

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')
    # ...

from django.shortcuts import redirect

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