從壹開始先後端 [vue後臺] 之二 || 完美實現 JWT 滑動受權刷新

時間 2019-11-05

標籤開始後端 vue 後臺之二完美實現 jwt 滑動受權刷新简体版

原文原文鏈接

緣起

哈嘍你們週一好！不知道小夥伴們有沒有學習呀，近來發現各類俱樂部搞起來了，啥時候羣裏小夥伴也搞一次分享會吧，好歹也是半千了（時間真快，還記得5個月前只有20多人），以前在上個公司，雖然也參與組織過幾回活動，這個再說吧，畢竟都是五湖四海的小夥伴，不太好聚😂。今天要說的內容很簡單，可是我的感受很實用，從文章標題就可見一斑：JWT的滑動受權，這個問題我被問了不下 n 次，從 6 個月前開始第一次寫 JWT 受權，就有小夥伴陸陸續續在羣裏提問，說如何然這種無序化的 Token 令牌（不像 Session 那樣，一直存在會話狀態），達到滑動刷新，實現用戶的無感知受權，我也一直在思考，大抵有如下一些思路：前端

一、token 失效後，直接跳轉到登陸頁； // UE體驗感賊差vue

二、將 JWT 、用戶標識 ( 如：id ) 、過時時間等令牌信息存到數據庫，配合用戶進行操做； // 額外的操做太多，鏈接數據庫ios

三、一樣的上邊的這些信息放到 Redis 裏，再配合緩存，也能夠高效處理；// 雖然不操做數據庫，可是變相破壞Token的無序性git

四、返回前端兩個token，經過 refresh_token 來刷新 access_token；// 本文要說明的，和這個相似的策略方法github

五、在後端處理，Id4中，自帶了 RefreshToken，自動能夠從新獲取token；// 這個在下一個系列說到 Id4 的時候，會說到；redis

這些方法和策略我也一直和羣裏小夥伴討論，可是卻一直沒有寫文章，也一直沒有真正的經過代碼寫出來，之前偷懶是由於只有後臺 .net core 項目，後來本身又偷懶說只有博客項目，直觀上很差實現，如今好了，終於在這段時間上線了後臺管理系統，終於把這個問題提上了日程，那下邊就開始今天的說明吧。數據庫

老規矩，仍是先看效果（這篇文章比較簡單，可是有一丟丟的繞，但願看的時候，能夠有十多分鐘的安靜時間，不要着急，本身研究出來的永遠比問出來的要高效的多）：axios

故事背景：後端

當前 Token 將於 18:05:14 失效，之前的狀況是，在失效後，直接跳轉到登陸頁，可是如今不是了，api

在 18:05:19 的時候，執行查詢，咱們從新對 Token 進行無縫刷新，而後自動重發請求併成功加載數據，是否是達到了你想要的目的？

老張說，這只是對JWT使用者簡單處理，若是高併發，或者大數據，更安全驗證，仍是建議使用ID4，若是小公司本身用，目前這個就夠了。若是你有不少顧慮和疑問，請看下邊的評論席，確定會有小夥伴和你有相似的心情，歡迎批評指正，最後：想要更好的受權需求，仍是用Id4，JWT只不過是練手。

那這個究竟是如何實現的呢，複雜不復雜呢？若是是你想要的，請往下看 👍，保證每一個人都能看懂，前提是你有 JWT 基礎，至少用過。

1、個人設計思路是怎樣的

一、傳統的受權流程

傳統的受權登陸呢，很簡單，也很直白，就是咱們平時使用的，由於不像 session 那樣，能夠一直保持着狀態，當咱們的 Token 失效了之後，就只能從新獲取一個新的 Token 令牌，這不只僅是它的優勢也是一個缺點，

優勢就是能夠支持分佈式，多點式的訪問，session 就不能實現分佈式；

缺點固然也是顯而易見，當其過時了，就沒法續簽，或者一直保持激活狀態；

咱們就只能從新獲取一個，因此通常有的開發者就索性把 Token 的過時時間定的很長，好比一天，一週，甚至十天，只有用戶在當前電腦上登陸一次，之後就能夠隨心訪問了，除非本身手動點擊退出登陸，說真的，這種狀況我也在使用，由於咱們公司的項目有一些是內部的前臺項目，好比一個Tool，一個圖表系統，或者一個簡單的我的數據展現，一不怕被外網看到，不會被篡改，二沒有公司其餘人來使用個人電腦，我就定義了一個月的失效時間，平時就徹底不用登陸了，想一想也是能夠的。

