㈠ 使用SpringSecurity驗證token
我們從AuthenticationManager介面的實現類作為入口啟動認證，那麼就要在SecurityConfig配置類中去寫個@Bean註解，這樣我們才能自動注入。
service層
定義一個UserDetailsService介面的實現類，重寫loadUserByUsername方法（service層的AuthenticationManager類做校驗時會自動調用該方法），那麼它的返回是UserDetails介面的實現類，所以我們再寫個LoginUser作為實現類
好，到這邊准備工作做完了，我們再回過頭看service層。根據userId生成token，然後把用戶信息存入redis，而前端ajax請求的結果里則包含了token值。
接下來定義token驗證過濾器，這樣子的話，如果前端發的請求是需要驗證身份的，那就會走這個過濾器的校驗流程。
最後，附上springsecurity的配置類
㈡ 什麼是token驗證
Token是在客戶端頻繁向服務端請求數據，服務端頻繁的去資料庫查詢用戶名和密碼並進行對比，判斷用戶名和密碼正確與否，並作出相應提示，在這樣的背景下，Token便應運而生。Token是服務端生成的一串字元串，以作客戶端進行請求的一個令牌，當第一次登錄後，伺服器生成一個Token便將此Token返回給客戶端，以後客戶端只需帶上這個Token前來請求數據即可，無需再次帶上用戶名和密碼。
(2)前端許可權驗證token具體方法擴展閱讀：
token其實說的更通俗點可以叫暗號，在一些數據傳輸之前，要先進行暗號的核對，不同的暗號被授權不同的數據操作。例如在USB1.1協議中定義了4類數據包：token包、data包、handshake包和special包。主機和USB設備之間連續數據的交換可以分為三個階段，第一個階段由主機發送token包，不同的token包內容不一樣（暗號不一樣）可以告訴設備做不同的工作，第二個階段發送data包，第三個階段由設備返回一個handshake包。
㈢ 鑒權操作流程（前端邏輯）
1.用戶登錄 調取介面 去獲取對應的token，此時將token 存儲在了sessionStorage中。項目的最開始是去獲取當前用戶的token。（base64加密），之後調用token有效時間和校驗token是否失效。
2.公共請求方法 request 函數在請求頭添加 token，即每次的相關請求都帶有了當前用戶的token信息，如果token在有效期內則可以正常請求。否則便會拋出異常。
3.假如token的有效時間是3600s，但是用戶很久沒有操作系統，會啟動用戶鎖定狀態，通過監控用戶的操作時間差來判斷鎖定的狀態。正常情況下token是不會過期的，因為在token的過期前幾分鍾內會進行token的更新操作，理論上token是不會過期的。所以當用戶重新操作系統的時候，超過了一定時間之後需要用戶重新登錄系統來，其實也是調取的token的介面，去獲取新的token，並替換之前的token。（但是這里沒有考慮到的一種情況是如果項目一直在啟動，但是服務重啟了，或者其他原因導致前端的token在驗證的時候不通過，這樣就會導致頁面的鎖定狀態無法打開，這時候前端做的處理是重新跳轉到登錄頁，並刪除token，就像第一次登錄系統一樣。）
㈣ 服務端如何校驗token的是否正確
服務端第一次返回登錄請求token的時候,服務端是校驗了用戶,並綁定了用戶關系,之後才返回了這個token,也就說,服務端保存了token和登錄用戶賬戶的對應關系,不管之後的token怎麼變,都是伺服器校驗上一次的token,並返回新的token,token和用戶賬戶的對應關系一直在服務端更新並維護,對於客戶端來講,無需判斷token是誰,伺服器下發什麼,就返回什麼,檢驗是服務端處理
㈤ Vue前端用戶許可權控制大全
用戶許可權是對特定資源的訪問許可，所謂許可權控制，也就是確保用戶只能訪問到被分配的資源
介面許可權目前一般採用通用的形式來驗證(用戶是否登錄系統)，沒有的話一般返回401，跳轉到登錄頁面重新進行登錄 ,
登錄成功後拿到token，將token存起來，通過axios請求攔截器進行攔截，每次請求的時候頭部攜帶token
通過自定義指令進行按鈕許可權的判斷
自定義許可權指令
在使用的按鈕中只需要引用v-has指令
全局路由守衛里做判斷
每次路由跳轉的時候都要判斷許可權，這里的判斷也很簡單，因為菜單的name與路由的name是一一對應的，而後端返回的菜單就已經是經過許可權過濾的
如果根據路由name找不到對應的菜單，就表示用戶有沒許可權訪問
如果路由很多，可以在應用初始化的時候，只掛載不需要許可權控制的路由。取得後端返回的菜單後，根據菜單與路由的對應關系，篩選出可訪問的路由，通過addRoutes動態掛載
這種方式的缺點：
菜單需要與路由做一一對應，前端添加了新功能，需要通過菜單管理功能添加新的菜單，如果菜單配置的不對會導致應用不能正常使用
全局路由守衛里，每次路由跳轉都要做判斷
㈥ token什麼意思 前端如何使用token
大家好，從網上找了很多關於token的文章，都是提到要生成一個token，然後前端每次請求的時候，要使用這個token，請問下如何在前端使用生成的token？
前端能就使用jQuery搞定，還是需要其他的前端框架配合？能有這方面的完整示例嗎？
做後端的，對前端的東西有些不太懂，請見諒
先謝謝大家了！！
解決方案1:
一般是後端有個結構給你拿token的，然後你請求的時候，根據約定
把token
放在header中
放uri參數中
放body表單里
給後端
解決方案2:
因為http協議是無狀態的 token是後台給你發的一個唯一標識 你再去訪問後台時帶上這個token 後台就知道你是誰了
同session的作用
解決方案3:
前台生成的token，可能會存在安全性問題吧
解決方案4:
你做後台應該很了解token才對呀。
用戶登錄後，生成一個session_id，即token，可以存在redis里。然後前端或客戶端保存起來，存cookie或者LS都行，然後所有的請求作為基類參數帶上（也有通過cookie帶的），然後server端再取到後，驗證你是不是你。
解決方案5:
使用領域很多，以表單為例子：
後台生成token.
前端列印表單,並且講該token變成隱藏項。<input type="hide" value="{{token}}">
客戶提交表單。
後台驗證提交的token合法性。
驗證成功，處理表單。驗證失敗，返回錯誤處理頁面。
解決方案6:
token一般都是後端生成的，在登陸之後返回，前端保存token，之後每次請求都帶上token來驗證身份。
解決方案7:
問題是前端生成的token給後台有用嗎
解決方案8:
一般token都是伺服器端生成，做csrf的。我在補充下我見過前端生成的栗子，雖然沒啥卵用，但讓我廢了好大的勁才發現。
譬如你有一個驗證碼的表單，你在傳遞驗證碼的時候，新增一個隱藏域，將驗證碼用你本地的js加密後，作為參數傳遞，這樣在伺服器端可以檢測驗證碼是不是被篡改過。
但這樣沒啥卵用，因為在提交的時候用同樣的js模擬即可。
解決方案9:
大多數情況下，token作為一種令牌，都是在伺服器端生成，生成的方法很多，從簡單點的對時間或者id或者兩個混合起來進行哈希運算的值到自己設計更復雜的演算法都可以，生成的目的是為了給前端下一次通信時使用這個token作為令牌，當作為一個請求資源的許可的標識，而伺服器則會視這個token在一段時間內都是有效的，並且還可以額外看情況加上是否是同一個ip之類的其它的限制，從而防止某種資源被非法訪問
偶有前端（包括本地客戶端或者app）生成token的情況是已經約定好了一個好的加密機制，伺服器可以信任客戶端的這個輸入的情況下可以由前端或者客戶端生成
㈦ 前後端分離項目——登錄Token校驗思路
對token的校驗分為前端和後端
前端： Vue-Cli 2.x + axios
後端：SpringBoot 2.3.4
這里的話，userToken和userId放到sessionStorage是關鍵步驟
後端主要是使用攔截器來進行請求的攔截和校驗
解釋一下思路：
這里的話，針對需要攔截的路徑和需要放行的路徑進行配置就行
關於redisTemple的引入這里就不再贅述。
到這里為止，前後端的token就都做完了，後面就再講講前端的一些其他思路吧
對於登錄狀態的判斷，前端可以在router.foreach上對路由進行狀態判定，從而實現頁面程度的攔截（具體可以參考最後的參考文章2）
在使用攔截器後，會發現前端部分請求會無法正常到達後端，網路後發現是因為 axios發送正式請求前會先發送一個嗅探請求 ，而嗅探請求是不攜帶我們封裝的header的，所以會導致部分請求會無法成功，解決的方式有很多種，這里的話是選擇了在後端去直接處理
參考文章
1、SpringBoot加了攔截器後出現的跨域問題解析
https://blog.csdn.net/mrkorbin/article/details/104066979
2、Vue項目中實現用戶登錄及token驗證
https://www.cnblogs.com/web-record/p/9876916.html
㈧ JWT生成token及過期處理方案
## 業務場景
在前後分離場景下，越來越多的項目使用token作為介面的安全機制，APP端或者WEB端（使用VUE、REACTJS等構建）使用token與後端介面交互，以達到安全的目的。本文結合stackoverflow以及本身項目實踐，試圖總結出一個通用的，可落地的方案。
## 基本思路
- 單個token
1. token（A）過期設置為15分鍾
2. 前端發起請求，後端驗證token（A）是否過期；如果過期，前端發起刷新token請求，後端設置已再次授權標記為true，請求成功
3. 前端發起請求，後端驗證再次授權標記，如果已經再次授權，則拒絕刷新token的請求，請求成功
4. 如果前端每隔72小時，必須重新登錄，後端檢查用戶最後一次登錄日期，如超過72小時，則拒絕刷新token的請求，請求失敗
- 授權token加上刷新token
用戶僅登錄一次，用戶改變密碼，則廢除token，重新登錄
## 1.0實現
1.登錄成功，返回access\_token和refresh\_token，客戶端緩存此兩種token;
2.使用access_token請求介面資源，成功則調用成功；如果token超時，客戶端
攜帶refresh\_token調用中間件介面獲取新的access\_token;
3.中間件接受刷新token的請求後，檢查refresh_token是否過期。
如過期，拒絕刷新，客戶端收到該狀態後，跳轉到登錄頁；
如未過期，生成新的access\_token和refresh\_token並返回給客戶端（如有可能，讓舊的refresh\_token失效），客戶端攜帶新的access\_token重新調用上面的資源介面。
4.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(使access\_token和refresh\_token失效)，同時清空客戶端的access\_token和refresh\_toke。
後端表
id user\_id client\_id client\_secret refresh\_token expire\_in create\_date del_flag
## 2.0實現
場景： access\_token訪問資源 refresh\_token授權訪問 設置固定時間X必須重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期30分鍾）和refresh\_token（jwt有效期15天），並緩存到redis（hash-key為token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全部token，也可以根據sub-key,廢除部分設備的token。），設置過期時間為1個月，保證最終所有token都能刪除)，返回後，客戶端緩存此兩種token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果token超時，中間件刪除access\_token（廢除）；客戶端再次攜帶refresh\_token調用中間件介面獲取新的access_token;
3.中間件接受刷新token的請求後，檢查refresh_token是否過期。
如過期，拒絕刷新，刪除refresh_token（廢除）； 客戶端收到該狀態後，跳轉到登錄頁；
如未過期，檢查緩存中是否有refresh\_token（是否被廢除），如果有，則生成新的access\_token並返回給客戶端，客戶端接著攜帶新的access_token重新調用上面的資源介面。
4.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token和refresh\_token（廢除）)，同時清空客戶端側的access\_token和refresh\_toke。
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
6.以上3刷新access_token可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：失效，長時間未登錄，頻繁刷新）
2.0 變動
1.登錄
2.登錄攔截器
3.增加刷新access_token介面
4.退出登錄
5.修改密碼
## 3.0實現
場景：自動續期 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期30分鍾），並緩存到redis（hash-key為access\_token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全部token），設置access_token過期時間為7天，保證最終所有token都能刪除)，返回後，客戶端緩存此token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token（廢除）)，同時清空客戶端側的access\_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
3.0 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
1.3 場景：token過期重新登錄 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期7天），並緩存到redis，key為 "user\_id:access\_token",value為access\_token（根據用戶id，可以人工廢除指定用戶全部token），設置緩存過期時間為7天，保證最終所有token都能刪除，請求返回後，客戶端緩存此access_token；
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token（廢除）)，同時清空客戶端側的access\_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
1.3 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
# 解決方案
2.0 場景： access\_token訪問資源 refresh\_token授權訪問 設置固定時間X必須重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期30分鍾）和refresh\_token（jwt有效期15天），並緩
存到redis（hash-key為token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全
部token，也可以根據sub-key,廢除部分設備的token。），設置過期時間為1個月，保證最終所有token都
能刪除)，返回後，客戶端緩存此兩種token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果
token超時，中間件刪除access\_token（廢除）；客戶端再次攜帶refresh\_token調用中間件介面獲取新的
access_token;
3.中間件接受刷新token的請求後，檢查refresh_token是否過期。
如過期，拒絕刷新，刪除refresh_token（廢除）； 客戶端收到該狀態後，跳轉到登錄頁；
如未過期，檢查緩存中是否有refresh\_token（是否被廢除），如果有，則生成新的access\_token並返回給
客戶端，客戶端接著攜帶新的access_token重新調用上面的資源介面。
4.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token和refresh\_token（
廢除）)，同時清空客戶端側的access\_token和refresh\_toke。
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
6.以上3刷新access_token可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（
拒絕的場景：失效，長時間未登錄，頻繁刷新）
2.0 變動
1.登錄
2.登錄攔截器
3.增加刷新access_token介面
4.退出登錄
5.修改密碼
3.0 場景：自動續期 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access_token（jwt有效期30分鍾），並緩存到redis（hash-key為
access_token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全部token，也可以
根據sub-key,廢除部分設備的token。），設置access_token過期時間為1個月，保證最終所有token都能刪
除)，返回後，客戶端緩存此token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果
token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的
access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access_token（廢除）)，同時清
空客戶端側的access_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長
時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
3.0 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
4.0 場景：token過期重新登錄 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access_token（jwt有效期7天），並緩存到redis，key為
"user\_id:access\_token" + 用戶id,value為access_token（根據用戶id，可以人工廢除指定用戶全部
token），設置緩存過期時間為7天，保證最終所有token都能刪除，請求返回後，客戶端緩存此
access_token；
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果
token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的
access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access_token（廢除）)，同時清
空客戶端側的access_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長
時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
4.0 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
## 最終實現
### 後端
1. 在登錄介面中 如果校驗賬號密碼成功 則根據用戶id和用戶類型創建jwt token(有效期設置為-1，即永不過期),得到A
2. 更新登錄日期(當前時間new Date()即可)（業務上可選），得到B
3. 在redis中緩存key為ACCESS_TOKEN:userId:A(加上A是為了防止用戶多個客戶端登錄 造成token覆蓋),value為B的毫秒數（轉換成字元串類型），過期時間為7天（7 * 24 * 60 * 60）
4. 在登錄結果中返回json格式為{"result":"success","token": A}
5. 用戶在介面請求header中攜帶token進行登錄，後端在所有介面前置攔截器進行攔截，作用是解析token 拿到userId和用戶類型（用戶調用業務介面只需要傳token即可），
如果解析失敗（拋出SignatureException），則返回json（code = 0 ,info= Token驗證不通過, errorCode = '1001'）；
此外如果解析成功，驗證redis中key為ACCESS_TOKEN:userId:A 是否存在 如果不存在 則返回json（code = 0 ,info= 會話過期請重新登錄, errorCode = '1002'）；
如果緩存key存在，則自動續7天超時時間（value不變），實現頻繁登錄用戶免登陸。
6. 把userId和用戶類型放入request參數中 介面方法中可以直接拿到登錄用戶信息
7. 如果是修改密碼或退出登錄 則廢除access_tokens（刪除key）
### 前端（VUE）
1. 用戶登錄成功，則把username存入cookie中，key為loginUser;把token存入cookie中，key為accessToken
把token存入Vuex全局狀態中
2. 進入首頁
㈨ Vue項目中用戶登錄及token驗證及流程圖
在前後端完全分離的情況下，Vue項目中實現token驗證大致思路如下：
簡單舉例說明：
① 調登錄介面成功，在回調函數中將token存儲到localStorage和vuex中（login.vue中）
② store文件夾下的index.js
③ 路由守衛（router文件夾下的index.js）
④ 請求頭加token
⑤ 如果前端拿到狀態碼為401，就清除token信息並跳轉到登錄頁面
流程圖：