Token , Cookie , Session
2017-05-20 本文已影响0人
清一语
HTTP 的无状态
HTTP协议是无状态的,这与HTTP协议本来的目的是相符的,客户端只需要简单的向服务器请求下载某些文件,无论是客户端还是服务器都没有必要纪录彼此过去的行为,每一次请求之间都是独立的,好比一个顾客和一个自动售货机或者一个普通的(非会员制)大卖场之间的关系一样。 但是如果能够提供一些按需生成的动态信息会使web变得更加有用,就萌发了cookie 和session 等客户端与服务器之间保持状态的解决方案。
Session -- 创建,保存在服务器中的会话
- 当用户打开某个web应用时,便与web服务器产生一个session。服务器使用session把用户的信息临时保存在了服务器上, 存放于内存。
- session是由服务器创建的,跟浏览器没有半毛钱关系,浏览器只是拿到一个session 的 ID。
- session是消耗服务器内存的,所以要合理使用session。
缺陷:如果web服务器做了负载均衡,那么下一个操作请求到了另一台服务器的时候session会丢失。
Cookie -- 服务器上生成,保存于客户端
- cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该cookie发送给服务器。
- 一个cookie的设置以及发送过程分为以下四步:
客户端发送一个http请求到服务器端
服务器端发送一个http响应到客户端,其中包含Set-Cookie头部
客户端发送一个http请求到服务器端,其中包含Cookie头部
服务器端发送一个http响应到客户端 - 局限:由于cookie是存在客户端上的,所以浏览器加入了一些限制确保cookie不会被恶意使用,同时不会占据太多磁盘空间,所以每个域的cookie数量是有限的 ; cookie 不是很安全 , 别人可以利用储存的本地的cookie 。
Token -- 验证用户身份的令牌
- 唯一的 ,比较安全
- token 验证流程 :
客户端使用用户名跟密码请求登录。
服务端收到请求,去验证用户名与密码。
验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端。
客户端收到 Token 以后可以把它存储起来。
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据。
cookie 和session
- cookie数据存放在客户的浏览器上,session数据放在服务器上。
- cookie不是很安全,考虑到安全应当使用session。
- session会在一定时间内保存在服务器上。当访问增多,会比较占用服务器的性能考虑到减轻服务器性能方面,应当使用cookie。
- 单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
- 将登陆信息等重要信息存放为session,其他信息如果需要保留,可以放在cookie中
6 . 由于采用服务器端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助于cookie机制来达到保存标识的目的,但实际上它还有其他选择 --由于cookie可以被人为的禁止,必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器.
token 和session
- session只提供一种简单的认证,即有此 session ID ,即认为有此 User的全部权力 ; token Token是唯一的。提供的是认证 和 授权 ,认证是针对用户,授权是针对app, 不可以转移到其它 app上,也不可以转到其它 用户上。
- 所以,如果用户数据可能需要和第三方共享,或者允许第三方调用 API 接口,用 token 。如果只是自己的网站,自己的 app,用session也可以。