工作总结之双token篇
复盘双token方案在项目中的实际应用
前言
笔者需要实现token的无感刷新,具体点说就是假设用户一直在使用,就会无感给用户的token进行刷新,不需要到点强制让用户重新登录,只有用户长时间不使用的情况下,过了设定时间后才强制用户登录
方案
现在有两个可选的方案:
- token+redis
将token的过期时间放在redis中进行维护 - 双token
将token分为长短两个token:access_token和refresh_token。access_token的过期时间短,比如2小时,平时调用接口的时候只需要带上这个token做验证就行了;refresh_token的过期时间长,比如7天,当access_token过期时,如果refresh_token没有过期,那么就带上它去访问token的刷新接口,返回新的长短token,达到无感刷新的效果,如果refresh_token过期了,提示用户重新登录(长token跟session的作用差不多)
两个方案的优劣:
前者的优势在于实现起来只需要后端改一下就好了,前端几乎不需要做改动,这种方案容易理解,做起来也比较简单,这是传统的做法;劣势在于对redis的依赖,如果redis挂了,系统就登录不了了,有条件配置redis集群的当我没说
后者的优势:1)去除了对redis的依赖 2)短token可以防止被截获后无休止使用,长token又可以保证活跃用户不用一直登录 3)安全性更高,长token只有在第一次获取和刷新短token时才会在网络中传输,暴露的风险小很多;劣势:对前端的改动比较大,前端改动需要处理一些额外的并发问题比较麻烦
方案2前端如何改造的参考文章:
https://blog.csdn.net/u010952787/article/details/121655780
https://blog.csdn.net/m0_48468380/article/details/121577011
https://blog.csdn.net/long99920/article/details/124638211
https://juejin.cn/post/7035280102636126244
实现的结果
后端由笔者完美实现,前端则是由公司的同事去实现,然后,今天做复盘的时候,去翻了一下前端的代码,发现在刷新token的时候,前端并没有做二次请求(参考上面的文章,短token过期的请求应该被缓存起来,然后做二次请求),也没有处理并发问题(同一时间大量请求的短token过期,应该设置一把锁,只有一个请求去刷新长短token,剩下的同样缓存起来,后续挨着重新请求),只是简单的加一把锁去刷新长短token,本次请求和后续请求全部丢掉,不重新请求,仅此而已,就是下面的效果:
不翻不知道,一翻吓一跳,额滴神呀,加油,咱复盘到这了,已经很棒啦。