Django でのユーザ認証

API リファレンス

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

基本的な使い方

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')
# この操作で、User オブジェクト user を保存できるようになります。
# 他のフィールドを変更したければ、属性を変更します。
>>> user.is_staff = True
>>> user.save()

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

パスワード

User オブジェクトの password フィールドは:

hashtype$salt$hash

のような形式の文字列、すなわちハッシュ方式 (hashtype)、ハッシュソルト (salt)、そしてハッシュ値 (hash) をドル記号 ("$") で分割した文字列になり ます。

ハッシュ形式は sha1 (デフォルト) または md5 、 crypt のいずれか で、それぞれパスワードの一方向ハッシュ化アルゴリズムを表します。 salt は生 のパスワード文字列からハッシュを生成するときに味付け (salt) しておくための ランダムな文字列です。 crypt のサポートは、 Python の標準モジュール crypt がサポートされている環境だけで有効です。また、 crypt のサポー トは開発版の Django でのみ利用できます。

例えば:

sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4

User.set_password() および User.check_password() 関数は、これらの値 の設定やチェックを背後で行っています。

バージョン 0.90 のような以前の Django では、パスワードソルトなしの単純な MD5 ハッシュを使っていました。この形式は、以前のバージョンとの互換性を持た せるためにまだサポートしています。ただし、古いパスワードのユーザに対する User.check_passwword() が成功すると、パスワードは自動的に新しい形式に変 換されます。

匿名ユーザ (Anonymous users)

django.contrib.auth.models.AnonymousUser は django.contrib.auth.models.User インタフェースを実装したクラスですが、 以下の点で User と異なります:

• id は常に None です。
• is_staff および is_superuser は常に False です。
• is_active は常に False です。
• groups および user_permissions は常に空です。
• is_anonymous() は False ではなく True を返します。
• is_authenticated() は True ではなく False を返します。
• has_perm() は常に False を返します。
• set_password(), check_password(), save(), delete, set_groups() および set_permissions() は NotImplementedError を送出します。

おそらく、実践上意識して AnonymousUser オブジェクトを使う必要はないはず です。とはいえ、匿名ユーザは次節で述べるような形で Web リクエストで使われて います。

スーパユーザの作成

INSTALLED_APPS に 'django.contrib.auth' を追加した直後の manage.py syncdb では、スーパユーザの作成を促すプロンプトを表示します。 また、後でスーパユーザを作成したい場合には、 creater_superuser.py ユー ティリティを使えます。以下のコマンドを実行してください:

python /path/to/django/contrib/auth/create_superuser.py

/path/to/ は自分のシステムの Django コードベースへのパスに応じて読み変 えて下さい。

追加のユーザ情報の保存

ユーザに追加の情報をひもづけて保存したい場合のために、 Django ではサイトご とにユーザに関連付けられた「ユーザプロファイル」を取り出すためのメソッドを 提供しています。

ユーザプロファイルを利用するには、まず、ユーザにひもづけて保存したい情報を 入れるためのフィールドや持たせたいメソッド、そして User モデルへの ForeignKey を持ったモデルを定義します。 ForeignKey には unique=True をセットし、ユーザごとにモデルが一つだけ生成されるようにし ます。

このモデルをあるサイトのユーザプロファイルモデルにするには、 AUTH_PROFILE_MODULE に以下の内容をドット区切りの文字列で指定します:

1. ユーザプロファイルモデルを定義している (小文字に変換した) アプリケーショ ン名 (別の言い方をするなら、 manage.py startapp でアプリケーションを 作成するときに指定する名前を全て小文字にしたもの)。
2. (小文字に変換した) モデルクラス名

例えば、プロファイルモデルが UserProfile という名前のクラスで、 accounts というアプリケーションで定義されているなら、設定値は以下のよう になるでしょう:

AUTH_PROFILE_MODULE = 'accounts.userprofile'

上記の方法でユーザプロファイルモデルを定義して指定すると、ユーザオブジェ クトには get_profile() というメソッドが付加されます。このメソッドは、 ユーザに関連付けられているプロファイルモデルのインスタンスを返します。

さらに詳しい情報は、 Django book の 12 章 を参照してください。

ユーザのパスワードを手動で調べる

ユーザ認証を手動で行うために平文パスワードとデータベース上のハッシュ化パス ワードを比較したい場合には、 django.contrib.auth.models.check_password という便宜関数を使えます。この関数は、調べたい平文パスワードと、比較対象の データベースに格納されているユーザの password フィールド全体の二つの引 数をとり、二つが一致すれば True を、そうでなければ False を返します。

