Django 会话、用户和注册

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_datedatetime.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.表 14-2. 影响cookie行为的设置设置描述缺省SESSION_COOKIE_DOMAIN使用会话cookie（session cookies）的站点。 将它设成一个字符串，就好象“.example.com” 以用于跨站点（cross-domain）的cookie，或None 以用于单个站点。NoneSESSION_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 。用户与Authentication通过session，我们可以在多次浏览器请求中保持数据， 接下来的部分就是用session来处理用户登录了。 当然，不能仅凭用户的一面之词，我们就相信，所以我们需要认证。当然了，Django 也提供了工具来处理这样的常见任务（就像其他常见任务一样）。 Django 用户认证系统处理用户帐号，组，权限以及基于cookie的用户会话。 这个系统一般被称为 auth/auth (认证与授权)系统。 这个系统的名称同时也表明了用户常见的两步处理。 我们需要验证 (认证) 用户是否是他所宣称的用户(一般通过查询数据库验证其用户名和密码)验证用户是否拥有执行某种操作的 授权 (通常会通过检查一个权限表来确认)根据这些需求，Django 认证/授权 系统会包含以下的部分：用户 : 在网站注册的人权限 : 用于标识用户是否可以执行某种操作的二进制(yes/no)标志组 :一种可以将标记和权限应用于多个用户的常用方法Messages : 向用户显示队列式的系统消息的常用方法如果你已经用了admin工具(详见第6章)，就会看见这些工具的大部分。如果你在admin工具中编辑过用户或组，那么实际上你已经编辑过授权系统的数据库表了。打开认证支持像session工具一样，认证支持也是一个Django应用，放在 django.contrib 中，所以也需要安装。 与session系统相似，它也是缺省安装的，但如果它已经被删除了，通过以下步骤也能重新安装上：根据本章早前的部分确认已经安装了session 框架。 需要确认用户使用cookie，这样sesson 框架才能正常使用。将 'django.contrib.auth' 放在你的 INSTALLED_APPS 设置中，然后运行 manage.py syncdb以创建对应的数据库表。确认 SessionMiddle