深入浅出的解析session和cookie

为什么需要

cookie

• 为了记录状态
  
  • web1.0时代,web应用只是用来实现资源的共享
  • web2.0时代,web应用强调的是交互,比如登录,但是http协议本身是无状态的协议; 为了实现交互的效果,就需要记录请求的状态, session和cookie技术就随之产生.

session

• cookie,每次客户端访问都得带着cookie,如果cookie多了. 就增加了客户端与服务端的数据传输量,所以session出现了

session,cookie特征

• session和cookie都是由服务器生成的.都是会话跟踪技术
• session和cookie都是键值对应的,即session和cookie就是用来保存特定的值的一种技术
• session是保存在服务器的,cookie是返回给客户端的, session可以是很多个值, 而sessionid,就是一个钥匙, 一般session的ID是通过类似于cookie的形式返回给客户端.session依赖于cookie
• 客户端(浏览器)会在发送请求的时候,自动将本地存活的cookie封装在信息头中发送给服务器
• cookie和session都是有生命周期的
  * cookie的生命周期受到cookie自身的生命周期以及客户端是否保留cookie文件的影响.
  * 单个cookie保存的数据不能超过4k,很多浏览器都限制一个站点最多保存20个cookie
  * session的生命周期受到session自身的存活周期以及客户端连接是否关闭的影响
  
  • cookie和session都是有作用域的.
• 为什么说cookie不安全呢?
  
  • cookie是返回给客户端的,并且保存在客户端的.
    
    • cookie的内容和工作原理就存在破解的可能性;
    • 如果服务器不对cookie的有效性做检查,则很容易产生安全问题,但是如果不做检查,这个cookie就没啥意义了
• 重要状态走session, 不重要走cookie.登录信息用session, 购物车最好用cookie,但是cookie是可以在客户端禁用的,这时候要使用cookie+数据库的方式实现,当从cookie中不能取出数据时,就从数据库获取.
• session为什么相对cookie更加安全呢?
  
  • 用户拿到的仅仅只是一个sessionID,和实际记录的状态值没有任何关系,这就意味着用户没有办法通过sessionID去推测服务器是通过什么样的值,什么样的逻辑来实现状态的判断,从而就没有办法去破解服务器的状态验证机制
• 对于应用来说,只要记录状态,其实不是说必须通过session或者cookie来实现的,只需要能够在完成A操作的时候, 产生一个记录状态的值,并且返回给客户端,然后在客户端再通过一定的技术(JS)来封装状态值到请求中,发送给服务器,从而完成一个生成-校验的过程即可, 因此, 像token等技术,其实都是在session和cookie的基础上扩展而来的,校验机制更加安全而已.

cookie机制

session机制

session缺点

• cookie被禁止,session也被禁止,可以通过url重写拜托cookie
• 访问服务器用户很多,如果恰好session内容过于复杂,会导致内存溢出
• 集群部署,需要做session同步

其他几种认证登录方式

HTTP Basic Auth

• 每次请求API都提供用户的username和password.它是配合RESTful API使用的最简单的认证方式,只需提供用户名密码即可,但是由于把用户名和密码暴露给第三方客户端的风险,所以生产环境下被使用的越来越少.因此,在开发对外开发的RESTful API时,尽量避免采用HTTP Basic Auth

OAuth

开放的授权标准,允许用户让第三方应用访问该用户在某一个web服务器上存储的私密的资源,而无需将用户名和密码提供给第三方应用
* 允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特点服务提供者的数据,每一个令牌授权一个特定的第三方系统.
* OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息,而非所有内容

所以其适用于个人消费者类的互联网产品,不太适合拥有自有认证权限管理的企业应用;

JWT的Token认证

这个就先简单了解吧.后面再写一篇博客,专门讲token