第十四章： 会话、用户和注册

存取Cookies

在Django中处理持久化，大部分时候你会更愿意用高层些的session 和/或 后面要讨论的user 框架。 但在此之前，我们需要停下来在底层看看如何读写cookies。 这会帮助你理解本章节后面要讨论的工具是如何工作的，而且如果你需要自己操作cookies，这也会有所帮助。

读取已经设置好的cookies极其简单。 每一个`` HttpRequest`` 对象都有一个`` COOKIES`` 对象，该对象的行为类似一个字典，你可以使用它读取任何浏览器发送给视图（view）的cookies。

def show_color(request):
    if "favorite_color" in request.COOKIES:
        return HttpResponse("Your favorite color is %s" %             request.COOKIES["favorite_color"])
    else:
        return HttpResponse("You don't have a favorite color.")

写cookies稍微复杂点。 你需要使用 HttpResponse对象的 set_cookie()方法。 这儿有个基于 GET 参数来设置 favorite_color

cookie的例子：

def set_color(request):
    if "favorite_color" in request.GET:

        # Create an HttpResponse object...
        response = HttpResponse("Your favorite color is now %s" %             request.GET["favorite_color"])

        # ... and set a cookie on the response
        response.set_cookie("favorite_color",
                            request.GET["favorite_color"])

        return response

    else:
        return HttpResponse("You didn't give a favorite color.")

你可以给 response.set_cookie() 传递一些可选的参数来控制cookie的行为，详见表14-1。

.. table:: 表 14-1: Cookie 选项

   +---------------------------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   |参数                             |缺省值                     |描述                                                                                                                                                                                |
   +=================================+===========================+====================================================================================================================================================================================+
   |``max_age``                      |``None``                   |cookie需要延续的时间（以秒为单位） 如果参数是\ `` None`` ，这个cookie会延续到浏览器关闭为止。                                                                                       |
   +---------------------------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   |``expires``                      |``None``                   |cookie失效的实际日期/时间。 它的格式必须是：\ `` "Wdy, DD-Mth-YY HH:MM:SS GMT"`` 。如果给出了这个参数，它会覆盖\ `` max_age`` 参数。                                                |
   +---------------------------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   |``path``                         |``"/"``                    |cookie生效的路径前缀。 浏览器只会把cookie回传给带有该路径的页 面，这样你可以避免将cookie传给站点中的其他的应用。                                                                    |
   |                                 |                           |                                                                                                                                                                                    |
   |                                 |                           |当你不是控制你的站点的顶层时，这样做是特别有用的。                                                                                                                                  |
   +---------------------------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   |``domain``                       |``None``                   |这个cookie有效的站点。 你可以使用这个参数设置一个跨站点（cross-domain）的cookie。 比如，\ `` domain=".example.com"`` 可以设置一个在\ `` www.example.com`` 、\ `` www2.example.com`` 以及\ `` an.other.sub.domain.example.com`` 站点下都可读到的cookie。|
   |                                 |                           |                                                                                                                                                                                    |
   |                                 |                           |如果这个参数被设成\ `` None`` ，cookie将只能在设置它的站点下可以读到。                                                                                                              |
   +---------------------------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   |``False``                        |``False``                  |如果设置为 ``True`` ，浏览器将通过HTTPS来回传cookie。                                                                                                                               |
   +---------------------------------+---------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

好坏参半的Cookies

也许你已经注意到了，cookies的工作方式可能导致的问题。 让我们看一下其中一些比较重要的问题：

cookie的存储是自愿的，一个客户端不一定要去接受或存储cookie。 事实上，所有的浏览器都让用户自己控制 是否接受cookies。 如果你想知道cookies对于Web应用有多重要，你可以试着打开这个浏览器的 选项：

尽管cookies广为使用，但仍被认为是不可靠的的。 这意味着，开发者使用cookies之前必须 检查用户是否可以接收cookie。

Cookie(特别是那些没通过HTTPS传输的)是非常不安全的。 因为HTTP数据是以明文发送的，所以 特别容易受到嗅探攻击。 也就是说，嗅探攻击者可以在网络中拦截并读取cookies，因此你要 绝对避免在cookies中存储敏感信息。 这就意味着您不应该使用cookie来在存储任何敏感信息。

