session, cookie, token 的应用以及发展历程
session,cookie,token到底有什么区别和联系
参考URL: https://zhuanlan.zhihu.com/p/92949110
由于http是无状态的会话,所以我们需要一个东西来记录。目前我们用到的主要有三种:session,cookie 和 token。
-
session:
在服务器端记录,每一个会话会产生一个sessionId。当用户打开某个web应用时,便与web服务器产生一次session。服务器使用 sessionId 把用户的信息临时保存在了服务器上,用户离开网站后session会被销毁。这样服务器就会根据每个人sessionId的不同,区别开谁是谁了,从而返回给用户不同的请求结果。
缺点:
如果使用单个服务器的话,用户过多的话,会造成服务器开销太大。如果我们系统采用分布式的话,我们登录时,响应我们的那台机器会记录我们登录信息,万一下一个请求,响应我们的不是原来那台机器的话,它并没有存储我们之前会话信息,就会认为我们并没有登录。session粘连或者session复制都不是特别好的方案。
那既然服务端存储这些 SessionId 这么麻烦,人类又想出一招,那就是把这些SessionId 都存储在客户端。这个时候,cookie运用而生
-
cookie
cookie是服务端保存在客户端的临时的少量的数据。cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的,所以浏览器加入了一些限制确保cookie不会被恶意使用,同时不会占据太多磁盘空间,所以每个域的cookie数量是有限的。但是,cookie 这种方式很容易被恶意攻击者入侵,那么又怎么验证客户端发给我的session id 的确是我生成的呢? 如果不去验证,服务器都不知道他们是不是合法登录的用户, 那些不怀好意的家伙们就可以伪造session id , 为所欲为了。
这就需要我们用一种加密的方法或者可以说暗号,来验证这个id是否由我自己的服务器之前生成而非恶意攻击者篡改的。
-
token
token的定义:Token是服务端生成的一串字符串,当作客户端进行请求的一个令牌,当第一次登录后,服务器生成一个Token并将此Token返回给客户端,以后客户端只需带上这个Token前来请求数据即可,无需再次带上用户名和密码。
session的原理
(1)服务器在处理客户端请求过程中会创建session,并且为该session生存唯一的session ID。(这个session ID在随后的请求中会被用来重新获得已经创建的session。在session被创建后,就可以调用session相关的方法向session中新增内容,这些内容只会保存在服务器中)
(2)服务器将session ID发送到客户端
(3)当客户端再次请求时,就会带上这个session ID
(4)服务器接收到请求之后就会一句Session ID 找到相应的Session ,完成请求
ps
1、虽然session保存在服务器,但它还是需要客户端浏览器的支持,因为session需要使用cookie作为识别标志。服务器会向客户端发送一个名为JSEDDIONID的cookie,它的值为session ID。
2、当cookie被禁用时,可以使用url重写的方法:将session写在URL中,服务器在进行解析。
cookie的生命周期
cookoe的生存时间是整个会话期间:浏览器会将cookie保存在内存中,浏览器关闭时自动删除这个cookie。
cookie的生存时间是长久有效的:手动将cookie报存在客户端的硬盘中,浏览器关闭的话,cookie页不会清除;下次在打开浏览器访问对应网站内容,这个cookie就会自动再次发送到服务器。
token认证流程
token 的认证流程与cookie很相似
用户登录,成功后服务器返回Token给客户端。
客户端收到数据后保存在客户端
客户端再次访问服务器,将token放入headers中
服务器端采用filter过滤器校验。校验成功则返回请求数据,校验失败则返回错误码
token和session对比选型
Token是什么?和session、cookie相比,使用场景有什么区别?
参考URL: https://www.detechn.com/post/383.html
传统的应用是将Session放在应用服务器上,而将生成的JSESSIONID放在用户浏览器的Cookie中,而这种模式在前后端分离中就会出现以下问题
1,开发繁琐。
2,安全性和客户体验差
3,有些前端技术不支持Cookie,如微信小程序
这种情况下,前后端之间使用Token(令牌)进行通信就完美的解决上面的问题。
与session验证项目token的优点:
- 支持跨域访问: Cookie是不允许垮域访问的,这一点对Token机制是不存在的,前提是传输的用户认证信息通过HTTP头传输。
- 无状态(也称:服务端可扩展行):Token机制在服务端不需要存储session信息,因为Token 自身包含了所有登录用户的信息,只需要在客户端的cookie或本地介质存储状态信息.
- 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成,只要在你的API被调用的时候,你可以进行Token生成调用即可。
- 适用接口跨平台: 当你的客户端是一个原生平台(iOS, Android,Windows 8等)时,Cookie是不被支持的(你需要通过Cookie容器进行处理),这时采用Token认证机制就会简单得多。
- CSRF:因为不再依赖于Cookie,所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
- 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库(.NET, Ruby, Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft)
总结: token的验证机制比session的验证机制更加灵活方便。 现在一般新项目使用token的比较多!
参考
SpringSecurity实现用户名密码登录(Token)
参考URL: https://www.cnblogs.com/fanqisoft/p/10665144.html