Django でのユーザ認証¶

revision-up-to:	17812 (1.4)

Django にはユーザ認証システムがついてきます。 Django のユーザ認証システムは、ユーザアカウント、グループ、パーミッションとクッキーベースのユーザセッションを扱えます。このドキュメントでは、ユーザ認証の仕組みについて説明します。

概要¶

認証システムは以下の要素から成り立っています:

ユーザ (Users)
パーミッション: あるユーザが特定のタスクを実行してよいかどうかを決める、バイナリ (yes/no) のフラグです。
グループ (Groups): 複数のユーザに対してラベル付したり、認証を設定したりするための一般的な方法です。
メッセージ (Messages): 指定のユーザ(達) に対するメッセージをキューするための簡単な方法です。

インストール¶

認証のサポートは Django アプリケーションとして django.contrib.auth にバンドルされています。インストールするには、以下のようにします:

INSTALLED_APPS 設定に 'django.contrib.auth' と、 'django.contrib.contenttypes' を加えます。 (django.contrib.auth モジュールのモデル Permission は django.contrib.contenttypes に依存します)
manage.py syncdb を実行します。

django-admin.py startproject が生成するデフォルトの settings.py ファイルの INSTALLED_APPS には、簡便のため 'django.contrib.auth' が最初から入っています。この場合は、単に manage.py syncdb するだけでかまいません。このコマンドはその都度必要なものだけをインストールするので、何度実行してもかまいません。

syncdb コマンドは必要なデータベーステーブルを作成し、インストール済みのアプリケーションで必要な全てのパーミッションオブジェクトを作成します。また、最初に実行したときには、ユーザにスーパユーザアカウントを作成するよう促します。

これだけで、認証サポートを使えるようになります。

ユーザ (User)¶

class models.User¶

API リファレンス¶

フィールド¶

class models.User

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

username¶: 必須です。30 文字以下の文字列で、英数字 (アルファベット、数字、アンダースコア) だけを使えます。

ユーザネームには今では @, +, . and - 等の文字列を含めることが出来ます。

first_name¶: オプションです。30 文字以下です。オプションです。30 文字以下です。

last_name¶: オプションです。 30 文字以下です。

email¶: オプションです。 Email アドレスです。

password¶: 必須です。パスワードのメタデータであるハッシュ値です (Django では生のパスワードを保存しません)。生のパスワードは任意の長さでよく、どんな文字が入っていても構いません。詳しくは以下の「パスワード」の節を参照して下さい。

is_staff¶: Bool 値です。この値が真なら、ユーザは admin サイトにアクセスできます。

is_active¶

Bool 値です。この値が真なら、このアカウントを使ってログインできます。アカウントを削除する代わりに、この値を False に設定してください。もしアプリケーションが外部キーをユーザに対して持っていたとしても、この方法なら破綻しないのでおすすめです。

ユーザがログインできるかどうかをコントロールする必要性がない場合でも認証バックエンドが is_active フラッグをチェックする必要がない時であっても、もしログインできるかどうかを is_active を False にしたくない場合でも、ログインビューの中ではあなた次第です。しかしながら、 login() によって使われる AuthenticationForm ビューは does このチェックを実行します。has_perm() のような権限を確かめるメソッドのように、そして Django アドミンでの認証と同じように。これらのような関数/メソッドはアクティブでないユーザに対して、 False を返します.

is_superuser¶: Bool 値です。この値が真なら、ユーザは明示的な指定がなくても全てのパーミッションを得ます。

last_login¶: ユーザが最後にログインした時刻を表す datetime オブジェクトです。デフォルトではログイン時現在の日付/時刻になります。

date_joined¶: アカウントの作成された時刻を表す datetime オブジェクトです。デフォルトではアカウント作成時現在の日付/時刻になります。

メソッド¶

class models.User

User オブジェクトには groups と user_permissions という二つの多対多のフィールドがあります。この関係性のために、 User オブジェクトは他の Django モデルと同じようにして、関連づけされたオブジェクトにアクセスできます:

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()

自動的に生成されるこれらの API に加え、 User オブジェクトには以下のカスタムメソッドがあります:

is_anonymous()¶: 常に False を返します。 User オブジェクトを AnonymousUser オブジェクトと区別する手段の一つです。通常は、 is_authenticated() メソッドを使うようにしてください。

is_authenticated()¶: 常に True を返します。ユーザを認証済みかどうかを調べる一つの方法です。このメソッドの戻り値は、ユーザが正しいパーミッションを持っているか、あるいはアクティブなユーザであるかどうかに関係なく、ユーザが正しいユーザ名とパスワードを入力したことだけを示します。

get_full_name()¶: first_name と last_name をスペースでつなげた文字列を返します。

set_password(raw_password)¶: 渡された文字列をハッシュ化し、ユーザのパスワードに設定します。 User オブジェクトの保存は行いません。

check_password(raw_password)¶: 渡された文字列がこのユーザの正しい文字列ならば True を返します。 (このメソッドは比較時にパスワードのハッシュ処理を行います)

set_unusable_password()¶

ユーザにパスワード未設定のマークをつけます。パスワード未設定の状態は、パスワードが空の文字列である状態と区別されます。パスワード未設定状態のユーザに対して check_password() を呼び出すと、決して True を返しません。このメソッドは User オブジェクトを直接保存しません。

この機能は、 LDAP ディレクトリのような外部の認証ソースを使ってアプリケーションの認証を行いたい場合に必要です。

has_usable_password()¶: ユーザに対して set_unusable_password() を呼び出し、パスワードが未設定状態であれば False を返します。

get_group_permissions(obj=None)¶

ユーザが自分の属するグループから得ているパーミッションを表す文字列からなるリストを返します。

リリースノートを参照してください

もし obj が引数に渡されていれば、その種類のオブジェクトへ対する、属するグループから得ているパーミッションしか返しません。

get_all_permissions(obj=None)¶

ユーザ自身のもつパーミッションと、ユーザの属するグループのパーミッションの両方からなるリストを返します。

リリースノートを参照してください

