Cookie Session Token
三者的关系
这三者都是和维持状态信息有关系,简单来说就是当你登录以后,想维持每一个页面都保持登录的状态。要是你不用上面的三种技术,想要维持用户的登录状态信息是十分麻烦的,就只能每次都携带登录的账号密码给后端,每次的进行前后端的登录验证。
先来讲一下Cookie
前端登录时,把账号和密码发送给后端,后端验证通过以后把账号密码返回给前端,前端把后端返回回来的账号密码保存到游览器的小型数据库里面,就是我们说的Cookie,以后每次给后端进行信息传递时都会自动的带上Cookie。
Cookie是直接存储在客户端游览器上面的,客户可以进行篡改,而且Cookie的使用是可以手动禁用的。
再来讲一下Session:
首先也是前端把登录时的账号密码发送到后端,后端接收到前端的账号密码信息以后,会形成一个key、value形式的数据,用key来确认唯一标识,用value来保存前端穿的信息,可以直接把前端传的一整个对象保存下来。然后把key只进行加密形成一串字符串,保存到请求头里面的set-cookie属性里面,发送给前端。当游览器发现你有set-cookie属性,就会自动把set-cookie里面的SessionID存到Cookie里面,就不需要自己手动在前端调用set-cookie方法获取再进行保存,在下一次请求时也会自动的把SessionID放到cookie里面,整个过程都是自动完成的,用起来就十分方便。
优点是比cookie安全,容量也比cookie大,但是在高并发时,还是会占用游览器的资源和内存,还有就是扩展性比较差和跨域限制。下面解释一下:
就比如登录时前端给后端服务器传了账号密码,只有一个后端服务器接收到了,并形成了只有他自己知道的Session数据,其他的后端并不知道Session数据,集群在下一次的负载均衡以后就可能不是和原来的那台服务器进行访问了,前端把Session传给后端,后端就会判定你没有登录。还有就是在现在前后端分离的架构里面,每一个前端(电脑,手机)都会有一个自己的端口和域名,这个时候前端给后端发送请求就有跨域问题,在出现跨域问题时,前端默认是不把cookie传给后端的,我们既要在后端设置允许跨域,还需要在前端单独设置跨域的cookie传递,所以在集群的情况下,Session就已经不再适用了。
最后来讲一下Token:
说白了Token就是加密以后的字符串,就先来讲一下jwt令牌
它是由三段结构组成
·· 第一段是在说明用了什么算法和Token的类型,这个是不可逆的,就确保了安全性
- 第二段就是你要传递的数据
- 第三段:
他会把第一段的header和payload相加,再加上只有你自己知道一个私钥,最后通过header里面指定的算法来进行加密,就得到了第三段。
首先前端先发送一个带有账号密码的数据给后端,后端拿到以后进行jwt加密,形成jwt令牌,然后把这个jwt令牌(Token)给前端,前端拿到以后,不用存储,在下次和后端交互时,在请求头的Authorization加上Token就行了,后端拿到以后进行解密和检验。这样子前后端都不需要保存登录的数据信息,即解决了跨域,又解决了存储浪费性能的问题。