二、Django用户认证之cookie和session

1、cookie原理

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

为了维持用户在网站的状态，比如登陆、购物车等，出现了先后出现了四种技术，分别是隐藏表单域、URL重写、cookie、session。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

当你在浏览网站的时候，WEB 服务器会先送一小小资料放在你的计算机上，Cookie 会帮你在网站上所打的文字或是一些选择，都记录下来。当下次你再光临同一个网站，WEB 服务器会先看看有没有它上次留下的 Cookie 资料，有的话，就会依据 Cookie里的内容来判断使用者，送出特定的网页内容给你。 Cookie 的使用很普遍，许多有提供个人化服务的网站，都是利用 Cookie来辨认使用者，以方便送出使用者量身定做的内容，同时也可以缓解服务端的压力，比如使用cookie之后，用户不需要在短期内频繁查询数据库进行登录，他可以通过cookie进行直接登录，当然，这也会带来安全问题，一旦你的cookie被盗用，其他人也可以登录网址。

2、session原理

Session 是存放在服务器端的，类似于Session结构来存放用户数据，当浏览器第一次发送请求时，服务器自动生成了一个Session和一个Session ID用来唯一标识这个Session，并将其通过响应发送到浏览器。当浏览器第二次发送请求，会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上，服务器从请求中提取出Session ID，并和保存的所有Session ID进行对比，找到这个用户对应的Session。

一般情况下，服务器会在一定时间内（默认30分钟）保存这个 Session，过了时间限制，就会销毁这个Session。在销毁之前，程序员可以将用户的一些数据以Key和Value的形式暂时存放在这个 Session中。当然，也有使用数据库将这个Session序列号后保存起来的，这样的好处是没了时间的限制，坏处是随着时间的增加，这个数据库会急速膨胀，特别是访问量增加的时候。一般还是采取前一种方式，以减轻服务器压力。

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

3、cookie与session的区别

简单来说，cookie数据保存在客户端，session数据保存在服务器端。

浏览器cookie

如果浏览器使用的是 cookie，那么所有的数据都保存在浏览器端，比如你登录以后，服务器设置了 cookie用户名(username),那么，当你再次请求服务器的时候，浏览器会将username一块发送给服务器，这些变量有一定的特殊标记。服务器会解释为 cookie变量。所以只要不关闭浏览器，那么 cookie变量便一直是有效的，所以能够保证长时间不掉线。如果你能够截获某个用户的 cookie变量，然后伪造一个数据包发送过去，那么服务器还是认为你是合法的。所以，使用 cookie被攻击的可能性比较大。如果设置了的有效时间，那么它会将 cookie保存在客户端的硬盘上，下次再访问该网站的时候，浏览器先检查有没有 cookie，如果有的话，就读取该 cookie，然后发送给服务器。如果你在机器上面保存了某个论坛 cookie，有效期是一年，如果有人入侵你的机器，将你的 cookie拷走，然后放在他的浏览器的目录下面，那么他登录该网站的时候就是用你的的身份登录的。所以 cookie是可以伪造的。当然，伪造的时候需要主意，直接copy cookie文件到 cookie目录，浏览器是不认的，他有一个index.dat文件，存储了 cookie文件的建立时间，以及是否有修改，所以你必须先要有该网站的 cookie文件，并且要从保证时间上骗过浏览器。

服务端session，客户端sessionID

当你登录一个网站的时候，如果web服务器端使用的是session,那么所有的数据都保存在服务器上面，客户端每次请求服务器的时候会发送当前会话的sessionid，服务器根据当前sessionid判断相应的用户数据标志，以确定用户是否登录，或具有某种权限。由于数据是存储在服务器上面，所以你不能伪造，但是如果你能够获取某个登录用户的sessionid，用特殊的浏览器伪造该用户的请求也是能够成功的。sessionid是服务器和客户端链接时候随机分配的，一般来说是不会有重复，但如果有大量的并发请求，也不是没有重复的可能性，我曾经就遇到过一次。登录某个网站，开始显示的是自己的信息，等一段时间超时了，一刷新，居然显示了别人的信息。

Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID 为标识符来存取服务器端的Session存储空间。而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效。

服务器也可以通过URL重写的方式来传递SessionID的值，因此不是完全依赖Cookie。如果客户端Cookie禁用，则服务器可以自动通过重写URL的方式来保存Session的值，并且这个过程对程序员透明。

可以试一下，即使不写Cookie，在使用request.getCookies();取出的Cookie数组的长度也是1，而这个Cookie的名字就是SESSIONID，还有一个很长的二进制的字符串，是SessionID的值。

4、cookie和session的关系

Cookies是属于Session对象的一种。但有不同，Cookies不会占服务器资源，是存在客服端内存或者一个cookie的文本文件中；而“Session”则会占用服务器资源。所以，尽量不要使用Session，而使用Cookies。但是我们一般认为cookie是不可靠的，session是可靠的，但是目前很多著名的站点也都用cookie。有时候为了解决禁用cookie后的页面处理，通常采用url重写技术，调用session中大量有用的方法从session中获取数据后置入页面。

5、Cookies与Session的应用场景

Cookies的安全性能一直是倍受争议的。虽然Cookies是保存在本机上的，但是其信息的完全可见性且易于本地编辑性，往往可以引起很多的安全问题。所以Cookies到底该不该用，到底该怎样用，就有了一个需要给定的底线。