もし、 obj が引数に渡されていれば、その特有のオブジェクトに対するユーザのパーミッションを返します。

has_perm(perm, obj=None)¶

ユーザが特定のパーミッションを持っている場合に True を返します。パーミッション名 perm は "<application name>.<lowercased model name>" のような形式で表します。ユーザがアクティブでない場合、このメソッドは常に False を返します。

リリースノートを参照してください

もし obj が引数に渡されていれば、このメソッドはモデルに対するパーミッションをチェックせず、引数のオブジェクトに対するものをチェックしようとします。

has_perms(perm_list, obj=None)¶

ユーザが perm_list 内のパーミッションのいずれかを持っている場合に True を返します。各々のパーミッション名は "<app label>.<permission codename>" のような形式で表します。ユーザがアクティブでない場合、このメソッドは常に False を返します。

リリースノートを参照してください

もし obj が引数で渡されていれば、このメソッドはモデルに対する権限ではなく、引数のオブジェクトに対するものを調べます。

has_module_perms(package_name)¶: ユーザが指定した名前のパッケージ (アプリケーション) の何らかのパーミッションを持っていれば True を返します。ユーザがアクティブでない場合、このメソッドは常に False を返します。

email_user(subject, message, from_email=None)¶: ユーザにメールを送信します。 from_email が None の場合、 Django は DEFAULT_FROM_EMAIL 設定を使います。

get_profile()¶: ユーザのサイト固有のプロファイル (site-specific profile) を返します。プロファイルを使えないサイトでは django.contrib.auth.models.SiteProfileNotAvailable を送出します。もしくはユーザがプロファイルを持っていなければ django.core.exceptions.ObjectDoesNotExtis を送出します。サイト固有のユーザプロファイルを定義するには、後述の追加のユーザ情報の保存を参照して下さい。

マネジャ関数¶

class models.UserManager¶

User モデルには、以下のヘルパ関数を備えたマネジャがあります。

create_user(username, email=None, password=None)¶

email パラメータはオプションになりました。username パラメータは、空のものと有効でない値が出た時の ValueError を上げるものをチェックするのに使われています。

ユーザを生成して保存し、生成された User を返します。 username, email は、自動的に小文字に変更され、 password は指定した値になり、 is_active は True に設定されます。

パスワードを指定しなかった場合、 set_unusable_password() を呼び出します。

使い方はユーザの作成を参照してください。

make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')¶

指定した長さのランダムなパスワードを生成して返します。パスワードに使える文字は文字列で指定します。 allowed_chars のデフォルト値は、ユーザが見間違いやすい以下の文字を除いてあります:

i, l, I, and 1 (lowercase letter i, lowercase letter L, uppercase letter i, and the number one)
o, O, and 0 (uppercase letter o, lowercase letter o, and zero)

基本的な使い方¶

ユーザの作成¶

ユーザを作成する一番基本的な方法は、オブジェクトマネージャの create_user() ヘルパー関数を使う方法です:

>>> 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()

Django のアドミンサイトを使用するユーザを作ることも出来ます。アドミンサイトの URL を /admin/ にひも付けると思います、 “Add user” ページは /admin/auth/user/add/ にあります。また、アドミンのメインページ（インデックスページ）の “Auth” セクションの “Users” へのリンクでも確認できます。 “Add user” 管理ページは、通常の管理ページ（アドミン）とはユーザネームとパスワードを、残りのフィールドを変更する前に埋めなくてはならない点で異なっています。

また、 note: もし、自身のユーザアカウントを Django のアドミンサイトを使えるようにしたいのならば、パーミッションを２つ与える必要があり、それぞれユーザを加える権限とユーザを変更する権限です。（すなわち、 “Add user” と “Change user” の権限です。）もし、あなたのアカウントが「ユーザを加える権限」は持っていても、「ユーザを変更する権限」を持っていない場合、ユーザを加えることはできません。なぜか？それは、ユーザを加える権限を有しているということは、スーパユーザを作る権限を有しているということで、スーパーユーザは同様に、他のユーザを変えることができます。だから、 Django はそれに加えてユーザ変更の権限も、セキュリティ対策として必要としているのです。

パスワードの変更¶

manage.py changepassword コマンドが追加されました。

manage.py changepassword *username* はコマンドラインからユーザのパスワードを変更する手続きを提供しています。パスワードを変更するには、二度指定したユーザの変更後のパスワードを入力しなくてはいけません。二つがマッチすると、ただちにパスワードが変更されます。ユーザを渡さないと、コマンドは最新のユーザのパスワードを変更しようとします。

パスワードの変更には set_password() を使います:

.. code-block:: python

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

特別な意図のない限り、 password 属性を直接設定しないでください。これについては次節で説明します。

Django はどのようにパスワードを保持するか¶

Django 1.4 では新しくフレキシブルなパスワードのストレージシステムと PBKDF2 をデフォルトで使用しています。以前のバージョンの Django では SHA1 が使われており、他のアルゴリズムを使用することは出来ませんでした。

User オブジェクトの password フィールドは、以下の形式:

algorithm$hash

すなわちストレージアルゴリズム（storage algorithm)と、ハッシュソルト (salt)、そしてハッシュ値(hash) はドル記号 ("$") で分割した文字列形式をとります。アルゴリズムはいくつかのハッシュ化または Django で使えるパスワードのストレージ方式のうちの一つです。下を見てください。ハッシュ値はハッシュ関数の結果であります。

通常では、 Django は PBKDF2 アルゴリズムをSHA256ハッシュ関数で暗号化します。パスワードのストレッチ機構は NIST によって勧告されています。これはほとんどのユーザにとっては満足できるものでしょう。高い安全性で、パスワードを破るには莫大な計算量を必要とします。

しかしながら必要に応じて、他のアルゴリズムを選択することもあるでしょう、また必要なセキュリティの度合いに応じてカスタムアルゴリズムを使用する必要もあることでしょう。繰り返すと、ほとんどのユーザはそれを必要とはしていません。もし、必要性が確かではないなら、それは必要なことではないでしょう。もし、あなたがそうしたいのならば読み進めてください。