可是，更多的是須要用戶去實時登陸的，相信你們也用過一直公網的管理後臺，關閉瀏覽器或者一段時間不操做之後，就會提示須要咱們從新登陸，因此咱們就會把 Token 的失效時間定義的很短暫，好比個人一些項目就是 30 分鐘，或者一個小時，這樣不只更安全，並且也能夠應對那些存在變化的，好比後臺管理系統，當前用戶的角色變了，總不能還用以前的令牌吧，因此短時的 Token 刷新仍是頗有必要的。

這樣就會出現一個問題，如何實現滑動受權，就是在流程上，Token仍是會失效，可是在用戶體驗 UE 上，實現無感操做，讓用戶在沒有察覺的狀況下，實現這個功能，你能夠先停下來，想一想如何設計，若是想好了，請繼續往下看，看是否和你的思路一致。

二、實現滑動的受權流程

這兩個流程圖對比起來，不一樣點就在於虛線的問題，由以前的失效即跳轉到登陸頁，多了一個選擇——在用戶活躍期內，經過舊的 token 換取新的 token 繼續體系內循環，這樣就達到了效果（這裏還有一種，就是同時發放兩個 token 到前端，一個是access_token，一個是 refresh_token，我作了等價處理，其實這兩種是同樣的）。

這樣不只能知足無縫刷新的問題，還能保持 Token 的無序性，那具體的如何在項目中使用呢，請往下繼續看。

2、實現滑動的三步走

從上邊的流程圖中，咱們能夠看出來，其實要實現滑動刷新很簡單，只須要咱們在 Token 失效的時候，從新獲取一個 token，並從新執行一個請求便可，因此我總結了如下三個步驟：

一、定義刷新時間戳

你必定會好奇爲何定義一個刷新時間，不知道你是否還記得上邊我剛剛說到了，其實通常的作法是：每次登陸，向前端丟兩個 token，當咱們的 access_token 失效的時候，就判斷 refresh_token 是否有效，若是 refresh_token 有效，咱們就把這個 refresh_token 帶到資源服務器，換取新的 access_token，這樣就實現了咱們的目的。

可是咱們不想這麼操做，太麻煩，還須要生成兩個，因此就人爲的在前端定義了一個刷新時間點，只要在這個時間點內而且 token 失效了，我就用這個失效的 token 獲取新的token：

在 Login.vue 頁面中定義一個刷新時間：

 var token = data.token;
 _this.$store.commit("saveToken", token);// 保存 token

 var curTime = new Date();
 var expiredate = new Date(curTime.setSeconds(curTime.getSeconds() + data.expires_in)); // 定義過時時間
 _this.$store.commit("saveTokenExpire", expiredate); // 保存過時時間
 window.localStorage.refreshtime = expiredate; // 保存刷新時間，這裏的和過時時間一致

在瀏覽器中查看兩個時間：

二、當執行操做時更新刷新時間（重要）

A：定義方法：

我在 api.js 文件中，定義了保存刷新時間的方法 saveRefreshtime() ，這個的做用主要是記錄當前用戶的操做活躍期，當在這個活躍期內，就能夠滑動更新，若是超過了這個時期，就跳轉到登陸頁：

export const saveRefreshtime = params => {

    let nowtime = new Date();
    let lastRefreshtime = window.localStorage.refreshtime ? new Date(window.localStorage.refreshtime) : new Date(-1);
    let expiretime = new Date(Date.parse(window.localStorage.TokenExpire))

    let refreshCount=1;//滑動係數
    if (lastRefreshtime >= nowtime) {
        lastRefreshtime=nowtime>expiretime ? nowtime:expiretime;
        lastRefreshtime.setMinutes(lastRefreshtime.getMinutes() + refreshCount);
        window.localStorage.refreshtime = lastRefreshtime;
    }else {
        window.localStorage.refreshtime = new Date(-1);
    }
};

上邊的方法中，紅色的是重要的兩點：

一、滑動係數 refreshCount

這個是什麼意思呢，就是你自定義的用戶的中止活躍時間段，好比你想用戶最大的休眠時間是20分鐘，說句人話就是，用戶能夠最多20分鐘內不進行操做，若是20分鐘後，再操做，就跳轉到登陸頁，若是20分鐘內，繼續操做，那繼續更新時間，休眠時間仍是以當前時間+20分鐘。

二、最後刷新時間 lastRefreshtime

這個就是上邊說到的，當用戶操做的時候，實時更新最後的刷新時間，保證用戶活躍時間一直有效，這裏有一個重要的就是：

lastRefreshtime=nowtime>expiretime ? nowtime:expiretime;

