token保活设计.md

本文探讨了两种Token保活策略:使用RefreshToken获取新AccessToken和服务端保活机制。在RefreshToken方案中,登录返回两个Token,当AccessToken过期,通过RefreshToken获取新AccessToken。服务端保活机制则在每次请求时自动延长Token有效期,适用于Web端。设计中,通过Filter拦截请求,验证并异步更新Token的有效时长,避免频繁操作Redis。
摘要由CSDN通过智能技术生成

如果我们要使用token机制用以标识用户登录状态,以获得请求相关资源接口的权限。让你来设计一套方案,以为怎么设计呢?
通常有两种思路:

1.使用refreshtoken获取新的accesstoken

登录成功之后,返回一个返回refreshtoken和accesstoken。accesstoken作为请求其他接口的权限参数,它有时间期限。过期之后就无法使用。可以使用refresh_token来获取新的accesstoken。
refresh_token也有时间期限,只不过比较长,一般可设置为1天或3天。这种设计方案需要客户端有“token保活机制”,比如accesstoken失效请求失败,则获取新的accesstoken重新请求,对时效性要求可能不是那么高。这种机制一般常见于移动端。
典型的参数
{
“access_token”: “343bec2737979ca0ace85a80c243b1ec”,
“expires_in”: 2592000,
“refresh_token”: “de81cfe747ad7e06f2a904e73646f04c”
}

2.服务端token保活

登录成功之后,只返回accesstoken。accesstoken作为请求其他接口的权限参数,它也有时间期限。不同的是,我们将“token保活机制”做在服务端。在token有效内,如果使用了此token,那么更新token的有效时长,效果相当于重新登录之后的有效时长。web端就非常适合这样的机制。

1.token保活机制设计

token保活机制需要满足下面2个条件

1.登录成功之后,返回一个token。前端所有请求都带上token做鉴权验证。
2.假如token的有效时长是3小时,我们期望的效果是:每用此token请求成功一次,都将token的有效时长自动延长至3小时。

最简单的处理方法是,每成功请求一次,都对token进行put到Redis的操作,重新设置有效时长。简单粗暴。但是我们知道,Redis是一个适合“少写多读”场景的缓存数据库,这样做显然不合适。
而且对于第2条要求,显然没有次次都更新的必要,我们想要的是,在token失效之前的一小段时间,如果有带次token的请求成功,这时我们再进行一次put到Redis的操作。而且我们希望这样的更新操作,不会阻塞请求向前执行。

设计方案:

1.使用过滤器Filter拦截除登录外的所有请求,验证token是否有效,有效才放行

2.我们将token作为key,用户信息还有token上次的请求时间戳作为value,存在Redis中,并设置有效时间。存redis的原因是,1是便于多个服务获取当前用户,2是简单高效。

3.当Fil

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值