セッションを有効にする¶

セッションは、 ミドルウェア の1つを使って実装されています。

セッションの機能を有効にするには、次のように設定を行います。

• MIDDLEWARE 設定を編集し 'django.contrib.sessions.middleware.SessionMiddleware' を含むようにする。 django-admin startproject で作られるデフォルトの settings.py は SessionMiddleware が有効化されています。

セッションを使いたくない場合は、 MIDDLEWARE 内の SessionMiddleware 行と INSTALLED_APPS 内の 'django.contrib.sessions' を削除しても構いません。これで、オーバーヘッドが少しだけ短縮されます。

セッションエンジンを設定する¶

デフォルトでは、Django はセッションを、(django.contrib.sessions.models.Session モデルを用いて) データベースに保存します。これは便利ですが、セットアップによってはセッションのデータを他の場所においたほうが高速化できる場合があります。そのため、Django はセッションデータをファイルシステムやキャッシュに保存するように設定できます。

ビューでセッションを使う¶

SessionMiddleware を有効にすれば、それぞれの HttpRequest オブジェクト（Django のビュー関数に渡される最初の引数）は、辞書ライクなオブジェクトの session 属性を持つようになります。

この request.session には、ビューの好きな場所で、何度でも、読み書きを行うことができます。

class backends.base.SessionBase¶

このオブジェクトは、すべてのセッションオブジェクトのベースクラスとなっているので、以下に挙げるような基本的なディクショナリのメソッドを持っています。

__getitem__(key)¶

例: fav_color = request.session['fav_color']

__setitem__(key, value)¶

例: request.session['fav_color'] = 'blue'

__delitem__(key)¶

例: del request.session['fav_color'] 与えられた key がセッション内にない場合には、KeyError 例外を起こします。

__contains__(key)¶

例: 'fav_color' in request.session

get(key, default=None)¶

例: fav_color = request.session.get('fav_color', 'red')

pop(key, default=__not_given)¶

例: fav_color = request.session.pop('fav_color', 'blue')

keys()¶

items()¶

setdefault()¶

clear()¶

また、次のようなメソッドも利用できます。

flush()¶

セッションから現在のセッションデータを削除し、セッションクッキーを削除します。このメソッドは、前回のセッションデータがユーザのブラウザから再びアクセスされないようにするためなどに使います (たとえば、django.contrib.auth.logout() がこの関数を呼びます)。

set_test_cookie()¶

ユーザのブラウザがクッキーをサポートしているかどうか判定するために、テスト用のクッキーをセットします。クッキーの動作原理により、ユーザが次のページへのリクエストを行わないとこのテストは行えません。詳しい情報については、下の Setting test cookies を読んでください。

test_cookie_worked()¶

ユーザのブラウザがテストクッキーを正しく保存したかどうかに応じて、True または False を返します。クッキーの動作原理により、あらかじめ別のページのリクエストとして set_test_cookie() を呼び出しておく必要があります。詳しい情報については、下の Setting test cookies を読んでください。

delete_test_cookie()¶

テストクッキーを削除します。クッキーをきれいにしておくために使ってください。

get_session_cookie_age()¶

SESSION_COOKIE_AGE の設定値を返します。これはカスタム セッション バックエンドで上書きできます。

set_expiry(value)¶

セッションの有効期限を設定します。以下に挙げるようなさまざまな値を与えることができます。

• もし value が整数なら、与えられた秒数だけ活動がなかった時にセッションを破棄します。たとえば、request.session.set_expiry(300) と呼び出せば、5分後にセッションを破棄するように設定できます。
• もし value が datetime または timedelta オブジェクトであれば、セッションはその日時で終了します。
• もし value が 0 ならば、ユーザのセッションクッキーは、ユーザがウェブブラウザを閉じた時に破棄されます。
• もし value が None ならば、セッションはグローバルなセッション有効期限ポリシーにしたがって扱われます。

セッションの読み込みを行っても、有効期限は延長されません。セッションの有効期限は、セッションが最後に 修正された 時点を基に計算されます。

get_expiry_age()¶

このセッションの有効期限までの残りの秒数を返します。カスタムの有効期限を持たない (または、ブラウザを閉じた時とセットした) セッションの場合、この値は SESSION_COOKIE_AGE と等しいです。

この関数は 2 つの省略可能なキーワード引数を取ることができます。

• modification: セッションを最後に修正した時刻を datetime オブジェクトとして与える。デフォルトは現在の時刻。
• expiry: セッションの有効期限の情報を datetime オブジェクト、int (秒数で)、または None として与えます。デフォルトの値は、もしあれば、セッションに保存されている set_expiry() で得られる値、なければ None です。

注釈

このメソッドは、セッションを保存する際にセッションの有効期限を秒単位で決定するためにセッションバックエンドで使用されます。このようなコンテキスト以外での使用は想定していません。