还有一种被称为”中间人”的攻击更阴险，攻击者拦截一个cookie并将其用于另一个用户。 第19章将深入讨论这种攻击的本质以及如何避免。

即使从预想中的接收者返回的cookie也是不安全的。 在大多数浏览器中您可以非常容易地修改cookies中的信息。有经验的用户甚至可以通过像mechanize(http://wwwsearch.sourceforge.net/mechanize/) 这样的工具手工构造一个HTTP请求。

因此不能在cookies中存储可能会被篡改的敏感数据。 在cookies中存储 IsLoggedIn=1 ，以标识用户已经登录。 犯这类错误的站点数量多的令人难以置信； 绕过这些网站的安全系统也是易如反掌。

打开 Sessions功能

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

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

2. 确认 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)中你可以这样用：

# Set a session value:
request.session["fav_color"] = "blue"

# Get a session value -- this could be called in a different view,
# or many requests later (or both):
fav_color = request.session["fav_color"]

# Clear an item from the session:
del request.session["fav_color"]

# Check if the session has a given key:
if "fav_color" in request.session:
    ...

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

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

用正常的字符串作为key来访问字典 request.session ， 而不是整数、对象或其它什么的。

Session字典中以下划线开头的key值是Django内部保留key值。 框架只会用很少的几个下划线 开头的session变量，除非你知道他们的具体含义，而且愿意跟上Django的变化，否则，最好 不要用这些下划线开头的变量，它们会让Django搅乱你的应用。

比如，不要象这样使用`` _fav_color`` 会话密钥(session key)：

request.session['_fav_color'] = 'blue' # Don't do this!

不要用一个新对象来替换掉 request.session ，也不要存取其属性。 可以像Python中的字典那样使用。 例如：

request.session = some_other_object # Don't do this!

request.session.foo = 'bar' # Don't do this!

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

def post_comment(request):
    if request.method != 'POST':
        raise Http404('Only POSTs are allowed')

    if 'comment' not in request.POST:
        raise Http404('Comment not submitted')

    if request.session.get('has_commented', False):
        return HttpResponse("You've already commented.")

    c = comments.Comment(comment=request.POST['comment'])
    c.save()
    request.session['has_commented'] = True
    return HttpResponse('Thanks for your comment!')

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

def login(request):
    if request.method != 'POST':
        raise Http404('Only POSTs are allowed')
    try:
        m = Member.objects.get(username=request.POST['username'])
        if m.password == request.POST['password']:
            request.session['member_id'] = m.id
            return HttpResponseRedirect('/you-are-logged-in/')
    except Member.DoesNotExist:
        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.")

注意

在实践中，这是很烂的用户登录方式，稍后讨论的认证(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已工作了之后这样操作。

这是个典型例子：

def login(request):

    # If we submitted the form...
    if request.method == 'POST':

        # Check that the test cookie worked (we set it below):
        if request.session.test_cookie_worked():

            # The test cookie worked, so delete it.
            request.session.delete_test_cookie()

            # In practice, we'd need some logic to check username/password
            # here, but since this is an example...
            return HttpResponse("You're logged in.")

        # The test cookie failed, so display an error message. If this
        # were a real site, we'd want to display a friendlier message.
        else:
            return HttpResponse("Please enable cookies and try again.")

    # If we didn't post, send the test cookie along with the login form.
    request.session.set_test_cookie()
    return render_to_response('foo/login_form.html')

注意

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

在视图(View)外使用Session

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

>>> 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() 来读取实际的session数据。 这是必需的，因为字典存储为一种特定的编码格式。

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

何时保存Session

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

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

你可以设置 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.

技术细节

如果你还是好奇的话，下面是一些关于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 。

打开认证支持

像session工具一样，认证支持也是一个Django应用，放在 django.contrib 中，所以也需要安装。 与session系统相似，它也是缺省安装的，但如果它已经被删除了，通过以下步骤也能重新安装上：

1. 根据本章早前的部分确认已经安装了session 框架。 需要确认用户使用cookie，这样sesson 框架才能正常使用。

2. 将 'django.contrib.auth' 放在你的 INSTALLED_APPS 设置中，然后运行 manage.py syncdb以创建对应的数据库表。

3. 确认 SessionMiddleware 后面的 MIDDLEWARE_CLASSES 设置中包含 'django.contrib.auth.middleware.AuthenticationMiddleware' SessionMiddleware。

这样安装后，我们就可以在视图(view)的函数中处理user了。 在视图中存取users，主要用 request.user ；这个对象表示当前已登录的用户。 如果用户还没登录，这就是一个AnonymousUser对象(细节见下)。

你可以很容易地通过 is_authenticated() 方法来判断一个用户是否已经登录了：

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

使用User对象

User 实例一般从 request.user ，或是其他下面即将要讨论到的方法取得，它有很多属性和方法。 AnonymousUser 对象模拟了 部分 的接口，但不是全部，在把它当成真正的user对象 使用前，你得检查一下 user.is_authenticated() 表14-3和14-4分别列出了`` User`` 对象中的属性（fields)和方法。

