image
前言
記錄一下前后端分離下————token超時刷新策略!
需求場景
昨天發(fā)了一篇記錄 前后端分離應用——用戶信息傳遞 中介紹了token
認證機制,跟幾位群友討論了下,有些同學有這么一個疑惑:token
失效了,應該怎么做?強制定向到登錄頁?
其實理論上如果是活躍用戶,token
失效后,假如用戶正在操作表單,此時突然定向到登錄頁面,那用戶體驗太差了。
實現(xiàn)目標
- 延長
token
過期時間 - 活躍用戶在
token
過期時,在用戶無感知的情況下動態(tài)刷新token
,做到一直在線狀態(tài) - 不活躍用戶在
token
過期時,直接定向到登錄頁
登錄返回字段
如何簽發(fā)token
,請看上一篇推文,這里不做過多介紹。先看看登錄接口返回的數(shù)據(jù)如下:
@Data
public class LoginVo implements Serializable {
private static final long serialVersionUID = 6711396581310450023L;
//...省略部分業(yè)務字段
/**
* token令牌 過期時間默認15day
*/
private String jwt;
/**
* 刷新token 過期時間可以設置為jwt的兩倍,甚至更長,用于動態(tài)刷新token
*/
private String refreshJwt;
/**
* token過期時間戳
*/
private Long tokenPeriodTime;
}
具體返回字段的意義請看注釋,這里再簡要說明:
- jwt:用戶正常訪問接口時提交的
token
,過期時間設置長一些,15day吧 - refreshJwt:刷新
token
過期時間可以設置為jwt
的兩倍,甚至更長,用于動態(tài)刷新token
時候提交后臺驗證 - tokenPeriodTime:
token
過期時間戳,前端每次調(diào)用接口前需要主動判斷是否已經(jīng)過期,如果過期則提交refreshJwt
訪問token
刷新的接口進行刷新
動態(tài)刷新token
前端檢測到token
過期后,攜帶refreshJwt
訪問后臺刷新token
的接口,服務端在攔截器中依然對refreshJwt
進行解析鑒權
- 假如
refreshJwt
也過期了,提示登錄過期,強制跳轉(zhuǎn)登錄頁 - 假如
refreshJwt
還在有效期,則簽發(fā)新的token
返回,前端使用最新的token
進行接口請求
總結
- 如果是活躍用戶,那么允許他在
refreshJwt
過期時間與token
過期時間的差值這段時間內(nèi),不停的動態(tài)刷新token
,使其做到無感知的狀態(tài)下一直保持登錄狀態(tài) - 如果用戶不活躍,在
refreshJwt
過期時間到了,依然沒有使用系統(tǒng),那么將判定為不活躍用戶,此時應當重定向到登錄頁了
最后
篇幅較短,主要是延續(xù)上一篇 前后端分離應用——用戶信息傳遞 遺留問題做一下總結。如果你有更好的做法,歡迎留言告知我,謝謝啦。后續(xù)會不定期更新原創(chuàng)文章,歡迎關注公眾號 「張少林同學」!
image