• Django的 Session 框架
    • 打开 Sessions功能
    • 在视图中使用Session
    • 设置测试Cookies
    • 在视图(View)外使用Session
    • 何时保存Session
    • 浏览器关闭即失效会话 vs 持久会话
    • 其他的Session设置

    Django的 Session 框架

    由于存在的限制与安全漏洞，cookies和持续性会话已经成为Web开发中令人头疼的典范。 好消息是，Django的目标正是高效的“头疼杀手”，它自带的session框架会帮你搞定这些问题。

    你可以用session 框架来存取每个访问者任意数据， 这些数据在服务器端存储，并对cookie的收发进行了抽象。 Cookies只存储数据的哈希会话ID，而不是数据本身，从而避免了大部分的常见cookie问题。

    下面我们来看看如何打开session功能，并在视图中使用它。

    打开 Sessions功能

    Sessions 功能是通过一个中间件(参见第17章)和一个模型(model)来实现的。 要打开sessions功能，需要以下几步操作：

    • 编辑 MIDDLEWARE_CLASSES 配置，确保 MIDDLEWARE_CLASSES 中包含 'django.contrib.sessions.middleware.SessionMiddleware'。

    • 确认 INSTALLED_APPS 中有 'django.contrib.sessions' (如果你是刚打开这个应用，别忘了运行 manage.py syncdb )

    如果项目是用 startproject 来创建的，配置文件中都已经安装了这些东西，除非你自己删除，正常情况下，你无需任何设置就可以使用session功能。

    如果不需要session功能，你可以删除 MIDDLEWARE_CLASSES 设置中的 SessionMiddleware 和 INSTALLED_APPS 设置中的 'django.contrib.sessions' 。虽然这只会节省很少的开销，但积少成多啊。

    在视图中使用Session

    SessionMiddleware 激活后，每个传给视图(view)函数的第一个参数HttpRequest 对象都有一个 session 属性，这是一个字典型的对象。 你可以象用普通字典一样来用它。 例如，在视图(view)中你可以这样用：

    1. # Set a session value:
    2. request.session["fav_color"] = "blue"
    4. # Get a session value -- this could be called in a different view,
    5. # or many requests later (or both):
    6. fav_color = request.session["fav_color"]
    8. # Clear an item from the session:
    9. del request.session["fav_color"]
    11. # Check if the session has a given key:
    12. if "fav_color" in request.session:
    13.     ...

    其他的映射方法，如 keys() 和 items() 对 request.session 同样有效：

    下面是一些有效使用Django sessions的简单规则：

    用正常的字符串作为key来访问字典 request.session ， 而不是整数、对象或其它什么的。Session字典中以下划线开头的key值是Django内部保留key值。 框架只会用很少的几个下划线 开头的session变量，除非你知道他们的具体含义，而且愿意跟上Django的变化，否则，最好 不要用这些下划线开头的变量，它们会让Django搅乱你的应用。比如，不要象这样使用_fav_color 会话密钥(session key)：
    1. request.session['_fav_color'] = 'blue' # Don't do this!
    不要用一个新对象来替换掉 request.session ，也不要存取其属性。 可以像Python中的字典那样使用。 例如：
    1. request.session = some_other_object # Don't do this!
    3. request.session.foo = 'bar' # Don't do this!

    我们来看个简单的例子。 这是个简单到不能再简单的例子：在用户发了一次评论后将has_commented设置为True。 这是个简单（但不很安全）的、防止用户多次评论的方法。

    1. def post_comment(request):
    2.     if request.method != 'POST':
    3.         raise Http404('Only POSTs are allowed')
    5.     if 'comment' not in request.POST:
    6.         raise Http404('Comment not submitted')
    8.     if request.session.get('has_commented', False):
    9.         return HttpResponse("You've already commented.")
    11.     c = comments.Comment(comment=request.POST['comment'])
    12.     c.save()
    13.     request.session['has_commented'] = True
    14.     return HttpResponse('Thanks for your comment!')

    下面是一个很简单的站点登录视图(view)：

    1. def login(request):
    2.     if request.method != 'POST':
    3.         raise Http404('Only POSTs are allowed')
    4.     try:
    5.         m = Member.objects.get(username=request.POST['username'])
    6.         if m.password == request.POST['password']:
    7.             request.session['member_id'] = m.id
    8.             return HttpResponseRedirect('/you-are-logged-in/')
    9.     except Member.DoesNotExist:
    10.         return HttpResponse("Your username and password didn't match.")

    下面的例子将登出一个在上面已通过login() 登录的用户：

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

    注意

    在实践中，这是很烂的用户登录方式，稍后讨论的认证(authentication )框架会帮你以更健壮和有利的方式来处理这些问题。 这些非常简单的例子只是想让你知道这一切是如何工作的。 这些实例尽量简单，这样你可以更容易看到发生了什么

    设置测试Cookies

    就像前面提到的，你不能指望所有的浏览器都可以接受cookie。 因此，为了使用方便，Django提供了一个简单的方法来测试用户的浏览器是否接受cookie。 你只需在视图(view)中调用 request.session.set_test_cookie()

    ，并在后续的视图(view)、而不是当前的视图(view)中检查 request.session.test_cookie_worked() 。

    虽然把 set_test_cookie() 和 test_cookie_worked() 分开的做法看起来有些笨拙，但由于cookie的工作方式，这无可避免。 当设置一个cookie时候，只能等浏览器下次访问的时候，你才能知道浏览器是否接受cookie。

    检查cookie是否可以正常工作后，你得自己用 delete_test_cookie() 来清除它，这是个好习惯。 在你证实了测试cookie已工作了之后这样操作。

    这是个典型例子：

    1. def login(request):
    3.     # If we submitted the form...
    4.     if request.method == 'POST':
    6.         # Check that the test cookie worked (we set it below):
    7.         if request.session.test_cookie_worked():
    9.             # The test cookie worked, so delete it.
    10.             request.session.delete_test_cookie()
    12.             # In practice, we'd need some logic to check username/password
    13.             # here, but since this is an example...
    14.             return HttpResponse("You're logged in.")
    16.         # The test cookie failed, so display an error message. If this
    17.         # were a real site, we'd want to display a friendlier message.
    18.         else:
    19.             return HttpResponse("Please enable cookies and try again.")
    21.     # If we didn't post, send the test cookie along with the login form.
    22.     request.session.set_test_cookie()
    23.     return render_to_response('foo/login_form.html')

    注意

    再次强调，内置的认证函数会帮你做检查的。

    在视图(View)外使用Session

    从内部来看，每个session都只是一个普通的Django model（在 django.contrib.sessions.models 中定义)。每个session都由一个随机的32字节哈希串来标识，并存储于cookie中。 因为它是一个标准的模型，所以你可以使用Django数据库API来存取session。

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

    你需要使用get_decoded() 来读取实际的session数据。 这是必需的，因为字典存储为一种特定的编码格式。

    1. >>> s.session_data
    2. 'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
    3. >>> s.get_decoded()
    4. {'user_id': 42}

    何时保存Session

    缺省的情况下，Django只会在session发生变化的时候才会存入数据库，比如说，字典赋值或删除。

    1. # Session is modified.
    2. request.session['foo'] = 'bar'
    4. # Session is modified.
    5. del request.session['foo']
    7. # Session is modified.
    8. request.session['foo'] = {}
    10. # Gotcha: Session is NOT modified, because this alters
    11. # request.session['foo'] instead of request.session.
    12. request.session['foo']['bar'] = 'baz'

    你可以设置 SESSION_SAVE_EVERY_REQUEST 为 True 来改变这一缺省行为。如果置为True的话，Django会在每次收到请求的时候保存session，即使没发生变化。

    注意，会话cookie只会在创建和修改的时候才会送出。 但如果 SESSION_SAVE_EVERY_REQUEST 设置为 True ，会话cookie在每次请求的时候都会送出。 同时，每次会话cookie送出的时候，其 expires 参数都会更新。

    浏览器关闭即失效会话 vs 持久会话

    你可能注意到了，Google给我们发送的cookie中有 expires=Sun, 17-Jan-2038 19:14:07 GMT; cookie可以有过期时间，这样浏览器就知道什么时候可以删除cookie了。 如果cookie没有设置过期时间，当用户关闭浏览器的时候，cookie就自动过期了。 你可以改变 SESSION_EXPIRE_AT_BROWSER_CLOSE 的设置来控制session框架的这一行为。

    缺省情况下， SESSION_EXPIRE_AT_BROWSER_CLOSE 设置为 False ，这样，会话cookie可以在用户浏览器中保持有效达 SESSION_COOKIE_AGE 秒（缺省设置是两周，即1,209,600 秒）。 如果你不想用户每次打开浏览器都必须重新登陆的话，用这个参数来帮你。

    如果 SESSION_EXPIRE_AT_BROWSER_CLOSE 设置为 True ，当浏览器关闭时，Django会使cookie失效。

    其他的Session设置

    除了上面提到的设置，还有一些其他的设置可以影响Django session框架如何使用cookie，详见表 14-2.

    表 14-2. 影响cookie行为的设置
    设置描述缺省
    SESSION_COOKIE_DOMAIN使用会话cookie（session cookies）的站点。 将它设成一个字符串，就好象“.example.com” 以用于跨站点（cross-domain）的cookie，或None 以用于单个站点。None
    SESSION_COOKIE_NAME会话中使用的cookie的名字。 它可以是任意的字符串。"sessionid"
    SESSION_COOKIE_SECURE是否在session中使用安全cookie。 如果设置 True , cookie就会标记为安全， 这意味着cookie只会通过HTTPS来传输。False

    技术细节

    如果你还是好奇的话，下面是一些关于session框架内部工作方式的技术细节：

    session 字典接受任何支持序列化的Python对象。 参考Python内建模块pickle的文档以获取更多信息。Session 数据存在数据库表 django_session 中Session 数据在需要的时候才会读取。 如果你从不使用 request.session ， Django不会动相关数据库表的一根毛。Django 只在需要的时候才送出cookie。 如果你压根儿就没有设置任何会话数据，它不会 送出会话cookie(除非 SESSION_SAVE_EVERY_REQUEST 设置为 True )。Django session 框架完全而且只能基于cookie。 它不会后退到把会话ID编码在URL中（像某些工具(PHP,JSP)那样）。这是一个有意而为之的设计。 把session放在URL中不只是难看，更重要的是这让你的站点 很容易受到攻击——通过 Referer header进行session ID”窃听”而实施的攻击。

    如果你还是好奇，阅读源代码是最直接办法，详见 django.contrib.sessions 。