Django では PASSWORD_HASHERS の設定でアルゴリズムを選択することができます。これは Django で使用するハッシュ化のアルゴリズムクラス群のリストです、リストの最初の項目（すなわち settings.PASSWORD_HASHERS[0] )はパスワードを保存するために使われます。そして、他の項目は有効となったハッシュで実在するパスワードをチェックするために使われます。つまり、もし違うアルゴリズムを使用したくなったときに、 PASSWORD_HASHERS を修正する必要があり、リストの先頭に好きなアルゴリズムを組み込んでください。

通常 PASSWORD_HASHERS は

PASSWORD_HASHERS = (
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.BCryptPasswordHasher',
    'django.contrib.auth.hashers.SHA1PasswordHasher',
    'django.contrib.auth.hashers.MD5PasswordHasher',
    'django.contrib.auth.hashers.CryptPasswordHasher',
)

これは、 Django は PBKDF2 を全てのパスワードの保存時に使おうとするということです。でも、保存されたパスワードをチェックする際には、 PBKDF2SHA1, bcrypt, SHA1, その他を用います。次以降のセクションでは高度なユーザのために、設定を変更する一般的な二つの方法を紹介します。

bcrypt を Django で使うには¶

Bcrypt は一般的なパスワードの保存アルゴリズムは長期間パスワードを保持しておくためにデザインされたアルゴリズムです。 Django ではデフォルトで使われていません。サードパーティのライブラリを必要とするからです。しかし、 bcrypt をサポートするにはちょびっとの労力で使えるように Django は配慮してくれています。

Bcrypt をデフォルトのアルゴリズムで使うには、以下に従ってください。

py-bcrypt ライブラリをインストールしてください（ sudo pip install py-bcrypt を実行するか、ライブラリをダウンロードして、 python setup.py install を使ってインストールしてください。)

PASSWORD_HASHERS を設定してください。リスト内で BCryptPasswordHasher を先頭へ。セッティングファイルはこうなります:

PASSWORD_HASHERS = (
     'django.contrib.auth.hashers.BCryptPasswordHasher',
     'django.contrib.auth.hashers.PBKDF2PasswordHasher',
     'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
     'django.contrib.auth.hashers.SHA1PasswordHasher',
     'django.contrib.auth.hashers.MD5PasswordHasher',
     'django.contrib.auth.hashers.CryptPasswordHasher',
 )

(リストの中の他の項目は、そのままにしておいてください、または Django がパスワードをアップグレードできないようにしてください。下部を見てください)

今、Django は Bcrypt をデフォルトのパスワード保存アルゴリズムとして使おうとします。

bcrypt を使う他の方法

