如果我们要使用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