特に、正しい modification 値があり、 かつ expiry が datetime オブジェクトとしてセットされている場合にのみ、セッションの残り寿命を決定することが 可能 ですが、 modification 値を持っている場合、有効期限を手動で計算する方がより直接的です:

expires_at = modification + timedelta(seconds=settings.SESSION_COOKIE_AGE)

get_expiry_date()¶

このセッションが破棄される日付を返します。カスタムの有効期限を持たない (または、ブラウザを閉じた時とセットした) セッションに対しては、現在時刻から SESSION_COOKIE_AGE の秒数までの日付に等しいです。

この関数は、get_expiry_age() と同じキーワード引数を取ることができ、使用の際の注意点も同じです。

get_expire_at_browser_close()¶

ユーザのセッションクッキーがユーザのブラウザが閉じた時に破棄されるかどうかに応じて、True または False を返します。

clear_expired()¶

保存されているセッションから、有効期限が切れているものを削除します。このクラスメソッドは、clearsessions から呼び出されます。

cycle_key()¶

現在のセッションデータを保持したまま、新しいセッションキーを作成します。django.contrib.auth.login() は、このメソッドを呼び出すことで、過去のセッションを継続できるようにしています。

def post_comment(request, new_comment):
    if request.session.get("has_commented", False):
        return HttpResponse("You've already commented.")
    c = comments.Comment(comment=new_comment)
    c.save()
    request.session["has_commented"] = True
    return HttpResponse("Thanks for your comment!")

def login(request):
    m = Member.objects.get(username=request.POST["username"])
    if m.check_password(request.POST["password"]):
        request.session["member_id"] = m.id
        return HttpResponse("You're logged in.")
    else:
        return HttpResponse("Your username and password didn't match.")

def logout(request):
    try:
        del request.session["member_id"]
    except KeyError:
        pass
    return HttpResponse("You're logged out.")

テストクッキーを設定する¶

利便性のため、Django はユーザのブラウザがクッキーを受け入れることができるかどうかをテストするための方法を提供しています。テストをするには、一度ビューの中で request.session の set_test_cookie() メソッドを呼び出してから、同じビューではなく、次に呼び出されるビューの中で、 test_cookie_worked() メソッドを呼び出します。

このように set_test_cookie() と test_cookie_worked() を分離しなければならないのはちょっと気持ち悪いですが、クッキーの動作原理により、こうするより仕方がないのです。一度ブラウザにクッキーを設定しても、そのクッキーがブラウザに保存されたかどうかを確認するには、ブラウザがもう一度リクエストを行わなければならないからです。

テストクッキーがちゃんと機能していることを確認できたら、delete_test_cookie() を使ってセッションをきれいにしておくことにしましょう。

以下に、テストクッキーの典型的な使用例を挙げます。

from django.http import HttpResponse
from django.shortcuts import render


def login(request):
    if request.method == "POST":
        if request.session.test_cookie_worked():
            request.session.delete_test_cookie()
            return HttpResponse("You're logged in.")
        else:
            return HttpResponse("Please enable cookies and try again.")
    request.session.set_test_cookie()
    return render(request, "foo/login_form.html")

ビューの外でセッションを使う¶

>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore

次のようにして、ビューの外からセッションデータを操作する API が利用可能です。

>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore()
>>> # stored as seconds since epoch since datetimes are not serializable in JSON.
>>> s["last_login"] = 1376587691
>>> s.create()
>>> s.session_key
'2b1189a188b44ad18c35e113ac6ceead'
>>> s = SessionStore(session_key="2b1189a188b44ad18c35e113ac6ceead")
>>> s["last_login"]
1376587691

SessionStore.create() は新しいセッション(つまりセッションストアから読み込まれていない、session_key=None のセッション)を作成するためのものです。save() は既存のセッションを保存するために設計されています（つまり、セッションストアから読み込まれたもの）。新しいセッションに対して save() を呼び出すこともできますが、既存のセッションと session_key が衝突する可能性があります。 create() は save() を呼び出し、使用されていない session_key が生成されるまでループします。

django.contrib.sessions.backends.db バックエンドを使用している場合、各セッションは単なる Django のモデルになっていて、Session モデルは django/contrib/sessions/models.py で定義されています。普通のモデルにすぎないので、普通の Django データベース API からセッションにアクセスできます。

>>> from django.contrib.sessions.models import Session
>>> s = Session.objects.get(pk="2b1189a188b44ad18c35e113ac6ceead")
>>> s.expire_date
datetime.datetime(2005, 8, 20, 13, 35, 12)

セッションのディクショナリを取得するには、get_decoded() を呼ばなければならないことに注意してください。これが必要なのは、ディクショナリがエンコードされたフォーマットで保存されているためです。

>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}

セッションが保存されるタイミング¶