Django 内で bcrypt を用いる方法はいくつかあります。 Django の bcrypt サポート同士では直接的に互換性がありません。アップグレードするために、フォームの bcrypt$(生の bcrypt アウトプット)内で、データベースのハッシュを修正する必要があります。例えば: `bcrypt$$2a$12$NT0I31Sa7ihGEWpka9ASYrEFkhuTNeBQ2xfZskIiiJeyFXhRgS.Sy

作業面の向上¶

PDKDF2 と、 bcrypt アルゴリズムは、沢山のイテレーションとハッシュの循環を用います。これはシステムへの攻撃の手を遅めます。ハッシュ化されたパスワードによって攻撃に立ち向かいます。しかし、コンピュータのマシンパワーの向上とともに、必要なイテレーションの数も増加しました。それ相当なものを選んでいます( Django のリリースの度に数を増やしてます)が、その強度を増したい時もあれば減らしたい時もあるでしょう、セキュリティ環境に応じて、または実行環境に応じて。そうするために、サブクラスを作り適切なアルゴリズムと iterations パラメータの上書きをするでしょう。たとえば、イテレーションの回数を PBKDF2 で増加させるには:

サブクラスを django.contrib.auth.hashers.PBKDF2PasswordHasher という名前で作ります。:

from django.contrib.auth.hashers import PBKDF2PasswordHasher

class MyPBKDF2PasswordHasher(PBKDF2PasswordHasher):
    """
    PBKDF2PasswordHasher のサブクラスで百回以上イテレーションします
    """
    iterations = PBKDF2PasswordHasher.iterations * 100

プロジェクトのどこかでこれを保存してください。例えば、 myproject/hashers.py のようなファイルを置くのがよいでしょう。

2. PASSWORD_HASHERS の中の最初の項目として新しいハッシュを加えます:

PASSWORD_HASHERS = (
    'myproject.hashers.MyPBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.BCryptPasswordHasher',
    'django.contrib.auth.hashers.SHA1PasswordHasher',
    'django.contrib.auth.hashers.MD5PasswordHasher',
    'django.contrib.auth.hashers.CryptPasswordHasher',
)

これだけで – Django は PBKDF2 を使ってパスワードを保存する時に、もっと沢山のイテレーションを用いれるようになりました。

パスワードのアップグレード¶

ログインする時に、パスワードがアルゴリズムよりも好ましいもので保存されていれば、 Django は自動的にアルゴリズムをそちらにアップグレードします。この意味は、古い Django でもユーザがログインするたびにセキュアなものになるということです、そしてまた新しく（そしてより良い）パスワードの保持アルゴリズムが作られるたびにそちらへ切り替えられるということです。

しかしながら、 Django がアップグレードできるパスワードはアルゴリズムとして PASSWORD_HASHERS のなかで宣言されているものだけです。新しいシステムにアップグレードする時には、 以前使っていたものを削除しない ことを気をつけてください。もし削除してしまうと、消去してしまったアルゴリズムをいつまでもアップグレードできないでいることになります。

匿名ユーザ (Anonymous users)¶

class models.AnonymousUser¶

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 を返します。
set_password(), check_password(), save(), delete(), set_groups() および set_permissions() は NotImplementedError を送出します。

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

スーパユーザの作成¶

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

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

ユーティリティはパスワードの入力を促します。入力すると、ユーザは即座に作成されます。 --username や --email オプションを省略すると、ユーティリティはそれらの値を入力するよう促します。

古い Django も使っている場合、以前からあるコマンドラインのスーパユーザ作成方法も使えます:

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

/path/to/ は自分のシステムの Django コードベースへのパスに応じて読み変えて下さい。 manage.py は自動的に正しいパスと環境変数を決定するので、 manage.py を使うよう推奨します。

追加のユーザ情報の保存¶

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

ユーザプロファイルを利用するには、まず、ユーザにひもづけて保存したい情報を入れるためのフィールドや持たせたいメソッド、そして User モデルへの user という名前で OneToOneField を持ったモデルを定義します。 OneToOneField には User に対してユーザごとにモデルが一つだけ生成されるようにします。例をあげると:

from django.contrib.auth.models import User

class UserProfile(models.Model):
    # このフィールドが必要です.
    user = models.OneToOneField(User)

    # 他のフィールドはこちらにあります
    accepted_eula = models.BooleanField()
    facorite_animal = models.CharField(max_length=20, default="Dragons.")

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

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

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

AUTH_PROFILE_MODULE = 'accounts.UserProfile'

ユーザプロファイルモデルが定義されていて、この規則通りになっていた場合、 User のオブジェクトは、 get_profile() というメソッドを持つでしょう。 – これは User ユーザプロファイルモデルに関連づけられたインスタンスを返します。

get_profile() のメソッドは、プロファイルを作る訳ではありません。もし存在しないものがあれば、自身でユーザモデルの django.db.models.signals.post_save のハンドルのシグナルを登録する必要と、ハンドラーの中で、 created が True ならばユーザプロファイルと関連させて作るようにします:

# models.py の中で

from django.contrib.auth.models import User
from django.db.models.signals import post_save

# 上のユーザプロファイルの定義
# ...

def create_user_profile(sender, instance, created, **kwargs):
    if created:
        UserProfile.objects.create(user=instance)

post_save.connect(create_user_profile, sender=User)

Web リクエストに対する認証¶

ここまでのドキュメントは、認証関連のオブジェクトを操作するための低水準の API について扱ってきました。より高水準の API では、 Django はこれらの認証フレームワークを リクエストオブジェクト システム内にフックできます。

まず、 SessionMiddleware および AuthenticationMiddleware を MIDDLEWARE_CLASSES 設定に追加して、これらのミドルウェアをインストールします。詳しくはセッションのドキュメントを参照してください。

ミドルウェアをインストールしたら、ビューから request.user にアクセスできるようになります。 request.user は現在ログインしているユーザの User オブジェクトを表します。ユーザがログインしていなければ、 request.user は AnonymousUser のインスタンスになります (前節を参照してください)。ログインユーザと匿名ユーザは、 is_authenticated() で以下のように区別できます:

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

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

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

authenticate()¶

あるユーザ名とパスワードに対する認証を行うには、 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()¶

ユーザをログインさせるには、ビューの中で 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 'invalid login' error message.

authenticate() は最初に呼び出してください

ユーザを手動でログインさせる場合、 login() を呼び出す前に必ず authenticate() を呼び出してください。 authenticate() は、 User オブジェクトに、そのユーザが認証バックエンドによって正しく認証されたことを示す属性を付加します。 (詳しくは認証バックエンドのドキュメントを参照してください) この情報が後でログインの処理で必要だからです。

ユーザのパスワードを手動で管理する¶

django.contrib.auth.hashers モジュールは関数セットをハッシュ化したパスワードの作成と有効化のために提供しています。独立してそれらを使うことが出来ます。

check_password()¶: リリースノートを参照してください

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

make_password()¶: リリースノートを参照してください

アプリケーションの中で使うフォーマット通りにハッシュ化したパスワードを作りるには、二つの引数をとります: ハッシュ化するアルゴリズムとプレーンテキストのパスワードです。今サポートされているアルゴリズムは : 'sha1', 'md5' で、もし crypt のライブラリがインストールされていれば、それも使えます。もし、二つ目の引数が None だと、使えないパスワードがかえってきます（一つは、 django.contrib.auth.hashers.check_password() によって受け付けられません）

is_password_usable()¶: リリースノートを参照してください

与えられた文字列がハッシュ化されたパスワードであれば、それをチェックします。 django.contrib.auth.hashers.check_password() に反しないかが確かめられます。

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

logout()¶

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() の後で行ってください。

ログインとログアウトのサイン¶

リリースノートを参照してください

auth 認証のフレームワークは二つ signals を使います。それは、ユーザがログインまたはログアウトした時のお知らせのためです。

django.contrib.auth.signals.user_logged_in¶

ユーザがログインに成功した時に送信します。

このシグナルが引数で送られます:

sender: 上にある通り: このクラスはユーザがログインした時のものです
request: 最新のものは HttpRequest のインスタンスです。
user: ログインしたユーザのインスタンスです。

django.contrib.auth.signals.user_logged_out¶

ユーザがログアウトする時に送信するものは

sender: 上にあるとおり: ログアウトしたユーザのクラスまたはユーザが認証されていなければ None を返します。
request: 最新のものは HttpRequest instance.
user: ログアウトしたユーザのインスタンスか、もし認証されていなければ None を返します。

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

生真面目な方法¶

ページへのアクセスを制限する単純で生真面目な方法は、 request.user.is_authenticated() をチェックして、ログインページにリダイレクトするというものです:

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

login_required デコレータ¶

decorators.login_required([redirect_field_name=REDIRECT_FIELD_NAME, login_url=None])¶

手間を省くために、 login_required() デコレータを使えます:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required() に従うと:

もし、ユーザがログインしていなければ、クエリ文字列の現在の完全パスを通って、 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 に値を設定した場合、ログインテンプレートもそれに応じて変更する必要があります、テンプレートのコンテキスト（context) 変数が保持するリダイレクトパスは 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 パラメータを設定しない場合には settings.LOGIN_URL に適切な Django のビュー関数を対応づけておかねばなりません。例えば URLconf に以下のような行を設定します:

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

views.login(request[, template_name, redirect_field_name, authentication_form])¶

URL name: login

the URL documentation に URL パターンについて詳細にのっているので見てください。

django.contrib.auth.views.login は以下のような処理を行います:

GET で呼び出されると、同じ URL に対して POST を行うためのログインフォームを表示します。これについては後でもう少し説明します。
POST で呼び出されると、ユーザのログイン処理を試みます。ログインに成功すると、ビューは next に示された URL にリダイレクトします。 next を指定しない場合、 settings.LOGIN_REDIRECT_URL (デフォルト値は /accounts/profile/) にリダイレクトします。ログインに失敗すると、ログインフォームを再度表示します。

開発者は registration/login.html という名前のテンプレート上でログインフォームを提供せねばなりません。 Django はこのテンプレートに、以下の 3 つのテンプレートコンテキスト変数を渡します:

form: ログインフォームを表現する Form オブジェクトです。 Form オブジェクトの詳細は forms のドキュメントを参照してください。
next: ログイン成功後にリダイレクトされる先の URL です。 URL にはクエリ文字列を含めてかまいません。
site: 現在の Site, SITE_ID のセッティングに従っています。もし、サイトフレームワークがインストールされていなければ、これは、 RequestSite のインスタンスがセットされます。これはサイトの名前とドメインを現在の HttpRequest から取ってきます。
site_name: site.name のための別名（alias)です。もし、サイトフレームワークがインストールされていなければ、 request.META['SERVER_NAME'] の値がセットされます。サイトについてもっと知りたければ “sites” フレームワークを見てください。

registration/login.html テンプレートを呼び出したくないのなら、 URLconf を通じて外部パラメタ template_name をビューに渡してください。例えば、 myapp/login.html を使いたければ、URLconf の行は以下のようになります:

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

GET フィールドの名前を指定できます。 GET フィールドは、 redirect_field_name からビューへの、ログイン後のリダイレクト先を含むURLを設定してください。通常では、このフィールドは next です。

編集の雛型にできるような registration/login.html テンプレートの例を以下に示します。このテンプレートは、 content ブロックの定義された base.html があるという前提で書かれています:

{% extends "base.html" %}
{% load url from future %}

{% block content %}

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

<form method="post" action="{% url 'django.contrib.auth.views.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>

{% endblock %}

リリースノートを参照してください

もし、他の認証を使っているならば( 他の認証データソースを使うを見てください)カスタムされた認証フォームを通って、 authentication_form パラメータを経てログインビューへと行きます。このフォームは request キーワード引数を自身の __init__ メソッドの中で受け取らなくてはいけません。そして、 get_user メソッドは認証されたユーザーオブジェクトを返します。(このメソッドは、成功したフォームバリデーションの後に一度だけ呼ばれます。)

リリースノートを参照してください

login() のビューとその他の組み込みビューは今、全て TemplateResponse のインスタンスを返します。これは、レスポンスデータをレンダリング前に容易に改変できるようにします。もっと情報が欲しければ TemplateResponse documentation を見てください。

その他の組み込みビュー¶

login() ビューに加えて、認証システムはその他の役に立つビューを django.contrib.auth.views: に持っています。:

logout(request[, next_page, template_name, redirect_field_name])¶

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

URL name: logout

URL のドキュメントを見てください。もっと詳しく URL パターンを使う上での情報が載っています。

オプション引数:

next_page: ログアウト後にリダイレクトされる URL です。
template_name: ログアウトページのテンプレートの完全な名前です。この引数を省略すると、デフォルト値の registration/logged_out.html を使います。
redirect_field_name: GET フィールドの名前で、ログアウト後のリダイレクト先 URL を含みます。 GET パラメータが渡されると next_page が上書きされます。

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

title: “Logged out” の文字列を翻訳した値になります。
site: 現在の Site で、 SITE_ID のセッティングに従っています。もし、サイトフレームワークをインストールしていなければ、これは RequestSite のインスタンスがセットされ、サイトの名前てドメインを現在の HttpRequest から取ってきます。
site_name: site.name のための別名（alias)です。もし、サイトフレームワークがインストールされていなければ、 request.META['SERVER_NAME'] の値がセットされます。サイトについてもっと知りたければ “sites” フレームワークを見てください。

logout_then_login(request[, login_url])¶

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

オプション引数:

login_url: ログインページへのリダイレクト先です。この引数を省略すると、デフォルト値の settings.LOGIN_URL を使います。

password_change(request[, template_name, post_change_redirect])¶

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

オプション引数:

template_name: パスワード変更ページのテンプレートの完全な名前です。この引数を省略すると、デフォルト値の registration/password_change_form.html を使います。
post_change_redirect: パスワードの変更に成功した場合の URLリダイレクト先です。

リリースノートを参照してください
password_change_form: “パスワードの変更” フォームのカスタマイズは、 user のキーワード引数を受け取らなくてはいけません。フォームは実際にウーザのパスワードが変更される責任があります。通常では、 PasswordChangeForm になります。

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

form: パスワード変更のためのフォームです。

password_change_done(request[, template_name])¶

ユーザがパスワードを変更した後のページを表示するためのビューです。

URL name: password_change_done

オプション引数:

template_name: パスワード変更完了ページのテンプレートの完全な名前です。この引数を省略すると、デフォルト値の registration/password_change_done.html を使います。

password_reset(request[, is_admin_site, template_name, email_template_name, password_reset_form, token_generator, post_reset_redirect, from_email])¶

ユーザがパスワードをリセットできるように、一回しか使用できないリンクを作成します。また、新たなパスワードをメールで送信します。

from_email 引数が加えられました。

使えないパスワードでフラグ付けされたユーザ( set_unusable_password() を見てください)は、パスワードのリセットをリクエストできません。外部の認証ソース、例えばLDAPのようなものを使う際の悪用を防ぐためです。

URL name: password_reset

オプション引数:

template_name: パスワードリセットページのテンプレートの完全な名前です。この引数を省略すると、デフォルト値の registration/password_reset_form.html を使います。
email_template_name: 新しいパスワードを e-mail で送信する際に使うテンプレートの完全な名前です。この引数を省略すると、デフォルト値の registration/password_reset_email.html を使います。
subject_template_name: 新しいパスワードのemailを生成するのに使うテンプレートのフルネームです。デフォルトでは registration/password_reset_email.html が設定されています。

リリースノートを参照してください
password_reset_form: パスワードのセットに使うフォームです。デフォルトでは PasswordResetForm が設定されています。
token_generator: パスワードのチェックに使うクラスのインスタンスです。通常は default_token_generator に設定されています、これは django.contrib.auth.tokens.PasswordResetTokenGenerator のインスタンスです。
post_reset_redirect: パスワードの変更が成功した後にリダイレクトする URL です。
from_email: 有効な email アドレスです。通常 Django が使うのは DEFAULT_FROM_EMAIL です。

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

form: パスワードリセットのためのフォームです。 (上にある password_reset_form` を見てください)

