如何使用session¶
Django全面支持匿名session。会话框架允许您以每个站点访问者为基础存储和检索
任
意数据。它将数据存储在服务器端并提取Cookie的发送和接收。Cookie包含会话ID -
不是数据本身(除非您使用基于cookie的后端)。
启用session¶
会话通过一个中间件来实现。
要启用会话功能,请执行以下操作:
编辑MIDDLEWARE
设置并确保它
含 'django.contrib.sessions.middleware.SessionMiddleware'
。settings.py
创建的默认值 已 激活。django-
admin startproject
SessionMiddleware
如果你不想使用会话,你还不如删除 SessionMiddleware
从线MIDDLEWARE
和'django.contrib.sessions'
从
你的INSTALLED_APPS
。它会为你节省一点点的开销。
配置session引擎¶
默认情况下,Django将会话存储在数据库中(使模
型 django.contrib.sessions.models.Session
)。虽然这很方便,但在某些设置中,将会话数据存
储在别处会更快,因此可以将Django配置为将会话数据存储在文件系统或缓存中。
使用数据库支持的session¶
如果您想使用数据库支持的会话,则需要添加 'django.contrib.sessions'
到您的INSTALLED_APPS
设
置中。
配置 完安装后,运行安装存储会话数据的单个数据库表。manage.py migrate
使用缓存session¶
为了获得更好的性能,您可能需要使用基于缓存的会话后端。
要使用Django的缓存系统存储会话数据,首先需要确保已经配置了缓存; 详细信息请参阅缓存文档。
警告
如果您使用Memcached缓存后端,则只应使用基于缓存的会话。本地内存高速缓存后端不会保留足够长的数据作为一个好选择,并且直接使用文件或数据库会话会更快,而不是通过文件或数据库高速缓存后端发送所有内容。此外,本地内存缓存后端不是多进程安全的,因此可能不是生产环境的理想选择。
如果您在中定义了多个缓存CACHES
,Django将使用默认缓存。要使用另一个缓存,请设置SESSION_CACHE_ALIAS
为该缓存的名称。
一旦你的缓存配置完毕,你有两个选择如何将数据存储在缓存中:
- 设置
SESSION_ENGINE
于"django.contrib.sessions.backends.cache"
一个简单的缓存会话存储。会话数据将直接存储在缓存中。但是,会话数据可能不是持久性的:如果缓存填满或缓存服务器重新启动,缓存数据可能会被逐出。 - 对于持久性缓存数据,请设置
SESSION_ENGINE
为"django.contrib.sessions.backends.cached_db"
。这使用直写式高速缓存 - 每写入高速缓存也将写入数据库。如果数据尚未存在于缓存中,则会话读取仅使用数据库。
两个会话存储都非常快,但简单缓存更快,因为它忽略了持久性。在大多数情况下,cached_db
后端速度会很快,但如果您需要最后一点的性能,并且愿意让会话数据不时被删除,则cache
后端会为您提供帮助。
如果您使用cached_db
会话后端,则还需要遵循使用数据库支持的会话的配置说明。
使用基于文件的session¶
要使用基于文件的会话,请将SESSION_ENGINE
设置设置为 "django.contrib.sessions.backends.file"
。
您可能还想设置该SESSION_FILE_PATH
设置(tempfile.gettempdir()
很可能是默认输出/tmp
)来控制Django存储会话文件的位置。务必检查您的Web服务器是否有权读取和写入此位置。
使用基于cookie的session¶
要使用基于cookies的会话,请将SESSION_ENGINE
设置设置为"django.contrib.sessions.backends.signed_cookies"
。会话数据将使用Django的加密签名 和SECRET_KEY
设置工具进行存储。
注意
建议您将SESSION_COOKIE_HTTPONLY
设置保留True
为禁止访问来自JavaScript的存储数据。
警告
如果SECRET_KEY没有保密并且正在使用 PickleSerializer
,则可能导致任意远程代码执行。
拥有该攻击者SECRET_KEY
不仅可以生成伪造的会话数据,您的站点将信任该数据,还可以远程执行任意代码,因为数据是使用pickle序列化的。
如果您使用基于cookie的会话,请特别注意您的密钥始终保持完全保密,以供任何可能远程访问的系统使用。
会话数据已签名但未加密
当使用cookies后端时,会话数据可以被客户端读取。
MAC(消息认证码)用于保护数据免受客户端的改变,以便会话数据在被篡改时将失效。如果存储cookie的客户端(例如您的用户的浏览器)无法存储所有会话cookie并丢弃数据,则会发生相同的失效。尽管Django压缩数据,但仍然完全有可能超过每个cookie 4096个字节的常见限制。
没有新鲜度保证
还要注意的是,尽管MAC可以保证数据的真实性(数据是由您的网站而不是其他人生成的)和数据的完整性(数据的完整性和正确性),但它不能保证数据的真实性,即你正在被送回你发给客户的最后一件东西。这意味着对于会话数据的某些用途,cookie后端可能会让您重新开始重放攻击。与其他会话后端不同,后者保留每个会话的服务器端记录,并在用户注销时使其失效,当用户注销时,基于cookie的会话不会失效。因此,如果攻击者窃取用户的cookie,即使用户注销,他们也可以使用该cookie作为该用户登录。如果Cookie比您的年龄大,Cookie只会被检测为“陈旧”SESSION_COOKIE_AGE
。
性能
在视图中使用会话¶
当SessionMiddleware
被激活时,每个HttpRequest
对象 - 任何Django视图函数的第一个参数 - 都会有一个session
属性,它是一个类似字典的对象。
您可以阅读它并request.session
在您的视图中随时写信。您可以多次编辑它。
-
类
backends.base.