session应用场景

通过session累计用户数据。例如，一个未登录用户访问了京东网站，这个时候京东对其下发了一个 cookie，假设cookie的名字叫做abc，那这条记录就是 abc＝001，同时京东的后台也生成了一个 session id，它的值也为 001， 001 这个客户在 2 点、 3 点、 4 点分别添加了三件商品到购物车，这样后台也记录了 session id 为 001的用户的购物车里面已经有三件商品，并且只要每次客户端 cookie 带上来的值里面包含session id，后台都能够展示相应的数据，如果这个时候，在浏览器里面清空 cookie，cookie 数据消失之后，后台和客户端无法建立对应关系，购物车的数据就会失效了。
通过session实现单点登录。一个用户帐号成功登录后，在该次session还未失效之前，不能在其他机器上登录同一个帐号。登录后将用户信息保存到session中，如果此时在另外一台机器上一个相同的帐号请求登录，通过遍历（遍历的意思就是将所有session都查看一遍）Web服务器中所有session并判断其中是否包含同样的用户信息，如果有，在另一台机器上是不能登录该帐号的。

cookie应用场景

判断注册用户是否已经登录网站：用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录流程。
根据用户的爱好定制内容：网站创建包含用户浏览内容的cookies，在用户下次访问时，网站根据用户的情况对显示的内容进行调整，将用户感兴趣的内容放在前列。
实现永久登录：如果用户是在自己家的电脑上上网，登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。
实现自动登录：当用户注册网站后，就会收到一个惟一用户ID的cookie。用户再次连接时，这个用户ID会自动返回，服务器对它进行检查，确定它是否是注册用户且选择了自动登录，从而使用户无需给出明确的用户名和密码，就可以访问服务器上的资源。
使用cookie记录各个用户的访问计数：获取cookie数组中专门用于统计用户访问次数的cookie的值，将值加1并将最新cookie输出。
使用cookie记住用户名与用户密码。用户勾选了“自动登录”，就把用户名和密码的信息放到cookie中。同时可设置有效期。
用cookie实现新手大礼包等弹窗功能。同理，将新手大礼包弹窗逻辑写入到cookie中，并设置相应的有效期。比如在有效期内只弹出一次该弹窗，超过有效期登录后再次弹出弹窗。

6、cookie参数

语法：Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

a、value

value 部分，通常是一个 name=value 格式的字符串。事实上，这种格式是原始规范中指定的格式，但是浏览器并不会对 cookie 值按照此格式来验证。实际上，你可以指定一个不含等号的字符串，它同样会被存储。然而，最常用的使用方式是按照 name=value 格式来指定 cookie 的值（大多数接口只支持该格式）。

发送回服务器的cookie只包含cookie设置的值，而不包含cookie的其他可选项,而且浏览器不会对cookie做任何更改，会原封不动的发送回服务器。当存在多个cookie时，用分号和空格隔开：

Cookie: name=value; name1=value1; name2=value2/pre>

b、cookie过期时间

如果不设置cookie过期时间，cookie会在会话结束后销毁，称为会话cookie。如果想将会话cookie设置为持久cookie，只需设置一下cookie的过期时间即可，该选项的值是一个 Wdy, DD-Mon-YYYY HH:MM:SS GMT 日期格式的值。注意这个失效日期则关联了以 name-domain-path-secure 为标识的 cookie。要改变一个 cookie 的失效日期，你必须指定同样的组合。

持久cookie是无法改成会话cookie，除非删除这个cookie，然后重新建立这个cookie。

c、domain 选项

domian选项设置了cookie的域，只有发向这个域的http请求才能携带这些cookie。一般情况下domain会被设置为创建该cookie的页面所在的域名。

像 Yahoo! 这种大型网站，都会有许多 name.yahoo.com 形式的站点（例如：my.yahoo.com, finance.yahoo.com 等等）。将一个 cookie 的 domain 选项设置为 yahoo.com，就可以将该 cookie 的值发送至所有这些站点。浏览器会把 domain 的值与请求的域名做一个尾部比较（即从字符串的尾部开始比较），并将匹配的 cookie 发送至服务器。

d、path 选项

path选项和domain选项类似，只有包含指定path的http请求才能携带这些cookie。这个比较通常是将 path 选项的值与请求的 URL 从头开始逐字符比较完成的。如果字符匹配，则发送 Cookie 消息头，例如：

set-cookie:namevalue;path=/blog

所以包含/blog的http请求都会携带cookie信息。

e、secure 选项

该选项只是一个标记而没有值。只有当一个请求通过 SSL 或 HTTPS 创建时，包含 secure 选项的 cookie 才能被发送至服务器。这种 cookie 的内容具有很高的价值，如果以纯文本形式传递很有可能被篡改。

事实上,机密且敏感的信息绝不应该在 cookie 中存储或传输，因为 cookie 的整个机制原本都是不安全的。默认情况下，在 HTTPS 链接上传输的 cookie 都会被自动添加上 secure 选项。

f、HTTP-Only

HTTP-Only 的意思是告之浏览器该 cookie 绝不能通过 JavaScript 的 document.cookie 属性访问。设计该特征意在提供一个安全措施来帮助阻止通过 JavaScript 发起的跨站脚本攻击 (XSS) 窃取 cookie 的行为。