デフォルトでは、Django がセッションデータベースへデータを保存するのは、セッションが修正された時だけ、つまり、ディクショナリ直下の値が代入または削除された時だけです。

# Session is modified.
request.session["foo"] = "bar"

# Session is modified.
del request.session["foo"]

# Session is modified.
request.session["foo"] = {}

# Gotcha: Session is NOT modified, because this alters
# request.session['foo'] instead of request.session.
request.session["foo"]["bar"] = "baz"

上の例の場合、セッションオブジェクトに修正したことを明示的に伝えるためには、modified 属性を設定すれば良いです。

request.session.modified = True

このデフォルトの動作を変更するには、設定ファイルの SESSION_SAVE_EVERY_REQUEST を True に設定します。True に設定すると、Django は1リクエストごとに、セッションをデータベースに保存してくれるようになります。

セッションクッキーが送信されるのは、セッションの作成及び修正時のみであることに注意してください。SESSION_SAVE_EVERY_REQUEST を True に設定すると、各リクエストごとにセッションクッキーが送信されるようになります。

同時に、セッションクッキーの expires 部分も、セッションクッキーが送信されるごとに更新されます。

レスポンスステータスコードが 500 の時には、セッションは保存されません。

ブラウザ起動中のみ有効なセッション vs. 永続的なセッション¶

SESSION_EXPIRE_AT_BROWSER_CLOSE 設定を使うと、セッションフレームワークが、ブラウザ起動中のみ有効なセッションと永続的なセッションのどちらを使うか設定できます。

デフォルトでは、SESSION_EXPIRE_AT_BROWSER_CLOSE は False にセットされていて、セッションクッキーは SESSION_COOKIE_AGE の期間ユーザのブラウザに保持されます。これにより、ユーザはブラウザを開くたびにログインし直さずに済みます。

SESSION_EXPIRE_AT_BROWSER_CLOSE を True に設定すると、Django はブラウザ起動中のみ有効なクッキーを使用します。このクッキーは、ブラウザを閉じた瞬間に破棄されます。ユーザがブラウザを開くたびにログインするようにしたい場合には、この設定を利用してください。

この設定はグローバルなデフォルトですが、1セッションごとのレベルで設定を上書きできます。その場合には、上の using sessions in views で書いたようにして、request.session の set_expiry() メソッドを呼び出してください。

セッションストアのクリア¶

ユーザがウェブサイトで新しいセッションを作成した時、セッションデータはセッションストアに溜め込まれます。データベースのバックエンドを使っている場合には、django_session データベーステーブルが増大し、ファイルバックエンドを使っている場合には、一時ディレクトリのファイル数が増えてゆくでしょう。

この問題を理解するには、データベースバックエンドで起きていることを考えてみてください。ユーザがログインすると、Django は django_session データベースのテーブルに1行を追加します。Django はセッションのデータが変更されるたびに、この行を更新します。ユーザが手動でログアウトすると、Django はこの行を削除します。しかし、ユーザがログアウト しなかった 場合には、この行は決して削除されません。同様のプロセスが、ファイルバックエンドの場合にも発生します。

Django は、有効期限の切れたセッションを自動的に削除する機能を提供 しません 。したがって、定期的に有効期限の切れたセッションを削除する仕事は、開発者の手に委ねられています。Django はこの目的のために、クリーンナップ用の管理コマンド clearsessions を用意しています。たとえば、cron の毎日のジョブに追加するなどの方法で、定期的にこのコマンドを実行することが推奨されています。

キャッシュバックエンドの場合はこの問題が発生しないことに注意してください。キャッシュの場合、不要なデータは自動的に削除されるようになっているからです。しかし、クッキーバックエンドの場合はそうではありません。セッションデータはユーザのブラウザに保存されるからです。

設定¶

以下の Django の設定 を使うと、セッションの動作をコントロールできます。

• SESSION_CACHE_ALIAS
• SESSION_COOKIE_AGE
• SESSION_COOKIE_DOMAIN
• SESSION_COOKIE_HTTPONLY
• SESSION_COOKIE_NAME
• SESSION_COOKIE_PATH
• SESSION_COOKIE_SAMESITE
• SESSION_COOKIE_SECURE
• SESSION_ENGINE
• SESSION_EXPIRE_AT_BROWSER_CLOSE
• SESSION_FILE_PATH
• SESSION_SAVE_EVERY_REQUEST
• SESSION_SERIALIZER

セッションのセキュリティ¶

サイトのサブドメインからは、クライアントに対して、ドメイン全体に対するクッキーを設定できます。信頼できるユーザに管理されていないサブドメインから送られたクッキーを許可している場合、この方法でセッションの固定化 (session fixation) 攻撃が可能になってしまいます。