我爲何要這麼寫呢，由於你考慮一下，若是 Token 的過時時間比你本身定義的刷新時間還長，舉個栗子，你後臺定義的 token 過時時間是30分鐘，可是你的前端頁面刷新時間是20分鐘，當你登陸後，30分鐘內沒有任何操做，再31分鐘的時候，從新操做，token 確定是無效了，可是很巧，你的刷新時間也是十分鐘前，那就只能去登陸頁了，這樣達不到刷新的目的，因此我通過大量測試，不管是token過時時間，仍是頁面刷新時間，只要取一個較大者就行，而後加上滑動係數，這樣就能知足各類狀況，不信你能夠試試。

B：兩處調用：

那如今既然定義了這個刷新方法，在哪裏調用呢，我這裏想到了兩個地方，固然，你也能夠根據本身的須要進行自定義設計，個人是：

1、在路由鉤子裏刷新； //在 router.js  的 router.beforeEach 調用方法 saveRefreshtime(),保證每次進行路由切換的時候，都激活用戶活躍時間。

2、在 HttpRequest 鉤子刷新；//在 api.js 的 axios.interceptors.request.use 中調用 saveRefreshtime() ，由於有可能用戶長時間操做同一個頁面，沒有進行路由切換。

我這裏就處理了這兩個地方，不管是用戶切換路由，仍是在同一個路由的不一樣按鈕操做，都能保證當前用戶是在操做活躍期的，進而實現滑動的效果。

三、Token無效時，無縫獲取新Token，並從新請求（核心）

如今就到了關鍵時刻了，定義好了刷新時間，那如何進行滑動效果呢？請先看下邊代碼，重點是紅色的部分：

// http response 攔截器
axios.interceptors.response.use(
    response => {
        return response;
    },
    error => {
        if (error.response) {
            if (error.response.status == 401) {
                var curTime = new Date()
                var refreshtime = new Date(Date.parse(window.localStorage.refreshtime))
                // 在用戶操做的活躍期內 if (window.localStorage.refreshtime && (curTime <= refreshtime)) {
                    // 直接將整個請求 return 出去，否則的話，請求會晚於當前請求，沒法達到刷新操做 
                    return  refreshToken({token: window.localStorage.Token}).then((res) => {
                        if (res.success) {
                            Vue.prototype.$message({
                                message: 'refreshToken success! loading data...',
                                type: 'success'
                            });

                            store.commit("saveToken", res.token);

                            var curTime = new Date();
                            var expiredate = new Date(curTime.setSeconds(curTime.getSeconds() + res.expires_in));
                            store.commit("saveTokenExpire", expiredate);

                            error.config.__isRetryRequest = true;
                            error.config.headers.Authorization = 'Bearer ' + res.token;
 // error.config 包含了當前請求的全部信息 return axios(error.config);
                        } else {
                            // 刷新token失敗 清除token信息並跳轉到登陸頁面
                            ToLogin()
                        }
                    });
                } else {
                    // 返回 401，而且不知用戶操做活躍期內 清除token信息並跳轉到登陸頁面
                    ToLogin()
                }

            }
            // 403 無權限 if (error.response.status == 403) {
                Vue.prototype.$message({
                    message: '失敗！該操做無權限',
                    type: 'error'
                });
                return null;
            }
        }
        return ""; // 返回接口返回的錯誤信息
    }
);

其中要注意的是三點：

一、判斷是不是在用戶操做活躍期，若是不在，直接跳轉登陸頁，反之，進行 refresh 操做；

二、return refreshToken ，這裏是兩個return 的第一個，須要將刷新token的網絡請求返回過去，否則的話，刷新token的請求成功後，當前網絡請求已經結束了，沒法達到刷新的目的；

三、return axios(error.config) ，這裏就是從新進行一次請求，特別是 error.config ，這個就是咱們當前請求的所有信息。

效果以下：

好啦，JWT 滑動受權刷新就到這裏已經完成了，是否是很簡單。

3、實現滑動刷新的後端方法

一、Redis，控制 Token 頒發

除了這個前端方法覺得，還有後端處理，設計思路也很簡單，我就很少說了，簡單說兩句：

當用戶登陸的時候，生成 access_token ，咱們把 token 存在 redis 緩存中，對應匹配用戶標識，狀態等，當用戶修改了密碼，或者當前用戶的權限被超級管理修改的時候，把 redis 中的當前用戶的token 也更新操做，等用戶再次使用的時候，先判斷當前用的 token 是否有效，而後再判斷是否有權限，這樣也能達到效果。若是過時了，還能夠把新的token 放到 Header 中返回過去，不過這樣的方法，仍是須要配合前端操做，我的感受還不如上邊的方法。

若是有想嘗試的小夥伴，能夠本身嘗試下，我簡單提示一下，就是在後端項目的 PermissionHandler.cs 文件中，對當前 httpContext.Request.Headers["Authorization"] 進行獲取 token 判斷，至於怎麼操做這裏就不表了。