cookie、session、token

时间:2024-05-05 21:38:18

cookie

纳入标准文档,标准浏览器需要遵守的协议之一,作为标准浏览器必须支持的。

WEB应用都是基于HTTP协议,标准的HTTP协议是无状态的。

什么是无状态?

不管是谁,不管是从哪个地方发起的请求。只要你的请求(URL:包括了域名甚至包括了具体的文件【当然也有缺省的情况 ,即默认访问】)是一样的,你拿到的结果【响应】永远是一样的。

这样就导致了一些需求无法完成,比如:

我想让第一次访问该页面的用户,给他重定向到welcome页面接着是它想访问的页面,而之后继续访问该页面【第二次及以后】,则不会去访问welcome页面。

这种根据用户访问次数来做的需求就无法实现。

因此我们提出了cookie的概念。

由于HTTP本身是无状态的,那么我就把状态本身附加到响应头head中

同时这个cookie是符合HTTP标准协议里面的,即任何一个标准的浏览器都应该支持这个功能。当我们服务器在响应的时候,只要我们设置一个响应的字段“set-cookie”。

浏览器在收到响应之后,如果它发现响应头里面有“set-cookie”字段,那么浏览器就会把对应的key-value保存在浏览器里面,并且以后浏览器向同一个域名发起请求的时候,浏览器是会携带这个cookie【放在请求头中】

虽然HTTP本身是无状态的,但服务器把需要的状态以cookie的形式返回给浏览器,让浏览器来帮忙。服务器后续想更新这个cookie也是同样在响应头进行更新及扩充。

cookie的不足

我们会发现这些cookie都是明文暴露在外面的,泄漏了很多后台管理的状态,使得它有一定的安全问题,甚至一些企业中的安全策略(内网)会把cookie给禁掉。

2、引入了session

session

通过后台来保存这些状态,保存完之后为了区分不同的session,起名为session上下文(每个上下文有一个对应的sessionID),然后我们只把sessionID通过cookie返回回去。这样浏览器拿到的也就只有sessionID,很大程度避免了信息的泄漏。

session的不足

当一个服务是多地部署的,这样当两次请求发给的是不同的服务器,如:第一次发给了北京的服务器,而第二次发给了上海的服务器,在第二次的时候只拿到了sessionID,而没有session上下文,于是就需要回到北京的服务器去查。造成了性能的开销。

token

后端把需要保存的内容不保存在服务器里【当然也可以在服务器中拷贝一份】,后端将(session)上下文的状态打包成token,同时把token做加密,我只认token不认人。交给【返回给】前端,前端在发后续请求的时候把token和请求发给后端,后端收到请求之后把

token解包  -->

可以看到token里面的内容【前端一般不会主动去打开token】。对于分布式服务器,服务相同的一个session请求的时候,如果连续两次请求的是不同地段的服务器,我也不需要去查之前的服务器了,因为上下文的状态全保存在token中。

当设置token的时候,可以通过secret进行加密,也可以设置过期时间。

当后端进行校验工作确认信息没问题的时候,根据业务把相关信息进行打包,将token返回给前端,当前端拿到token的时候也只是拿到了一个令牌【前端是解不开的,因为我们正常是不会把secret传给前端】,在下次发请求的时候,会把token放入请求头里【的authorization】,发给后端。

token不是标准协议的内容,完全是前后端之间自己去定义、协商的。通常都是把token放入请求头里,和请求一起发过来,在拿到token之后去验证它:

验证secret对不对(签名),是否过期。当不满足上述条件,则直接返回401