山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制

目录

  • 结合请求拦截和响应拦截实现双token机制
  • 实现双token机制流程
  • 结合请求拦截和响应拦截实现双token机制代码
  • 可优化部分——解决并发请求问题
    • 并发请求
    • 存在的问题
    • 解决思路
    • 探索精神(自夸一波。。)

结合请求拦截和响应拦截实现双token机制

笔者从一开始写博客就说明了本项目将使用双token机制,大大满足用户体验以及用户账号信息的安全性能。
但是笔者在之前的测试中,与负责后端的同学交流过,先用单token机制进行测试 —— 因为双token机制实现起来就是对请求拦截和响应拦截进行丰富。 笔者在之前也曾说过,拦截什么的实现逻辑完全可以放在项目接近尾声的时候进行实现。故话不多说,且看下文。

实现双token机制流程

  • 修改原登录设置单token的逻辑 —— 在登录成功后,将双token存储下来。
    山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第1张图片
  • 回顾之前的请求拦截器和响应拦截器。 从下图的博客可以看到:
    (1)笔者之前的请求拦截器就是直接在发送的所有请求的请求头上加上token字段。显然这是不对的,因为登录请求的请求头是不需要该字段的。
    此外因为要实现双token机制,由于向服务器发起获取新的双token是需要将refreshToken作为请求头发送出去的。
    (2)笔者之前的响应拦截器几乎没做什么拦截,只要状态码是200的则放行,而其他状态码则给用户提示出了什么错误。
    而为了实现双token机制,则需要拦截accessToken过期的状态码,然后用refreshToken当作请求头向服务器发起获取新的双token的请求,这里有两种情况:1. 成功获取新的双token,则需要向服务器重新发起用户之前发起的所有请求;2. refreshToken也过期了导致无法获取新的双token,则给用户提示账号权限失效,需要重新登录,然后跳转到登录页面。
    山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第2张图片
  • 根据上述的所说,先解决请求拦截器存在的问题。当然这问题也很容易解决。且看下图。
    山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第3张图片
  • 实现响应拦截器。
  1. 第一个要解决的问题:如何发起获取新的双token请求?
  2. 第二个要解决的问题:如何存储用户原发起的请求?因为如果获取新的双token成功,则需要用到用户原新的请求。
  3. 第三个要解决的问题:获取失败后的逻辑具体实现。
  • 对于第一个问题,笔者在前文有提到,发起获取新token请求前,会对该请求进行拦截,修改请求头配置。然后就可以发起请求了。
    山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第4张图片
  • 对于第二个问题,也挺好实现的,直接将原config参数传递给响应拦截器,即存储下来了。
    山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第5张图片
  • 对于第三个问题,因为双token都过期了,那首先需要移除用户中原来的双token,然后再给用户提示,最后跳转到登录页面。
    山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第6张图片

结合请求拦截和响应拦截实现双token机制代码

请求拦截
山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第7张图片响应拦截
山东大学项目实训(二十五)—— 结合请求拦截和响应拦截实现双token机制_第8张图片
其余状态码响应拦截根据项目需求进行拦截。基本不用做什么特殊处理,直接提示用户即可。

可优化部分——解决并发请求问题

首先需要了解什么是并发请求。

并发请求

虽说是并发请求,但从微观上看,程序代码是有先后性的,网络请求也是存在先后顺序的,所以这并不是严格意义上的并发请求;而从宏观上看,由于程序发起这些请求的时间过于短暂,使得网络请求让人看起来像是并发请求一样,故而称为并发请求。

存在的问题

结合上述代码实现逻辑,那就存在一个问题:倘若存在并发请求,而这些并发请求携带的 accessToken 恰好又过期了,那便会向服务器发起多次获取新的双 token 请求,可能导致性能方面有所损耗。

解决思路

当然笔者对这可优化部分也有相应的实现思路:1、设置源请求缓冲区和锁;2、加锁;3、重新发起源队列中的请求;4、释放锁

1、设置源请求缓冲区和锁设置一个全局队列,由于并发请求实际上是有顺序的,即按用户源请求顺序将请求存入队列中。设置全局锁,用于控制是否可以发起获取新的双 token 请求。

2、加锁:由于并发请求携带的 accessToken 是过期的,则会有多个响应在返回的时候会被响应拦截器拦截下来。当第一个响应被拦截下来的时候,则对获取新的双 token 请求进行加锁——防止后续响应被拦截进来的时候继续执行该请求。

3、重新发起源请求缓冲区中的请求:发起条件则是成功获取新的双 token 后 (可使用 async 和 await 实现) ,按队列顺序依次发起用户原请求。

4、释放锁:释放锁的条件就是成功发起所有源请求后 (可使用 async 和 await 实现) ,释放锁。当然释放锁的同时,将源请求缓冲区置为空。

探索精神(自夸一波。。)

至于笔者为什么没有去实现这样的优化呢?

答:
(1)由于笔者代码的实现逻辑上,会产生并发请求的可能性较低;
(2)实现上述优化则需要申请全局队列以及全局锁,同时无论发起的是什么请求,都需要将请求存入队列中,然后大部分情况下都是需要将该队列内容进行清空的,实际上并没有这个必要,诚然这也算是另一方面的性能损耗;

综合上述考虑,目前实现逻辑的情况是:发起多次获取新token的请求可能性较低,并且在性能方面的损耗是可以接收的,笔者便觉得不是很有必要再深入优化了。但这并不能阻止笔者去探索这其中存在的问题不是吗?—— 倘若以后遇到类似的问题,那也算是有经验了啊。

你可能感兴趣的