たとえば、攻撃者が good.example.com にログインして、攻撃者のアカウントに対する有効なセッションを取得したとしましょう。この攻撃者が bad.example.com を自由に使えた場合、サブドメインからは *.example.com に対してクッキーを設定できるので、先ほど取得したセッションを利用して、攻撃者のセッションキーをターゲットの利用者に送信できてしまいます。次にこの利用者が good.example.com を訪問すると、この利用者は攻撃者のアカウントにログインすることになり、そのことに気付かずに大切な個人のデータ (たとえば、クレジットカード情報など) を攻撃者のアカウントに入力してしまう恐れがあります。

もう一つ考えられる攻撃は、good.example.com というサイトが SESSION_COOKIE_DOMAIN を "example.com" に設定していた場合に、そのサイトのセッションクッキーが bad.example.com に送信されてしまう、というものです。

技術的な詳細¶

• セッション辞書は、JSONSerializer を使用する場合、任意の json シリアライズ可能な値を受け入れます。
• セッションデータは、データベースの django_session という名前のテーブルに保存されます。
• Django は必要なときにだけクッキーを送信します。新しくセッションデータを設定しなければ、Django はセッションクッキーを送信しません。

データベースを使ったセッションを拡張する¶

Django に含まれるデータベースを使ったセッションエンジン (具体的に言えば、db と cached_db) をカスタマイズするには、AbstractBaseSession とともに SessionStore クラスを継承する必要があるかもしれません。

AbstractBaseSession と BaseSessionManager は、INSTALLED_APPS に django.contrib.sessions を追加しなくても、django.contrib.sessions.base_session からインポートできます。

class base_session.AbstractBaseSession¶

ベースとなる抽象的なセッションのモデルです。

session_key¶

プライマリーキーです。フィールド自体は40文字までの文字列を格納できますが、現在の実装では、32文字の文字列 (数字と小文字のASCII文字のランダムな列) を生成します。

session_data¶

エンコード・シリアライズされた、セッションディクショナリーを含む文字列です。

expire_date¶

セッションの有効期限を表す datetime オブジェクトです。

有効期限が切れたセッションをユーザが利用することはできませんが、clearsessions 管理コマンドを実行するまでは、ふつうはデータベースに保存されています。

classmethod get_session_store_class()¶

セッションモデルで使用するセッションストアクラスを返します。

get_decoded()¶

デコードしたセッションデータを返します。

デコードは、セッションストアのクラスで実行されます。

BaseSessionManager のサブクラスを作ることで、モデルマネージャをカスタマイズすることもできます。

class base_session.BaseSessionManager¶

encode(session_dict)¶

与えられたセッションディクショナリを、シリアライズ・エンコードした文字列として返します。

エンコードは、モデルクラスに関連付けられたセッションストアのクラスで実行されます。

save(session_key, session_dict, expire_date)¶

与えられたセッションキーに対するセッションデータを保存します。データが空の場合には、セッションを削除します。

SessionStore クラスのカスタマイズは、以下に挙げるメソッドやプロパティをオーバーライドすることで行えます。

class backends.db.SessionStore¶

データベースを使ったセッションストアを実装しています。

classmethod get_model_class()¶

カスタマイズしたセッションモデルを返す必要がある場合には、このメソッドをオーバーライドします。

create_model_instance(data)¶

現在のセッションの状態を表す、セッションモデルオブジェクトの新しいインスタンスを返します。

このメソッドをオーバーライドすると、セッションモデルのデータをデータベースへ保存する前に修正できます。

class backends.cached_db.SessionStore¶

キャッシュデータベースを使ったセッションストアを実装しています。

cache_key_prefix¶

キャッシュのキー文字列を作るためにセッションキーに追加するプリフィックスです。

from django.contrib.sessions.backends.db import SessionStore as DBStore
from django.contrib.sessions.base_session import AbstractBaseSession
from django.db import models


class CustomSession(AbstractBaseSession):
    account_id = models.IntegerField(null=True, db_index=True)

    @classmethod
    def get_session_store_class(cls):
        return SessionStore


class SessionStore(DBStore):
    @classmethod
    def get_model_class(cls):
        return CustomSession

    def create_model_instance(self, data):
        obj = super().create_model_instance(data)
        try:
            account_id = int(data.get("_auth_user_id"))
        except (ValueError, TypeError):
            account_id = None
        obj.account_id = account_id
        return obj

class SessionStore(CachedDBStore):
    cache_key_prefix = "mysessions.custom_cached_db_backend"

    # ...

URL 内のセッション ID¶

Django のセッションフレームワークは、完全かつ単独でクッキーをベースにしています。PHP のように最後の手段として URL にセッション ID を入れるようなことはありません。これは、意図的な設計上の決定です。そのような振る舞いは、URL を醜くしてしまうだけではなく、"Referer" ヘッダを介したセッション ID の盗難に対してサイトを脆弱にしてしまいます。