Email テンプレートコンテキスト:

email : user.email の別名です。
user: 現在の User で、 email フォームフィールドに従っています。アクティブユーザのみが、パスワードをリセットすることができます。( User.is_active is True )
site_name: sit.name のエイリアス（別名）です。もし、インストール済みのサイトフレームワークがない場合は、 request.META['SERVER_NAME'] の値をセットします。これについては “sites” フレームワークをご覧ください。
domain: site.domain のエイリアス（別名）です。もし、サイトフレームワークがインストールされていない場合、これは request.get_host() の値をセットします。
protocol: http or https
uid: ユーザのIDは36進数でエンコードされます。
token: トークンはパスワードが有効なものかをチェックします。

registration/password_reset_email.html （ email ボディテンプレート）にサンプルがあります:

{% load url from future %}
誰かがパスワードの変更を求めたら {{ email }} のように
email から送られたリンクへと飛ぶことになります。下のリンクに従ってください。:
{{ protocol }}://{{ site_name }}{% url 'auth_password_reset_confirm' uidb36=uid token=token %}

同じテンプレートコンテキストが、サブジェクトテンプレートに使われる時、サブジェクトは一行のプレーンテキストでなくてはなりません。

views.password_reset_done(request[, template_name])¶

ユーザがパスワードをリセットした後のページを表示するためのビューです。このビューは password_reset() ビューが post_reset_redirect の URL セットを所持していない時にデフォルトで呼ばれます。