ユーザをログインさせる

Django では、 django.contrib.auth の中で、 authenticat() と login() という二つの関数を提供しています。

あるユーザ名とパスワードに対する認証を行うには、 authenticate() を使っ てください。この関数は二つのキーワード引数、 username と password をとり、ユーザ名に対してパスワードが有効であった場合に User オブジェク トを返します。パスワードが無効だった場合には、 authenticate() は None を返します。例えば:

from django.contrib.auth import authenticate
user = authenticate(username='john', password='secret')
if user is not None:
    if user.is_active:
        print "You provided a correct username and password!"
    else:
        print "Your account has been disabled!"
else:
    print "Your username and password were incorrect."

ユーザをログインさせるには、ビューの中で 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(username=username, password=password)
    if user is not None:
        if user.is_active:
            login(request, user)
            # Redirect to a success page.
        else:
            # Return a 'disabled account' error message
    else:
        # Return an error message.

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

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() はエラーを送出しないことに注意 してください。

ログインユーザだけがアクセスできるように制限をかける

from django.http import HttpResponseRedirect

def my_view(request):
    if not request.user.is_authenticated():
        return HttpResponseRedirect('/login/?next=%s' % request.path)
    # ...

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

from django.contrib.auth.decorators import login_required

def my_view(request):
    # ...
my_view = login_required(my_view)

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    # ...

from django.contrib.auth.decorators import login_required

def my_view(request):
    # ...
my_view = login_required(redirect_field_name='redirect_to')(my_view)

from django.contrib.auth.decorators import login_required

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

(r'^accounts/login/$', 'django.contrib.auth.views.login'),

(r'^accounts/login/$', 'django.contrib.auth.views.login',
 {'template_name': 'myapp/login.html'}),

{% extends "base.html" %}

{% block content %}

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

<form method="post" action=".">
<table>
<tr><td><label for="id_username">Username:</label></td><td>{{ form.username }}</td></tr>
<tr><td><label for="id_password">Password:</label></td><td>{{ form.password }}</td></tr>
</table>

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

{% endblock %}

その他の組み込みビュー

認証システムでは、 login ビューの他にも便利なビューをいくつか提供してい ます:

組み込みマニピュレータ

組み込みビューを使いたくないけれども、マニピュレータを書かずに済ませたい場 合のために、認証システムでは組み込みのマニピュレータをいくつか提供していま す:

• django.contrib.auth.forms.AdminPasswordChangeForm: Admin インタ フェースでユーザのパスワード変更に使われているマニピュレータです。
• django.contrib.auth.forms.AuthenticationForm: ユーザをログインさ せるためのマニピュレータです。
• django.contrib.auth.forms.PasswordChangeForm: ユーザにパスワード 変更させるためのマニピュレータです。
• django.contrib.auth.forms.PasswordResetForm: パスワードをリセット し、新たなパスワードを送信するためのマニピュレータです。
• django.contrib.auth.forms.UserCreationForm: 新たなユーザを作成す るためのマニピュレータです。

テストにパスしたログインユーザだけがアクセスできるように制限をかける

特定のパーミッションやその他のテストの結果に応じたアクセスの制限には、前節 で説明したの本質的に同じことをします。

一番簡単な方法は、ビュー内で直接 request.user に対するテストを実行する というものです。例えば、以下のビューではユーザがログイン済みで、かつ polls.can_vote というパーミッションを持っているかチェックします:

def my_view(request):
    if not (request.user.is_authenticated() and \
        request.user.has_perm('polls.can_vote')):
        return HttpResponse("You can't vote in this poll.")
    # ...

user_passes_test デコレータを使えば、手間を省けます:

from django.contrib.auth.decorators import user_passes_test

def my_view(request):
    # ...
my_view = user_passes_test(lambda u: u.has_perm('polls.can_vote'))(my_view)

ここでは、簡単な例としてパーミッションのテストに user_passes_test を使っ ていますが、単にあるユーザがあるパーミッションを有しているかをテストしたい だけなら、後で解説する permission_required() デコレータを使えます。

Python 2.4 のデコレータ構文ならこうなります:

from django.contrib.auth.decorators import user_passes_test

@user_passes_test(lambda u: u.has_perm('polls.can_vote'))
def my_view(request):
    # ...

