目录
前言
Django 完全支持匿名会话。通过会话框架可以针对网站的每个访客存储和检索任意的数据。Django 把会话数据存储在服务器端，而且对发送和接收 cookie 的过程做了抽象。cookie 中存储的是会话 ID，而不是数据本身（除非使用基于 cookie 的后端）——这样实现更安全。
启用会话
会话由一个中间件实现。 django-admin startproject 命令创建的 settings.py 文件默认已激活 SessionMid-dleware 。为了保证会话可用， MIDDLEWARE_CLASSES 设置中要列出 'django.contrib.sessions.middleware.Ses-sionMiddleware' 。
如果不想使用会话，可以把 MIDDLEWARE_CLASSES 中的 SessionMiddleware 和 INSTALLED_APPS 中的 'djan-
go.contrib.sessions' 删掉。这样能节省少量的开销。
配置会话引擎
默认情况下，Django 在数据库中存储会话（使用 django.contrib.sessions.models.Session 模型）。这样虽
然方便，但是某些情况下在别处存储数据速度更快，因此 Django 允许修改配置，把会话数据存储在文件系统
或缓存中。
使用基于数据库的会话
如果想把会话存储在数据库中，要在 INSTALLED_APPS 设置中添加 'django.contrib.sessions' 。然后，运行manage.py migrate 命令，创建存储会话数据的数据表。
使用基于缓存的会话
如果 CACHES 设置定义了多个缓存后端，Django 将使用默认的那个。若想使用其他缓存后端，把 SES-SION_CACHE_ALIAS 设为那个后端的名称。配置好缓存之后，在缓存中存储会话数据有两种方式：
1. 把 SESSION_ENGINE 设为 "django.contrib.sessions.backends.cache" ，使用简单的缓存会话存储器。此时，会话数据直接存储在缓存中。然而，会话数据可能无法持久存储，因为缓存存储器空间用完或缓存服务器重启后数据会丢失。
2. 若想持久存储缓存的会话数据，把 SESSION_ENGINE 设为 "django.contrib.sessions.back-ends.cached_db" 。此时使用的是直写式缓存（write-through cache），写入缓存的数据也会写入数据库。如果缓存中没有会话数据，再到数据库中读取。
这两种会话存储器的速度都十分快，不过简单缓存更快，因为它不做持久存储。多数情况下， cached_db 后端足够快了；然而，如果你还需要那最后一点性能，而且想随着时间的推移擦除会话数据，可以使用 cache后端。如果使用 cached_db 后端，还要按照 15.2.1 节的说明配置。
使用基于文件的会话
若想使用基于文件的会话，把 SESSION_ENGINE 设为 "django.contrib.sessions.backends.file" 。你可能还想配置 SESSION_FILE_PATH （默认为 tempfile.gettempdir() 得到的结果，通常是 /tmp ），设定 Django 存储会话文件的位置。确保 Web 服务器有指定位置的读写权限。
会话对象指导方针
• request.session 字典的键使用普通的 Python 字符串。这不是不得违反的规则，而是一种约定。
• 以下划线开头的键是保留的，供 Django 内部使用。
• 别使用新对象覆盖 request.session ，也别访问或设定它的属性。像 Python 字典那样使用它。
会话序列化
在 1.6 版之前，Django 默认使用 pickle 序列化会话数据，然后再存入后端。如果使用的是签名的 cookie 会话后端，而且攻击者知道了 SECRET_KEY （Django 没有内在的漏洞会导致这个密钥泄露），那么攻击者可以在会话中插入字符串，反序列化会话后在服务器中执行任意的代码。网上充斥着这种简而易行的技术。虽然为了防止篡改，cookie 中存储的是签名后的会话数据，可是一旦 SECRET_KEY 泄露，远程执行代码的漏洞就凸显出来了。把序列化会话数据的方式由 pickle 改成 JSON 可以降低这种攻击的可行性。为此，Django1.5.3 引入了一个新设置，即 SESSION_SERIALIZER ，用于自定义会话的序列化格式。为了向后兼容，Django1.5.x 默认使用 django.contrib.sessions.serializers.PickleSerializer ；但是，为了增强安全性，Django1.6 之后默认使用 django.contrib.sessions.serializers.JSONSerializer
持续到浏览器关闭的会话与持久会话
可以使用 SESSION_EXPIRE_AT_BROWSER_CLOSE 设置控制会话框架使用持续到浏览器关闭的会话还是持久会话SESSION_EXPIRE_AT_BROWSER_CLOSE 的默认值是 False ，这意味着会话 cookie 在用户的浏览器中存储的时间等
于 SESSION_COOKIE_AGE 。如果不想让用户每次打开浏览器后都重新登录，使用这个默认值。
如果把 SESSION_EXPIRE_AT_BROWSER_CLOSE 设为 True ，Django 将使用持续到浏览器关闭的会话，即用户关闭
浏览器后会话 cookie 即告过期。
清理会话存储器
用户创建的会话不断积累，占据着会话存储器。Django 没有提供自动清除过期会话的机制，因此你自己要定期清除过期会话。为此，Django 提供了一个清理命令： clearsessions 。建议你定期执行这个命令，比如说定义一个每天执行的 cron 作业。
注意，缓存后端不受这个问题的影响，因为缓存会自动删除过期的数据。cookie 亦然，因为会话数据由用户的浏览器存储。