オプション引数:

template_name: パスワードリセット完了ページのテンプレートの完全な名前です。この引数を省略すると、デフォルト値の registration/password_reset_done.html を使います。

password_reset_confirm(request[, uidb36, token, template_name, token_generator, set_password_form, post_reset_redirect])¶

Presents a form for entering a new password.

オプション引数:

uidb36: 36進数でエンコードされたユーザのIDです。デフォルトでは None です。
token: パスワードが有効かをチェックするためのトークンです。デフォルトでは None です。
template_name: 確定したパスワードのビューを表示するテンプレートのフルネームです。
token_generator: パスワードをチェックするためのクラスのインスタンスです。これは default_token_generator がデフォルトです。そして、 django.contrib.auth.tokens.PasswordResetTokenGenerator のインスタンスでもあります。
set_password_form: パスワードをセットするためのフォームとして使用されます。 SetPasswordForm がデフォルトです。
post_reset_redirect: パスワードのリセットが終了した後にリダイレクトされる先です。デフォルトでは None です。

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

form: 新しいユーザのパスワードをセットするためのフォームです（上にある set_password_form を見てください）
validlink: Boolean 型です。 True でリンクが有効か（ uidb36 とトークンの組み合わせ）またはまだ使われていないかです。

password_reset_complete(request[, template_name])¶

ユーザにパスワードの変更が成功したということを伝えるためのビューです。

URL name: password_reset_complete

オプション引数:

template_name: ビューを表示するためのテンプレートのフルネームです。registration/password_reset_complete.html がデフォルトの値になります。

ヘルパー関数¶

redirect_to_login(next[, login_url, redirect_field_name])¶

ログインページへリダイレクトします、ログインに成功したら、トップ画面ではなく、違う URL へと戻ります。

必要な引数:

next: ログインに成功した後のリダイレクト先の URL です。

オプション引数:

login_url: リダイレクトするログインページの URL です。デフォルトでは settings.LOGIN_URL となります。
redirect_field_name: GET フィールドに含まれているログアウト後にリダイレクトする先の URL です。 GET パラメータが渡されていれば next を上書きします。

組み込みフォーム¶

組み込みビューを使いたくないけれども、フォームクラスを書かずに済ませたい場合のために、認証システムは組み込みのフォームを django.contrib.auth.forms でいくつか提供しています:

class AdminPasswordChangeForm¶: Admin インタフェースでユーザのパスワード変更に使われているフォームです。

class AuthenticationForm¶: ユーザをログインさせるためのフォームです。

class PasswordChangeForm¶: ユーザにパスワードを変更させるためのフォームです。

class PasswordResetForm¶: パスワードをリセットし、新たなパスワードを送信するためのフォームです。

class SetPasswordForm¶: 古いパスワードを入力することなく、パスワードを変更させるためのフォームです。

class UserChangeForm¶: ユーザ情報とパーミッションを変更するためのアドミンインターフェースです

class UserCreationForm¶: 新たなユーザを作成するためのフォームです。

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

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

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

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

user_passes_test(func[, login_url=None])¶

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

from django.contrib.auth.decorators import user_passes_test

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

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

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

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

例えば:

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):
    ...

`permission_required` デコレータ¶