user_passes_test には必須の引数が一つあります。この引数は、 User を 引数に取り、ユーザにページのビューを許可する場合には True を返す呼び出 し可能オブジェクトでなければなりません。 user_passes_test は User が匿名かどうかを自動的に調べないので注意してください。

user_passes_test() はオプションの引数として login_url をとります。 この引数を使うとログインページへの URL を指定できます (デフォルトでは settings.LOGIN_URL になります)。

Python 2.3 風の構文で書いた例を示します:

from django.contrib.auth.decorators import user_passes_test

def my_view(request):
    # ...
my_view = user_passes_test(lambda u: u.has_perm('polls.can_vote'), login_url='/login/')(my_view)

Python 2.4 風の構文で例を書くと以下のようになります:

from django.contrib.auth.decorators import user_passes_test

@user_passes_test(lambda u: u.has_perm('polls.can_vote'), login_url='/login/')
def my_view(request):
    # ...

from django.contrib.auth.decorators import permission_required

def my_view(request):
    # ...

my_view = permission_required('polls.can_vote')(my_view)

from django.contrib.auth.decorators import permission_required

def my_view(request):
    # ...
my_view = permission_required('polls.can_vote', login_url='/loginpage/')(my_view)

アクセスを汎用ビューに制限する

アクセスを 汎用ビュー に制限するには、ビューを囲む薄いラッパコードを書き、 URLconf を変更して、ジェネリックビュー自体ではなくラッパコードを指すように します。例えば:

from django.views.generic.date_based import object_detail

@login_required
def limited_object_detail(*args, **kwargs):
    return object_detail(*args, **kwargs)

デフォルトのパーミッション

class Admin セットを持つ Django モデルには、三つの基本的なパーミッショ ンである、 add, change, delete が自動的に生成されます。 manage.py syncdb を実行したとき、背後では、これらのパーミッションが自動 的に auth_permission データベーステーブルに追加されます。 django-admin.py sqlinitialdata [app] を実行すると、追加を行っている INSERT 文そのものを閲覧できます。

manage.py syncdb を実行した際、モデルに class Admin セットがないと、 パーミッションは生成されないので気を付けて下さい。この後でデータベースを初 期化して class Admin をモデルに追加した場合、 manage.py sycndb を再 度実行せねばなりません。このコマンドは、インストール済みのアプリケーション に欠けているパーミッションを生成します。

カスタムのパーミッション

カスタムのパーミッションを生成するには、 permissions という モデルのメタ属性 を使います。

この例では、三つのカスタムパーミッションを生成しています:

class USCitizen(models.Model):
    # ...
    class Meta:
        permissions = (
            ("can_drive", "Can drive"),
            ("can_vote", "Can vote in elections"),
            ("can_drink", "Can drink alcohol"),
        )

この定義の役割は、 syncdb を実行したときに追加のパーミッションを追加 することだけです。

API リファレンス

ユーザと同様、パーミッションは Django モデルとして実装されています。実装は django/contrib/auth/models.py にあります。

ユーザ

現在のログインユーザは、 User インスタンスであっても AnonymousUser インスタンスであっても、テンプレート変数 {{ user }} に入ります:

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

パーミッション

現在のログインユーザのパーミッションはテンプレート変数 {{ perms }} に入っ ています。この変数はパーミッションオブジェクトをテンプレートで扱いやすくす るためのプロキシ (proxy) である、 django.core.context_processors.PermWrapper のインスタンスです。

{{ perms }} オブジェクトに対して 1 段の属性参照を行うと、実際には User.has_module_perms へのプロキシになっています。例えば下記の例は、ロ グインユーザが foo というアプリケーションへのパーミッションを持っている 場合に True を表示します:

{{ perms.foo }}

2 段の属性参照は User.has_perm へのプロキシです。以下の例では、ログイン ユーザが foo.can_vote へのパーミッションを持つ場合に True を表示し ます:

{{ perms.foo.can_vote }}

こうして、テンプレート内で {% if %} 文を使ってチェックを行えます:

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

他の認証バックエンドを指定する

舞台裏では、 Django は認証に使う「認証バックエンド」のリストを維持していま す。前述の「ユーザをログインさせる」で説明したように django.contrib.auth.authenticate() を呼び出すと、Django は全ての認証バッ クエンドにわたって認証テストを試みます。最初の認証メソッドに失敗すると次の 認証バックエンド、という具合にして、認証に成功しない限り、全てのバックエン ドを試すまで続けます。