.. table:: 表 14-4. ``User`` 对象方法

    

创建用户

使用 create_user 辅助函数创建用户:

>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user(username='john',
...                                 email='jlennon@beatles.com',
...                                 password='glass onion')

在这里， user 是 User 类的一个实例，准备用于向数据库中存储数据。（create_user()实际上没有调用save()）。 create_user() 函数并没有在数据库中创建记录，在保存数据之前，你仍然可以继续修改它的属性值。

>>> user.is_staff = True
>>> user.save()

修改密码

你可以使用 set_password() 来修改密码：

>>> user = User.objects.get(username='john')
>>> user.set_password('goo goo goo joob')
>>> user.save()

除非你清楚的知道自己在做什么，否则不要直接修改 password 属性。 其中保存的是密码的 加入salt的hash值 ，所以不能直接编辑。

一般来说， User 对象的 password 属性是一个字符串，格式如下：

hashtype$salt$hash

这是哈希类型，salt和哈希本身，用美元符号（$）分隔。

hashtype 是 sha1 （默认）或者 md5 ，它是用来处理单向密码哈希的算法。 Salt是一个用来加密原始密码以创建哈希的随机字符串，例如:

sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4

User.set_password() 和 User.check_password() 函数在后台处理和检查这些值。

salt化得哈希值

一次 哈希 是一次单向的加密过程，你能容易地计算出一个给定值的哈希码，但是几乎不可能从一个哈希码解出它的原值。

如果我们以普通文本存储密码,任何能进入数据库的人都能轻易的获取每个人的密码。 使用哈希方式来存储密码相应的减少了数据库泄露密码的可能。

然而，攻击者仍然可以使用 暴力破解 使用上百万个密码与存储的值对比来获取数据库密码。 这需要花一些时间，但是智能电脑惊人的速度超出了你的想象。

更糟糕的是我们可以公开地得到 rainbow tables （一种暴力密码破解表）或预备有上百万哈希密码值的数据库。 使用rainbow tables可以在几秒之内就能搞定最复杂的一个密码。

在存储的hash值的基础上，加入 salt 值（一个随机值），增加了密码的强度，使得破解更加困难。 因为每个密码的salt值都不相同，这也限制了rainbow table的使用，使得攻击者只能使用最原始的暴力破解方法。

加入salt值得hash并不是绝对安全的存储密码的方法，然而却是安全和方便之间很好的折衷。

处理注册

我们可以使用这些底层工具来创建允许用户注册的视图。 最近每个开发人员都希望实现各自不同的注册方法，所以Django把写注册视图的工作留给了你。 幸运的是，这很容易。

作为这个事情的最简化处理, 我们可以提供一个小视图, 提示一些必须的用户信息并创建这些用户。 Django为此提供了可用的内置表单, 下面这个例子就使用了这个表单:

from django import forms
from django.contrib.auth.forms import UserCreationForm
from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response

def register(request):
    if request.method == 'POST':
        form = UserCreationForm(request.POST)
        if form.is_valid():
            new_user = form.save()
            return HttpResponseRedirect("/books/")
    else:
        form = UserCreationForm()
    return render_to_response("registration/register.html", {
        'form': form,
    })

这个表单需要一个叫 registration/register.html 的模板。这个模板可能是这样的：

{% extends "base.html" %}

{% block title %}Create an account{% endblock %}

{% block content %}
  <h1>Create an account</h1>

  <form action="" method="post">
      {{ form.as_p }}
      <input type="submit" value="Create the account">
  </form>
{% endblock %}