decorators.permission_required([login_url=None, raise_exception=False)¶

あるユーザが特定のパーミッションを有しているかのチェックは、比較的よくある操作なので、 Django はショートカットとして permission_required() というデコレータを用意しています。このデコレータを使うと、上の例は以下のように書き直せます:

from django.contrib.auth.decorators import permission_required

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

As for the User.has_perm() method, permission names take the form "<app label>.<permission codename>" (すなわち polls.choice はは polls アプリケーションのモデルへのパーミッションです.)

permission_required() もまた、 login_url を引数に取れます。例えば:

from django.contrib.auth.decorators import permission_required

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

login_required デコレータと同様、 login_url のデフォルト値は settings.LOGIN_URL です。

リリースノートを参照してください

raise_exception パラメータが追加されました。もし、パラメータが与えられると、でコレータは PermissionDenied を送出します。 the 403 (HTTP Forbidden) view を、ログインページへのリダイレクトの代わりに出します。

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

アクセスを汎用ビューに制限するには、 View.dispatch というクラスのメソッドをデコレートする必要があります。クラスのデコレートの詳細を確認してください。

汎用ビューをベースにした関数¶

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

from django.views.generic.date_based import object_detail

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

パーミッション (Permission)¶

Django には単純なパーミッション機構がついてきます。このパーミッション機構は特定のユーザやユーザのグループに対してパーミッションを結びつける手段を提供します。

パーミッション機構は Django の admin サイトでも使われていますが、自作のコード内でも自由に使えます。

“add” フォームをビューし、オブジェクトを追加するためのアクセスを、その型のオブジェクトの “add” パーミッションを持つユーザに制限しています。
変更リストをビューし、”change” フォームをビューしてオブジェクトを変更するためのアクセスを、その型のオブジェクトの “change” パーミッションを持つユーザに制限しています。
あるオブジェクトを削除するためのアクセスを、その型のオブジェクトの “delete” パーミッションを持つユーザに制限しています。

パーミッションはオブジェクトインスタンスごとではなく、オブジェクトの型ごとにグローバルに設定されます。例えば、「Mary はニュース記事を変更できる」のようには書けますが、現状では、「Mary はニュース記事を変更できる。ただし彼女が書いた分だけ」とか、「Mary はある状態にある記事か、ある日時に出版されたか、ある ID の記事だけを変更できる」のようには書けません。後者の機能についてはは、現在 Django の開発者達が議論中です。

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

INSTALLED_APPS 設定に django.contrib.auth を追加している場合、インストールされている全てのアプリケーションのモデルについて、追加 (add)、変更 (change)、および削除 (delete) というデフォルトのパーミッションが作成されます。

これらのパーミッションは、 manage.py syncdb を実行したときに生成されます。厳密には、 django.contrib.auth を INSTALLED_APPS 設定に追加した直後に syncdb を実行すると、その時インストールされていた全てのアプリケーションと、新たに追加したアプリケーションのデフォルトパーミッションが作成されます。以後、 manage.py syncdb を実行するたびに、新たに追加されたモデルのデフォルトパーミッションが生成されます。

もし、アプリケーションを app_label foo という名前にしていてモデルの名前を Bar だと仮定します、標準のパーミッションをテストするにはこのようにします:

add: user.has_perm('foo.add_bar')
change: user.has_perm('foo.change_bar')
delete: user.has_perm('foo.delete_bar')

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

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

この例では、 Task モデルに三つのカスタムパーミッションを作っています、すなわち Task インスタンスによってユーザが出来るアクションが決まります。アプリケーション内でのコードは:

class Task(models.Model):
    ...
    class Meta:
        permissions = (
            ("view_task", "Can see available tasks"),
            ("change_task_status", "Can change the status of tasks"),
            ("close_task", "Can remove a task by setting its status as closed"),
        )

この定義の役割は特別なパーミッションを追加することだけです。 manage.py syncdb を実行すると、コードはパーミッションをチェックする役割を負います。それが実行されるのは、ユーザがアプリケーションによって機能へとアクセスしようとする時（タスクを見て、タスクのステータスを変え、タスクを閉じるような動作）です。上の例に続ければ、ユーザがタスクを見る時にそれと共にチェックします:

user.has_perm('app.view_task')

API リファレンス¶

class models.Permission¶

フィールド¶

Permission オブジェクトには以下のフィールドがあります:

Permission.name¶: 必須です。50 文字以下です。例: 'Can vote'

Permission.content_type¶: 必須です。インストール済みの Django モデルのレコードが入った django_content_type データベーステーブルへの参照です。

Permission.codename¶: 必須です。 100 文字以下です。例: 'can_vote'

メソッド¶

Permission オブジェクトは、他の Django モデルと同じく、標準的なデータアクセスメソッドを備えています。

プログラム的にパーミッションを作る¶

Meta クラス内でカスタムパーミッションが定義される一方、直接的にパーミッションを作ることもまたできます。例えば、 myapp の BlogPost モデルに対して、 can_publish パーミッションを作ろうとすると:

from django.contrib.auth.models import Group, Permission
from django.contrib.contenttypes.models import ContentType

content_type = ContentType.objects.get(app_label='myapp', model='BlogPost')
permission = Permission.objects.create(codename='can_publish',
                                       name='Can Publish Posts',
                                       content_type=content_type)

パーミッションは自身のクラスの user_permissions アトリビュートか、 Group の permissions アトリビュートから User へと割り当てることができます。

認証データのテンプレート上での扱い¶

RequestContext を使っている場合、ログインユーザとそのパーミッションにテンプレートコンテキスト (template context) を使ってアクセスできます。

技術的な話題

デフォルトの設定では、テンプレートコンテキストに RequestContext を使うようになっていて、かつ TEMPLATE_CONTEXT_PROCESSORS の設定に "django.contrib.auth.context_processors.auth" が入っています。この場合にのみ、上記の変数をテンプレートコンテキストの中で使えるようになります。詳しくは RequestContext のドキュメントを参照してください。

ユーザ¶

現在のログインユーザは、 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 %}

このテンプレートコンテキスト変数は、 RequestContext が使われていないと使うことが出来ません。

パーミッション¶

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

バージョン1.3の変更で、 django.contrib.auth.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 %}

グループ (Group)¶

グループは、パーミッションを適用するユーザのカテゴリを作ったり、一連のユーザに何らかのラベルを適用するための汎用的な手段です。一人のユーザは複数のグループに所属できます。

グループに所属したユーザは、そのグループに許可されているパーミッションを自動的に得ます。例えば、 Site editors というグループに can_edit_home_page というパーミッションをがあれば、そのグループに属するユーザはみな, can_edit_home_page のパーミッションを持ちます。

