【21.1】Django框架之会话Session补充

【一】前言引入

【1】HTTP特性之无状态

• 因为因特网HTTP协议的特性，每一次来自于用户浏览器的请求(request)都是无状态的、独立的。
• 通俗地说，就是无法保存用户状态，后台服务器根本就不知道当前请求和以前及以后请求是否来自同一用户。
• 对于静态网站，这可能不是个问题，而对于动态网站，尤其是京东、天猫、银行等购物或金融网站，无法识别用户并保持用户状态是致命的，根本就无法提供服务。
• 你可以尝试将浏览器的cookie功能关闭，你会发现将无法在京东登录和购物。

【2】解决连接方案(Cookie)

• 为了保持连接状态，网站会通过用户的浏览器在用户机器内被限定的硬盘位置中写入一些数据，也就是所谓的Cookie。
• 通过Cookie可以保存一些诸如用户名、浏览记录、表单记录、登录和注销等各种数据。
• 但是这种方式非常不安全，因为Cookie保存在用户的机器上，如果Cookie被伪造、篡改或删除，就会造成极大的安全威胁，因此，现代网站设计通常将Cookie用来保存一些不重要的内容，实际的用户数据和状态还是以Session会话的方式保存在服务器端。

【3】解决数据安全方案(Session)

• Session就是在服务器端的‘Cookie’，将用户数据保存在服务器端，远比保存在用户端要安全、方便和快捷得多。

• Session依赖Cookie！但与Cookie不同的地方在于Session将所有的数据都放在服务器端，用户浏览器的Cookie中只会保存一个非明文的识别信息，比如哈希值。

• Session是大多数网站都需要具备的功能。Django为我们提供了一个通用的Session框架，并且可以使用多种session数据的保存方式：

  • 保存在数据库内

  • 保存到缓存

  • 保存到文件内

  • 保存到cookie内

• 通常情况，没有特别需求的话，请使用保存在数据库内的方式，尽量不要保存到Cookie内。

【扩展】

• Django的session框架支持匿名会话，封装了cookies的发送和接收过程。
• cookie包含一个会话ID而不是数据本身(除非你使用的是基于后端的cookie)。
• Django的会话框架完全地、唯一地基于Cookie。
• 它不像PHP一样，把会话的ID放在URL中。
• 那样不仅使得URL变得丑陋，还使得你的网站易于受到通过"Referer"头部进行窃取会话ID的攻击。

【二】启用会话

• Django通过一个内置中间件来实现会话功能，要启用会话就要先启用该中间件。
• 编辑settings.py中的MIDDLEWARE设置，确保存在django.contrib.sessions.middleware.SessionMiddleware这一行。
• 默认情况在新建的项目中它是存在的。
• 如果你不想使用会话功能，那么在settings文件中，将SessionMiddleware从MIDDLEWARE中删除，将django.contrib.sessions从INSTALLED_APPS中删除就OK了。

【三】配置会话引擎

• 默认情况下，Django将会话数据保存在数据库内(通过使用django.contrib.sessions.models.Session模型)。
• 当然，你也可以将数据保存在文件系统或缓存内。

【1】基于数据库的会话

• 确保在INSTALLED_APPS设置中django.contrib.sessions的存在，然后运行manage.py migrate命令在数据库内创建sessions表。

【2】基于缓存的会话

• 从性能角度考虑，基于缓存的会话会更好一些。

• 但是首先，你得先配置好你的缓存。

• 如果你定义有多个缓存，Django将使用默认的那个。

• 如果你想用其它的，请将SESSION_CACHE_ALIAS参数设置为那个缓存的名字。

【3】保存数据的两种方式

(1)方式一

• 一是将SESSION_ENGINE设置为"django.contrib.sessions.backends.cache"，简单的对会话进行保存。
• 但是这种方法不是很可靠，因为当缓存数据存满时将清除部分数据，或者遇到缓存服务器重启时数据将丢失。

(2)方式二

• 为了数据安全保障，可以将SESSION_ENGINE设置为"django.contrib.sessions.backends.cached_db"。
• 这种方式在每次缓存的时候会同时将数据在数据库内写一份。
• 当缓存不可用时，会话会从数据库内读取数据。

(3)小结

• 两种