作成者:
Djangoチーム
翻訳者:
[email protected]
翻訳開始日:
2006-04-27
改訂日:
2006-04-27
原文バージョン:
2744
Djangoは匿名セッションを完全にサポートしています.セッションフレームワークは、各ユーザがデータを保存して取り戻すことを可能にする.cookiesを抽象的に送信受信し、サーバ側にデータを保存する.CookieにはセッションIDが含まれている--データ自体ではない.

セッションの有効化

デフォルトでは、Session機能は有効です.
MIDDLEWARE_を修正CLASSES設定ではセッション機能を手動で有効またはオフにできます.セッション機能をアクティブにするには、MIDDLEWARE_を保証します.CLASSESは「django.contrib.sessions.middleware.SessionMiddleware」を含む.
セッションを使いたくないならMIDDLEWAREでCLASSESからセッションMiddleware行を削除します.これはあなたのシステムの負荷を少し減らします.

viewsでのsessionの使用

各HttpRequestオブジェクト、すなわち任意のDjango view関数の最初のパラメータは、辞書のような動作をする読み書き可能なオブジェクトであるsession属性を有する.
次の標準辞書メソッドが実装されています.

__contains__(key)例:'fav_color' in request.session

__getitem__(key)例:fav_color = request.session['fav_color']

__setitem__(key,value)例:request.session['fav_color'] = 'blue'

__delitem__(key)例:del request.session['fav_color']. This raises KeyError if the given key isn't already in the session.

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

keys()

items()

また、次の3つの方法があります.

set_test_クッキー()は、ユーザブラウザがクッキーをサポートするか否かを判断するテストクッキーを設定する.クッキーの働き方のため、ユーザーの次のリクエストページを取得しない限り、ユーザーブラウザがクッキーをサポートしているかどうかはわかりません.以下の「Settings test cookies」を読むと、より多くの情報が得られます.

test_cookie_worked()ユーザーブラウザがテストクッキーを受け入れるかどうかによってTrueまたはFalseに戻ります.クッキーの特殊な動作のため、前の独立したページ要求でset_を呼び出す必要があります.test_cookie() .以下の「Settings test cookies」を読むと、より多くの情報が得られる.

delete_test_cookie()テストcookieを削除します.クッキーを片付けるのに使えます

あなたのviewのどの部分でもrequestを編集できます.session、viewで何度も値を変更することもできます.

Sessionオブジェクトガイド

は、従来のPython文字列を辞書のrequestとして用いる.セッションのキーこれは硬い規定ではなく慣例である.

下線の先頭のセッションキーはDjangoの内部で使用する.

requestを新しいオブジェクトで上書きしないでください.セッションは、プロパティにアクセスしたり設定したりしないでください.あなたはずっとそれを辞書として使うべきです.

いくつかの例

次の極めて簡単なviewは、ユーザーがコメントを発表した後、has_commented変数の値はTrueに設定.ユーザーがコメントを一度だけ発表できるようにします.

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!')

次のviewは、サイトのユーザーログインに使用されます.

def login(request):
    m = members.get_object(username__exact=request.POST['username'])
    if m.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.")

...これは、上記のlogin()に基づいて、ユーザーのログインに使用されます.

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

テストクッキーの設定

便宜上、Djangoは、ユーザブラウザがクッキーを受け入れるかどうかをテストする簡単で効果的な方法を提供する.1つのviewでrequestを呼び出す.session.set_test_クッキー()は、後のviewでrequestを呼び出す.session.test_cookie_worked()--同じviewの2回の呼び出しではないことに注意してください.
不器用に見えるset_test_Cookie()およびtest_cookie_worked()を2段階に分けて実行する方法は不可能である.クッキーを設定すると、ブラウザの次のリクエストが受信されたかどうかはわかりません.
テストが完了したらdelete_をタイムリーに使用します.test_クッキー()テストクッキーを片付けるのは良い習慣です.
次に、一般的なアプリケーションの例を示します.

def login(request):
    if request.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_to_response('foo/login_form.html')

view以外でセッションを使用する

システム内部では、各セッションはDjango modelです.Session modelはdjango/contrib/sessions/modelsに定義する.py. 通常のmodelなので、通常のDjangoデータベースAPIを使用してsessionsにアクセスできます.

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

getを呼び出す必要があることに注意してください.decoded()はsession辞書を得る.この辞書は符号化された後に格納されるので、このステップは必須です.

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

セッションの保存

デフォルトでは、Djangoはセッションが変更されたときにのみデータベースにセッションを保存します.つまり、セッションが割り当てられたり削除されたりした場合:

# Session 
request.session['foo'] = 'bar'

# Session 
del request.session['foo']

# Session 
request.session['foo'] = {}

# Gotcha: Session  ,  
# request.session['foo']   request.session.
request.session['foo']['bar'] = 'baz'

このデフォルトの動作を変更するには、SESSION_SAVE_EVERY_REQUESTはTrueに設定.SESSION_SAVE_EVERY_REQUESTはTrueであり、Djangoは単独の要求が発生した場合にsessionをデータベースに保存する.
注意セッションクッキーは、1つのセッション変数が作成または変更された場合にのみクライアントに送信.SESSION_SAVE_EVERY_REQUESTがTrueである、セッションクッキーはいずれかのリクエスト時に送信される.
同様に、セッションクッキーのexpires部分は、セッションクッキーの送信時にも自動的に更新される.

設定

いくつかのDjango settingsでsessionの動作を制御できます.

SESSION_COOKIE_AGE

デフォルト:120,9600(秒単位で2週間)
session cookieの有効期間は秒で計算する.

SESSION_COOKIE_DOMAIN

デフォルト:None
セッションクッキーのドメインを使用します.セッションクッキーをドメイン間で動作する場合は「.lawrence.com」のように設定し、そうでない場合はNone(標準クッキー動作)に設定します.

SESSION_COOKIE_NAME

デフォルト:'sessionid'
session cookieの名前任意に設定できます.

SESSION_SAVE_EVERY_REQUEST

デフォルト:False
リクエストごとにセッションデータを保存するかどうか.値がFalse(デフォルト)の場合、セッションの内容が変更する場合にのみ保存されます.すなわち、辞書の値が割り当てられたり削除する場合にのみ保存されます.

テクノロジーの詳細

session辞書はpickleable Pythonオブジェクトを受け入れる.詳細については、the pickle moduleを参照してください.

Sessionデータがデータベースに保存されているdjango_セッションテーブル

Djangoは必要に応じてのみクッキーを送信.セッションデータを設定していない場合は、クッキーは送信されません.

URLのセッションID

Django sessionsフレームワークはcookieに基づいて、それは完全で独立している.セッションidをurlに入れることを最後の手段としない(PHPはそうである).私たちはわざとurlを使わないようにしました.その行為がurlを醜くしただけでなく、主にあなたのサイトが攻撃されやすいからです.(「Refer」ヘッドでsession-IDを盗む).