認証に使うバックエンドのリストは AUTHENTICATION_BACKENDS 設定に指定しま す。この値は Python モジュールパス名からなるタプルで、認証方法を実装したク ラスの名前を指定します。認証クラスは Python パス上のどこにあってもかまいま せん。

デフォルトでは、 AUTHENTICATION_BACKENDS の値は:

('django.contrib.auth.backends.ModelBackend',)

に設定されています。このクラスは、 Django のユーザデータベースをチェックす る認証スキームです。

AUTHENTICATION_BACKENDS の順番には意味があり、同じユーザ名とパスワード が複数のバックエンドで有効な値であったとしても、 Django は最初にユーザ名と パスワードがマッチした時点で認証処理を停止します。

認証バックエンドを作成する

認証バックエンドの実体は、 get_user(user_id) と authenticate(**credentials) という二つのメソッドを実装したクラスです。

get_user メソッドはユーザ名、データベース ID などを表す引数 user_id をとり、対応する User オブジェクトを返します。

authenticate メソッドは証明情報、すなわちユーザ名とパスワードなどをキー ワード引数の形で受け取ります。ほとんどの場合、以下のような形式をとります:

class MyBackend:
    def authenticate(self, username=None, password=None):
        # Check the username/password and return a User.

以下のようにトークンに対する認証を行うようにも書けます:

class MyBackend:
    def authenticate(self, token=None):
        # Check the token and return a User.

どちらの方法でも、 authenticate は受け取った証明情報をチェックし、証明 情報が有効な場合、対応する User オブジェクトを返さねばなりません。証明 情報が無効なら、 None を返します。

Django の admin システムは、冒頭で説明した Django の User オブジェクト と強くカップリングしています。従って、今のところ自作の認証バックエンドを扱 うには、 (LDAP ディレクトリや外部の SQL データベースなどのような) 別のバッ クエンド上のユーザに対して Django の User オブジェクトを生成するのがベ ストです。あらかじめスクリプトを書いておいてもよいですし、ユーザが最初にロ グインした際に、 authenticate メソッドでその処理を行うようにしてもよい でしょう。

以下に示すバックエンドの例では、 settings.py ファイルに定義されたユーザ 名とパスワードに対して認証を行い、ユーザが最初に認証を行ったときに User オブジェクトを生成します:

from django.conf import settings
from django.contrib.auth.models import User, check_password

class SettingsBackend:
    """
    Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.

    Use the login name, and a hash of the password. For example:

    ADMIN_LOGIN = 'admin'
    ADMIN_PASSWORD = 'sha1$4e987$afbcf42e21bd417fb71db8c66b321e9fc33051de'
    """
    def authenticate(self, username=None, password=None):
        login_valid = (settings.ADMIN_LOGIN == username)
        pwd_valid = check_password(password, settings.ADMIN_PASSWORD)
        if login_valid and pwd_valid:
            try:
                user = User.objects.get(username=username)
            except User.DoesNotExist:
                # Create a new user. Note that we can set password
                # to anything, because it won't be checked; the password
                # from settings.py will.
                user = User(username=username, password='get from settings.py')
                user.is_staff = True
                user.is_superuser = True
                user.save()
            return user
        return None

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

カスタムのバックエンドでパーミッションを扱う

カスタムの認証バックエンドから、独自のパーミッションを提供できます。

認証バックエンドがパーミッション照会のための関数 (get_group_permissions(), get_all_permissions(), has_perm(), および has_module_perms()) をサポートしている場合、ユーザモデルは パーミッションの照会をバックエンドに移譲します。

あるユーザに付与されるパーミッションの集合は、全てのバックエンドの返しうる パーミッションのスーパーセットです。すなわち、 Django はいずれかのバックエ ンドのパーミッションを、どのユーザにも付与できます。

前述の単純なバックエンドで、万能の管理ユーザを作る方法は、以下のようにとても 簡単です:

class SettingsBackend:

    # ...

    def has_perm(self, user_obj, perm):
        if user_obj.username == settings.ADMIN_LOGIN:
            return True
        else:
            return False

この書き方だと、上の例でアクセスを認可されたユーザにはあらゆるパーミッショ ンが許されます。バックエンドの認証関数はユーザオブジェクトを引数にとります。 また、ユーザオブジェクトの代わりに、 User のコンストラクタと同じ引数も 指定できます。

認可の API は、 django/contrib/auth/backends.py で実装されています。この バックエンドはデフォルトのバックエンドであり、ほとんどの場合 auth_permission にパーミッションを問い合わせます。