パーミッションだけではなく、グループはユーザをカテゴリに分けてラベルを付けたり、機能を拡張したりできます。例えば、 '特別なユーザ' のグループを作成して、そのグループのユーザ向けに、例えばサイト内のメンバー限定エリアへのアクセスを提供したり、メンバーだけに email メッセージを送るといった、特別な処理を行うコードを書けます。

メッセージ (Message)¶

API リファレンス¶

class models.Group¶

フィールド¶

Group オブジェクトはそれに続くフィールドを持っています:

Group.name¶: 必須です。 80文字以下です。どんな文字でも使えます。例えば: 'Awesome Users' このように。

Group.permissions¶

Many-to-many フィールド Permissions:

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

他の認証データソースを使う¶

ほとんどのケースでは、 Django についてくる認証メカニズムで十分のはずですが、場合によっては別の認証データソース (authentication source) をフックしたい、すなわち、Django 外のユーザ名やパスワードデータや認証メソッドを使いたいようなケースもあることでしょう。

例えば、会社が LDAP 構成を使って社員のユーザ名やパスワードを管理しているとしましょう。ネットワーク管理者にとっても、またユーザ自身にとっても、 LDAP とDjango ベースのアプリケーションの双方で別々のアカウントを維持するのはいささか骨の折れる作業です。

こうした状況を扱うために、 Django の認証システムは別の認証ソースをプラグインできるようになっています。 Django がデフォルトで使っているデータベースのスキームをオーバライドしたり、デフォルトのシステムを他のシステムと並列して動作させたりできます。

authentication backend reference を見てください。もっと詳しい情報が載っています。

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

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

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

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

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

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

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

Note

一度ユーザが認証されると、 Django はユーザのセッション内でどのバックエンドによってユーザが認証されたかを保持します。そして、同じバックエンドを「認証されたユーザ」であることが必要とされる時にアクセスします。この効率性が意味するのは、認証ソースが一回のセッションを基礎としてキャッシュされるということです。だから、もし AUTHENTICATION_BACKENDS を変更すると、セッションデータをクリアしなければ、異なる方法で再認証することができません。これのシンプルな方法は、 Session.objects.all().delete() を実行することです。

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

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

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

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

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

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

class MyBackend(object):
    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(object):
    """
    セッティングにそぐわない認証の ADMIN_LOGIN and ADMIN_PASSWORD

    ログインネームとパスワードのハッシュを使ってみます。例えば:

    ADMIN_LOGIN = 'admin'
    ADMIN_PASSWORD = 'sha1$4e987$afbcf42e21bd417fb71db8c66b321e9fc33051de'
    """

    supports_inactive_user = False

    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(object):

    # ...

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

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

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

匿名ユーザへの権限¶

リリースノートを参照してください

匿名ユーザは認証されていません。すなわち、有効な認証の情報が提供されていません。しかしながら、権限が与えられてないから何もしなくてよいという意味ではありません。最も基本的な部分で、ほとんどの Web サイトはサイトの大部分を匿名ユーザに対して見せています。そして、許可された匿名ユーザはコメントなどを投稿することができます。

Django のパーミッションフレームワークは、匿名ユーザに対してのパーミッションを保持する場所を設けてはいません。ですが、匿名ユーザに対しての権限を指定するための認証バックエンドのカスタムは基礎部分で許可されています。これは特に、再利用できるアプリの作者に取って役に立つものです。認証バックエンドに権限についての全ての問題を任せてしまうことが出来ます。セッティングを必要とするというより、例が匿名ユーザのコントロールです。

アクティブでないユーザの権限¶

リリースノートを参照してください

アクティブでないユーザは、認証されていても is_active が False にセットされているユーザです。しかし、これは何も認証されていないという意味ではありません。例えば、そのようなユーザは自身のアカウントをアクティブにすることができます。

パーミッションシステム内での匿名ユーザに対してのサポートは、アクティブでないユーザがしない、「何かをする権限を得ること」を許可しています。

これをバックエンドで有効にするには、クラスの supports_inactive_user アトリビュートを True にしなければいけません。

supports_inactive_user 属性が存在しないことは、 PendingDeprecationWarning を送出します。もし、 Django 1.3 または、 1.4 ではこの警告は、 DeprecationWarning にアップデートされています。これは大きくうるさげに表示されます。加えて、 supports_inactive_user が False になっていると、 Django 1.5 ではアクティブでないユーザが認証手続きでパスされることをサポートするでしょう。

オブジェクトへのパーミッションのハンドリング¶

Django のパーミッションフレームワークは、オブジェクトへのパーミッションを基礎に持っています、でも、コアにその実装を持っていません。その意味は、オブジェクトへのパーミッションは常に False が返るか、または空っぽのリスト（チェックがどう働いたかに依存します）が返ります。

Django 1.4 documentation

Django でのユーザ認証¶

概要¶

インストール¶

ユーザ (User)¶

API リファレンス¶

フィールド¶

メソッド¶

マネジャ関数¶

基本的な使い方¶

ユーザの作成¶

パスワードの変更¶

Django はどのようにパスワードを保持するか¶

bcrypt を Django で使うには¶

作業面の向上¶

パスワードのアップグレード¶

匿名ユーザ (Anonymous users)¶

スーパユーザの作成¶

追加のユーザ情報の保存¶

Web リクエストに対する認証¶

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

ユーザのパスワードを手動で管理する¶

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

ログインとログアウトのサイン¶

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

生真面目な方法¶

login_required デコレータ¶

その他の組み込みビュー¶

ヘルパー関数¶

組み込みフォーム¶

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

permission_required デコレータ¶

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

汎用ビューをベースにした関数¶

パーミッション (Permission)¶

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

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

API リファレンス¶

フィールド¶

メソッド¶

プログラム的にパーミッションを作る¶

認証データのテンプレート上での扱い¶

ユーザ¶

パーミッション¶

グループ (Group)¶

メッセージ (Message)¶

API リファレンス¶

フィールド¶

他の認証データソースを使う¶

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

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

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

匿名ユーザへの権限¶

アクティブでないユーザの権限¶

オブジェクトへのパーミッションのハンドリング¶

Last update:

`permission_required` デコレータ¶