2、Django用户认证之cookie和session

一、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被盗用，其余人也能够登陆网址。

 

二、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机制来达到保存标识的目的，但实际上它还有其余选择。

 

三、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的值。

 

四、cookie和session的关系

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

 

五、Cookies与Session的应用场景

Cookies的安全性能一直是倍受争议的。虽然Cookies是保存在本机上的，可是其信息的彻底可见性且易于本地编辑性，每每能够引发不少的安全问题。因此Cookies到底该不应用，到底该怎样用，就有了一个须要给定的底线。

session应用场景

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

cookie应用场景

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

六、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 的行为。