A. 遭遇黑客，程序員，前端人員獲取個人信息泄密問題你看該怎麼解決
這是一個安全問題，大致需要解決的是前端可能導致的許可權被拉取(cookie跨域訪問等)，傳輸過程中的信息抓包(中間人攻擊等)，以及後端資料庫被拖庫(伺服器被黑)
首先前端不要用cookie進行許可權的管理，使用token的方式，有條件設計單獨的token伺服器。非分布式的可以使用session。
其次數據的交互應該走https或一定的加密規則，保證數據傳輸過程的安全性。
前端開發者發送數據的時候，重要的數據一定得post不能使用get，還可以進行一定的數據加密和校驗規則。
最後後端接收並保存到資料庫，重要數據和隱私數據是必然需要加密存儲的，這里涉及到許可權問題，加密的隱私數據與規則應該盡量保證只有用戶才能查看，保證拖庫後也無法直接獲取用戶信息。加密規則加鹽規則保密。
B. ID Token - JWT
我們來繼續前兩章（ OAuth2 總結 , 對OpenID Connect的理解 ）的討論，進入對JWT的理解。先來簡單回顧一下OAuth2和OpenID：
OpenID建立在OAuth之上，完成了認證和授權。而認證和授權的結果就體現在這個ID token之上，而這個ID token通常會是JWT。那麼為什麼會是JWT呢？我們通過以下幾點來逐一解釋。
JWT RFC 7519 給出了官方定義的一些欄位：
當然也不限於此，可以根據自己的需要，添加其他欄位。到此，我們可以看出JWT提供了ID token所需要的能力。一個完整的JTW是由三部分組成：Header，Payload，Signature。三者之間由 . 隔開，剛才提到的認證授權的欄位就存在於Payload中。
Header中存放的是JTW的元數據，包含簽名的演算法以及token的類型，如下所示：
Signature部分是對前兩部分的簽名， 防止數據篡改 。首先，需要指定一個密鑰（secret）。這個密鑰只有伺服器才知道，不能泄露給用戶。然後，使用 Header 裡面指定的簽名演算法（默認是 HMAC SHA256），按照下面的公式產生簽名。
算出簽名以後，把 Header、Payload、Signature三個部分經過base64序列化為三個字元串，再講三個字元串由 . 為間隔拼接成一個字元串返回給客戶端。
ID Token需要有足夠的安全性，JWT是如何做到的呢？
剛看到了簽名部分，簽名的作用只是為了防止數據篡改，而JWT默認是不加密，但也是可以加密的。生成原始 Token 以後，可以用密鑰再加密一次。比如認證伺服器中使用私鑰進行加密，把公鑰分發給其他應用伺服器，應用服務拿到加密後的token後用公鑰解密，獲取到JWT，再用簽名的秘鑰來驗證數據是否經過的篡改。
我們來看看還有神馬其他備選么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。
JWT vs SAML：JWT基於json，而SAML基於XML，在大小上就有足夠的優勢，更適用於HTML和HTTP。
JWT vs SWT：在安全性上，SWT只支持對稱加密，而JWT和SAML支持公私鑰的加密方式。
作為一個mobile developer，也想在這里對比一下原先的簡單token模式和SSO中的JWT：
在沒有該機制前，我們通常會使用一個隨機產生的字元串作為token，認證成功後返回給前端，之後前端的每個請求帶上這個token。若後台服務的是個單體應用沒有什麼問題，請求來了，驗證一下token是否有效即可，但當認證服務和其他的應用服務是分離的，怎麼做呢？應用服務受到請求，再向認證服務發起一個請求來驗證驗證token是否合法，是否有許可權訪問該應用服務。這樣做到沒有什麼問題，只是當服務變多時，比如微服務下，勢必會造成認證伺服器的壓力過大。
在使用該機制後，客戶端通過認證服務登錄，獲得這個JWT，之後其他應用服務自身便可以驗證這個token的是否有效，是否有權訪問。
看似完美，但也有它自身的問題，我們來看一個場景：許可權變更。某用戶原先是一個超級管理員，可以訪問所有服務，並可進行任意的刪除，更改操作，他在這個狀態下拿到了JWT。隨後，由於許可權更改為普通管理員，便不應該具有所有許可權，但此時他開始時的JWT被緩存在客戶端仍然可用，其他應用服務也並無法知道這個用戶的許可權已經被更改，後果可想而知了。解決的方式無非是將這個token的有效時間設置的短一些。
C. Token 原理解讀
上一篇文章我們了解了一下 cookie 與 session 的產生、作用與原理。盡管二者在歷史中已經服役過很長一段時間，但不論什麼技術，都會有後來的優秀者取而代之。
前面說到，cookie 因為是保存在客戶端，所以有安全隱患，因而誕生了 session，session 保存在伺服器端，相對安全很多。但 session 每次都要為用戶開辟一個空間用於其身份校驗，且每次瀏覽器的請求過來伺服器都要進行校驗請求，十分耗費伺服器的空間與性能。
於是，另一種身份校驗工具誕生了，這就是 token。
本質上還是用戶身份驗證的工具。但與 cookie、session 明文似的形式不同，token 是經過一系列加密手段加密過的，最後表現為一串「無意義」的字元串。但裡麵包含了許多信息，可能包括用戶登錄的終端的地址、用戶身份 ID、時間戳以及一個簽名。所謂簽名就是信息發送者給這段信息進行簽名，讓信息接收方知道請求 token 是屬於誰。可以理解為在你的身份證上簽名字，證件加筆跡雙重認證。
為了避免上述 CSRF 攻擊，瀏覽器對網頁資源的訪問提出了限制，URL 請求必須是與頁面一樣來自同一 協議 、 域名 、 埠 才給予訪問許可權。這樣三者相同的站點被認為是有相同的「源」，是一個獨立的「域」。即使 「localhost」 與 「ip」 都指向了本機，但也會被認為是非同源。瀏覽器在某個「域」下不會執行其他「域」的腳本。因而這也產生了前端領域里一個重要的話題：跨域。
session 的產生來自於用戶登錄後伺服器生成的一個 session 對象，保存在伺服器端，這個 session 只適用於該「域」。但實際情況是，一個網站的請求大多數情況下都會跨域，每台伺服器的埠不同，甚至是域名就不同，每當跨域時就會形成新的會話，生成新的 session，這是非常影響用戶體驗的，所以也會有許多保存、共享或中央存儲 session 的方案。
但上述兩種限制在 token 這里就不再是問題。
與 cookie 類似。
首先，用戶輸入賬號密碼，發起登錄請求，伺服器校驗賬號密碼合法性，成功則返回 token 給客戶端。
客戶端收到響應後拿到 token，將其通過 localStorage 等本地存儲方式進行保存。
當瀏覽器再次請求時，需要在請求頭中添加 token，這樣伺服器在接收到請求後便可以識別該請求的身份是否合法，合法則返回響應數據。
在實際應用中，配合 axios 的請求攔截器使用起來會很方便：
這樣，就不用每次請求都手動添加 token，axios 會自動幫助我們完成添加，十分方便。
其實前端程序員對 token 的涉及沒有多深，只需要在需要授權的請求中攜帶 token 即可。token 的生成、加密等都是後端去處理。所以，這里也就不在贅述 token 的加密原理，以筆者的能力也很難去講述清楚。
token 運用也不是上文中描述的那麼簡單，涉及到一些過期處理、refresh 等操作。這些日後有機會再詳談。
D. 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. 進入首頁
E. 前後端交互數據加解密
本文提供了一種前後端交互數據的加解密方法，主要涉及了AES和RSA兩種加密方式。
AES加密是一種對稱式加密，即加密和解密所需秘鑰是相同的。後端生成一組秘鑰，並利用該秘鑰加密數據，然後發給前端，同時也需要把秘鑰發送給前端，這樣前端才能解密。這樣就會有風險，一旦秘鑰被泄露，你的加密將不存在任何意義。同時，相比RSA加密來說，好處是不會限制加密字元串的長度。
RSA加密，是一種非對稱式加密，相比AES加密，這個就安全多了。後端生成一對秘鑰，自己拿著私鑰，公鑰可以公開。這樣前端拿公鑰進行加密，後端拿私鑰進行解密，私鑰掌握在自己手裡，被泄露的風險就小了很多。當然也有不好的地方，就是被加密字元串的長度不能過長，1024的秘鑰只能加密117位元組以內的明文，這就比較尷尬了，可能稍微長一點的數據就會超出了，當然可以通過2048或者4096的秘鑰來延長加密長度，但總會被超出。所以適合需要加密長度不長的數據，最好是已知長度的數據，這樣 就不會因長度問題報錯。
RSA+AES混合加密，即後端通過RSA演算法生成一對公私鑰，並把公鑰提供給前端。前端通過AES演算法生成密鑰，利用公鑰進行加密並送給後端，後端根據私鑰進行解密，得到與前端相同的AES密鑰。然後，前後端就可以利用AES密鑰對稱加密進行數據交互。
詳細步驟如圖所示。
RSA+AES混合加密，結合了兩種加密方式的優點。另外，前端每次啟動都會隨機生成AES密鑰，後端增加token失效機制（前端設置了定時任務請求token），增加了前後端數據交互的安全性。
https://www.cnblogs.com/huanzi-qch/p/10913636.html
https://blog.csdn.net/weixin_38342534/article/details/94582656
F. 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的情況是已經約定好了一個好的加密機制，伺服器可以信任客戶端的這個輸入的情況下可以由前端或者客戶端生成
G. jwt的token怎麼生存的
引入依賴包加密解密方法。
在生產環境中，一般jwt會保存用戶的名字和角色許可權等信息。可以將token寫到cookie里，每次前端訪問後台時，可以在攔截器或者過濾器取到token，然後解密，先判斷是否過期，過期就拋異常阻止其訪問。然後取出信息保存到threadLocal里，方便以後調用這些信息，當後台訪問完成後，從thredLocal刪除此用戶信息。
伺服器認證以後，生成一個JSON格式的對象返回給客戶端。之後客戶端與服務端通信的時候，都要發回這個JSON對象。伺服器完全根據這個對象認證用戶身份。
H. 登錄時對於token的處理
在前後端完全分離的情況下，Vue項目中實現token驗證大致思路如下：
1、用戶輸入賬號密碼，前端調後端的登陸介面，發送用戶名和密碼，
2、後端收到請求，驗證用戶名和密碼，驗證通過後（即登錄成功），後端返回token給前端；
3、前端拿到token，將token存儲到localStorage和vuex中，並跳轉路由頁面；
4、前端每次跳轉路由，都要判斷 localStroage 中有無 token ，沒有就跳轉到登錄頁面，有則跳轉到對應路由頁面（ 通過router.beforeEach((to, from, next)=>{.....}）)
5、每次調後端介面，都要在請求頭中加上token；
6、後端判斷請求頭中有無token，有token，就拿到token並驗證token，驗證成功就返回數據，驗證失敗（例如：token過期）就返回編碼401（編碼由前台和後台約定好），請求頭中沒有token也返回編碼401；
7、如果前端拿到狀態碼為401，則清除token信息並跳轉到登錄頁面，並彈框提示用戶當前缺少token或者token已失效，請重新登錄；
一、調登錄介面成功，在回調函數中將token存儲到localStorage和vuex中
login.vue
store文件夾下的index.js
二、路由導航守衛
main.js
三、請求頭加token，如果前端拿到狀態碼為401，就清除token信息並跳轉到登錄頁面
I. vue項目實現用戶登錄 以及攜帶token
<article class="_2rhmJa">
調取登錄介面 （首先明確一下要做到事情）
在前後端完全分離的情況下，Vue項目中實現token驗證大致思路如下：
1、第一次登錄的時候，前端調後端的登陸介面，發送用戶名和密碼
2、後端收到請求，驗證用戶名和密碼，驗證成功，就給前端返回一個token
3、前端拿到token，將token存儲到localStorage和vuex中，並跳轉路由頁面
4、前端每次跳轉路由，就判斷 localStroage 中有無 token ，沒有就跳轉到登錄頁面，有則跳轉到對應路由頁面
5、每次調後端介面，都要在請求頭中加token
6、後端判斷請求頭中有無token，有token，就拿到token並驗證token，驗證成功就返回數據，驗證失敗（例如：token過期）就返回401，請求頭中沒有token也返回401
7、如果前端拿到狀態碼為401，就清除token信息並跳轉到登錄頁面
調取登錄介面成功，會在回調函數中將token存儲到localStorage和vuex中
1.<template>
<div>
</div>
</template>
export default {
data () {
},
methods: {
/////判讀賬號密碼是否輸入，沒有則alert 出來
}
};
在store文件夾下的index.js 添加 token
import Vue from 'vue';
import Vuex from 'vuex';
Vue.use(Vuex);
const store = new Vuex.Store({
state: {
},
mutations: {
}
});
export default store;
二，配置 路由導航守衛
router文件夾下的index.js
import Vue from 'vue';
import Router from 'vue-router';
import login from '@/components/login';
import home from '@/components/home';
Vue.use(Router);
const router = new Router({
routes: [
]
});
// 導航守衛
// 使用 router.beforeEach 注冊一個全局前置守衛，判斷用戶是否登陸
router.beforeEach((to, from, next) => {
if (to.path === '/login') {
} else {
}
});
export default router;
三、請求頭加token 在 main.js中添加
// 添加請求攔截器，在請求頭中加token
axios.interceptors.request.use(
config => {
},
error => {
});
token的過期可以自定義
四、如果前端拿到狀態碼為401，就清除token信息並跳轉到登錄頁面
localStorage.removeItem('Authorization');
this.$router.push('/login');
</article>
66人點贊
前段學習
J. token 加密解密
.
.
(三種不同的信息)
第一部分：紅色 令牌Header--頭部包含所使用的簽名演算法和令牌的類型
{ "alg": "HS256", "typ": "JWT"} 經過Base64Url 編碼以後，結果大致如：
第二部分：綠色 載荷payload--數據實體
{
data: { username: 'abc', password: '111111' },
exp: 1591933872,
iat: 1591930272
}
註：atob：ASCII-to-Binary 解密-返回一個正常字元串；
btoa：Binary-to-ASCII 加密-返回一個 Base64 表示的字元串
第三部分：藍色 簽名Signature--是對前兩部分的防篡改簽名。將Header和Payload用Base64URL編碼後，再用點(.)連接起來。然後使用簽名演算法和密鑰對這個字元串進行簽名。
signature = hmac_sha256(base64encode(header) + '.' + base64encode(payload), 'MY_SUPER_SECRET_KEY')
註：這個密鑰（MY_SUPER_SECRET_KEY）只有伺服器才知道，不能泄露給用戶。