JavaScript sessionStorage使

JavaScript sessionStorage使用

essionStorage只能保存在單一的瀏覽器窗口或分頁(tab), 關閉瀏覽器后存儲的數據就消失了, 其最大的用途在于保存一些臨時的數據, 防止用戶重新整理

網頁時不小心丟失這些數據。sessionStorage的操作方法與localStorage相同;

1 存儲

window.sessionStorage.setItem("userdata","Hello HTML5");
window.sessionStorage["userdata"]="Hello HTML5";
window.sessionStorage.userdata="Hello HTML5";

2 讀取

var value1=window.sessionStorage.getItem("userdata");
var value1=window.sessionStorage["userdata"];
var value1=window.sessionStorage.userdata;

3 清除

window.sessionStorage.removeItem("userdata");
delete window.sessionStorage.userdata;
delete window.sessionStorage["userdata"];

//全部清除

sessionStorage.clear();

session聲明周期包括刷新網頁的頁面

文分享自華為云社區《Cookie、Session、Token 背后的故事-云社區-華為云》，作者：龍哥手記。

1. 網站交互體驗升級

作為網友的我們，每天都會使用瀏覽器來逛各種網站，來滿足日常的工作生活需求。

現在的交互體驗還是很絲滑的，但早期并非如此，而是一錘子買賣。

1.1 無狀態的 HTTP 協議

無狀態的 HTTP 協議是什么鬼？

HTTP 無狀態協議，是指協議對于業務處理沒有記憶能力，之前做了啥完全記不住。每次請求都是完全獨立互不影響的，沒有任何上下文信息。

缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳關鍵信息，這樣可能導致每次連接傳送的數據量增大。

如果大家沒明白，可以想一下《夏洛特煩惱》里面的橋段：

大概明白了吧，假如一直用這種原生無狀態的 HTTP 協議，我們每換一個頁面可能就得重新登錄一次，那還玩個球。

所以必須要解決 HTTP 協議的無狀態，提升網站的交互體驗，否則星辰大海是去不了的。

1.2 解決之道

整個事情交互的雙方只有客戶端和服務端，所以必然要在這兩個當事者身上下手。

客戶端來買單

客戶端每次請求時把自己必要的信息封裝發送給服務端，服務端查收處理一下就行。

服務端來買單

客戶端第一次請求之后，服務端就開始做記錄，然后客戶端在后續請求中只需要將最基本最少的信息發過來就行，不需要太多信息了。

2. Cookie方案

Cookie 總是保存在客戶端中。按在客戶端中的存儲位置，可分為內存 Cookie 和硬盤Cookie。

內存 Cookie 由瀏覽器維護，保存在內存中，瀏覽器關閉后就消失了，其存在時間是短暫的。硬盤 Cookie 保存在硬盤里，有一個過期時間。除非用戶手工清理或到了過期時間，硬盤Cookie不會被刪除，其存在時間是長期的。

2.1 Cookie 定義和作用

HTTP Cookie（也叫 Web Cookie 或瀏覽器 Cookie）是服務器發送到用戶瀏覽器并保存在本地的一小塊數據。它會在瀏覽器下次向同一服務器再發起請求時，被攜帶并發送到服務器上。

通常 Cookie 用于告知服務端兩個請求是否來自同一瀏覽器，如保持用戶的登錄狀態。Cookie 使基于無狀態的HTTP協議記錄穩定的狀態信息成為了可能。

Cookie 主要用于以下三個方面：

會話狀態管理（如用戶登錄狀態、購物車等其它需要記錄的信息）
個性化設置（如用戶自定義設置、主題等）
瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

2.2 服務端創建 Cookie

當服務器收到 HTTP 請求時，服務器可以在響應頭里面添加一個 Set-Cookie 選項。

瀏覽器收到響應后通常會保存下 Cookie，之后對該服務器每一次請求中都通過 Cookie 請求頭部將 Cookie 信息發送給服務器。另外，Cookie 的過期時間、域、路徑、有效期、適用站點都可以根據需要來指定。

2.3 B/S 的 Cookie 交互

服務器使用 Set-Cookie 響應頭部向用戶瀏覽器發送 Cookie信息。

一個簡單的 Cookie 可能像這樣：

Set-Cookie: <cookie名>=<cookie值>
HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry

客戶端對該服務器發起的每一次新請求，瀏覽器都會將之前保存的Cookie信息通過 Cookie 請求頭部再發送給服務器。

GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry

我來訪問下淘寶網，抓個包看看這個真實的過程：

2.4 存在的問題

Cookie 常用來標記用戶或授權會話，被瀏覽器發出之后可能被劫持，被用于非法行為，可能導致授權用戶的會話受到攻擊，因此存在安全問題。

還有一種情況就是跨站請求偽造 CSRF，簡單來說比如你在登錄銀行網站的同時，登錄了一個釣魚網站，在釣魚網站進行某些操作時可能會獲取銀行網站相關的Cookie信息，向銀行網站發起轉賬等非法行為。

跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通?？s寫為 CSRF 或者 XSRF，是一種挾制用戶在當前已登錄的 Web 應用程序上執行非本意的操作的攻擊方法。跟跨網站腳本（XSS）相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。

跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并運行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。

由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶操作而去運行。這利用了 Web 中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的。

不過這種情況有很多解決方法，特別對于銀行這類金融性質的站點，用戶的任何敏感操作都需要確認，并且敏感信息的 Cookie 只能擁有較短的生命周期。

同時 Cookie 有容量和數量的限制，每次都要發送很多信息帶來額外的流量消耗、復雜的行為 Cookie 無法滿足要求。

特別注意：以上存在的問題只是 Cookie 被用于實現交互狀態時存在的問題，但并不是說 Cookie 本身的問題。

試想一下：菜刀可以用來做菜，也可以被用來從事某些暴力行為，你能說菜刀應該被廢除嗎？

3. Session 方案

3.1 Session 機制的概念

如果說 Cookie 是客戶端行為，那么 Session 就是服務端行為。

Cookie 機制在最初和服務端完成交互后，保持狀態所需的信息都將存儲在客戶端，后續直接讀取發送給服務端進行交互。

Session 代表服務器與瀏覽器的一次會話過程，并且完全由服務端掌控，實現分配ID、會話信息存儲、會話檢索等功能。

Session 機制將用戶的所有活動信息、上下文信息、登錄信息等都存儲在服務端，只是生成一個唯一標識 ID 發送給客戶端，后續的交互將沒有重復的用戶信息傳輸，取而代之的是唯一標識 ID，暫且稱之為 Session-ID 吧。

3.2 簡單的交互流程

當客戶端第一次請求 session 對象時候，服務器會為客戶端創建一個 session，并將通過特殊算法算出一個 session 的 ID，用來標識該 session 對象；
當瀏覽器下次請求別的資源的時候，瀏覽器會將 sessionID 放置到請求頭中，服務器接收到請求后解析得到 sessionID，服務器找到該 id 的 session 來確定請求方的身份和一些上下文信息。

3.3 Session 的實現方式

首先明確一點，Session 和 Cookie 沒有直接的關系?？梢哉J為 Cookie 只是實現 Session 機制的一種方法途徑而已，沒有 Cookie 還可以用別的方法。

Session和Cookie的關系就像加班和加班費的關系，看似關系很密切，實際上沒啥關系。

Session 的實現主要兩種方式：Cookie 與 URL 重寫，而 Cookie 是首選方式。因為各種現代瀏覽器都默認開通 Cookie 功能，但是每種瀏覽器也都有允許 Cookie 失效的設置，因此對于 Session 機制來說還需要一個備胎。

將會話標識號以參數形式附加在超鏈接的URL地址后面的技術稱為 URL 重寫

原始 URL：

http://taobao.com/getitem?name=baymax&action=buy

重寫后的 URL:

http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy

3.4 存在的問題

由于 Session 信息是存儲在服務端的，因此如果用戶量很大的場景，Session 信息占用的空間就不容忽視。

對于大型網站必然是集群化&分布式的服務器配置。如果 Session 信息是存儲在本地的，那么由于負載均衡的作用，原來請求機器 A 并且存儲了 Session 信息，下一次請求可能到了機器 B，此時機器 B 上并沒有 Session 信息。

這種情況下要么在 B 機器重復創建造成浪費，要么引入高可用的 Session 集群方案，引入 Session 代理實現信息共享，要么實現定制化哈希到集群 A，這樣做其實就有些復雜了

4. Token 方案

Token 是令牌的意思，由服務端生成并發放給客戶端，是一種具有時效性的驗證身份的手段。

Token 避免了 Session 機制帶來的海量信息存儲問題，也避免了 Cookie 機制的一些安全性問題，在現代移動互聯網場景、跨域訪問等場景有廣泛的用途。

4.1 簡單的交互流程

客戶端將用戶的賬號和密碼提交給服務器；
服務器對其進行校驗，通過則生成一個 token 值返回給客戶端，作為后續的請求交互身份令牌；
客戶端拿到服務端返回的 token 值后，可將其保存在本地，以后每次請求服務器時都攜帶該 token，提交給服務器進行身份校驗；
服務器接收到請求后，解析關鍵信息，再根據相同的加密算法、密鑰、用戶參數生成 sign 與客戶端的 sign 進行對比，一致則通過，否則拒絕服務；
驗證通過之后，服務端就可以根據該 Token 中的 uid 獲取對應的用戶信息，進行業務請求的響應。

4.2 Token 的設計思想

以 JSON Web Token（JWT）為例，Token主要由三部分組成：

Header 頭部信息：記錄了使用的加密算法信息；
Payload 凈荷信息：記錄了用戶信息和過期時間等；
Signature 簽名信息：根據 header 中的加密算法和 payload 中的用戶信息以及密鑰key來生成，是服務端驗證服務端的重要依據。

header 和 payload 的信息不做加密，只做一般的 base64 編碼。服務端收到 token 后剝離出 header 和 payload 獲取算法、用戶、過期時間等信息，然后根據自己的加密密鑰來生成 sign，并與客戶端傳來的 sign 進行一致性對比，來確定客戶端的身份合法性。

這樣就實現了用 CPU 加解密的時間換取存儲空間，同時服務端密鑰的重要性就顯而易見，一旦泄露整個機制就崩塌了，這個時候就需要考慮 HTTPS 了。

4.3 Token 方案的特點

Token 可以跨站共享，實現單點登錄；
Token 機制無需太多存儲空間。Token 包含了用戶的信息，只需在客戶端存儲狀態信息即可，對于服務端的擴展性很好；
Token 機制的安全性依賴于服務端加密算法和密鑰的安全性；
Token 機制也不是萬金油。

5. 總結

Cookie、Session、Token 這三者是不同發展階段的產物，并且各有優缺點，三者也沒有明顯的對立關系，反而常常結伴出現，這也是容易被混淆的原因。

Cookie 側重于信息的存儲，主要是客戶端行為。Session 和 Token 側重于身份驗證，主要是服務端行為。

三者方案在很多場景都還有生命力，了解場景才能選擇合適的方案。

點擊下方，第一時間了解華為云新鮮技術~

華為云博客_大數據博客_AI博客_云計算博客_開發者中心-華為云

言

認證和授權，其實吧簡單來說就是:認證就是讓服務器知道你是誰，授權就是服務器讓你知道你什么能干，什么不能干，認證授權倆種方式：Session-Cookie與JWT，下面我們就針對這兩種方案就行闡述。

一、Session

1.1 工作原理

當 client通過用戶名密碼請求server并通過身份認證后，server就會生成身份認證相關的 session 數據，并且保存在內存或者內存數據庫。并將對應的 sesssion_id返回給client，client會把保存session_id（可以加密簽名下防止篡改）在cookie。此后client的所有請求都會附帶該session_id（畢竟默認會把cookie傳給server），以確定server是否存在對應的session數據以及檢驗登錄狀態以及擁有什么權限，如果通過校驗就該干嘛干嘛，否則重新登錄。

前端退出的話就清cookie。后端強制前端重新認證的話就清或者修改session。

1.2 優勢

相比JWT，最大的優勢就在于可以主動清除session了

session保存在服務器端，相對較為安全

結合cookie使用，較為靈活，兼容性較好

1.3 弊端

cookie + session在跨域場景表現并不好

如果是分布式部署，需要做多機共享session機制，實現方法可將session存儲到數據庫中或者redis中

基于 cookie 的機制很容易被 CSRF

查詢session信息可能會有數據庫查詢操作

1.4 session、cookie、sessionStorage、localstorage的區別

session: 主要存放在服務器端，相對安全

cookie: 可設置有效時間，默認是關閉瀏覽器后失效，主要存放在客戶端，并且不是很安全，可存儲大小約為4kb

sessionStorage: 僅在當前會話下有效，關閉頁面或瀏覽器后被清除

localstorage: 除非被清除，否則永久保存

二、JWT

JSON Web Token（JWT）是一種開放標準（RFC 7519），它定義了一種緊湊且獨立的方式，可以將各方之間的信息作為JSON對象進行安全傳輸。該信息可以驗證和信任，因為是經過數字簽名的。

JWT基本上由.分隔的三部分組成，分別是頭部，有效載荷和簽名。一個簡單的JWT的例子，如下所示：

 eyJhbGciOiJIUzI1NiIsInR5cCI6Ik

如果你細致得去看的話會發現其實這是一個分為 3 段的字符串，段與段之間用 “.”【點號】隔開，在 JWT 的概念中，每一段的名稱分別為：

Header.Payload.Signature

在字符串中每一段都是被 base64url 編碼后的 JSON，其中 Payload 段可能被加密。

2.1 Header

JWT 的 Header 通常包含兩個字段，分別是：typ(type) 和 alg(algorithm)。

typ：token的類型，這里固定為 JWT
alg：使用的 hash 算法，例如：HMAC SHA256 或者 RSA

一個簡單的例子：

    {
      "alg": "HS256",
      "typ": "JWT"
    }

我們對他進行編碼后是：

    >>> base64.b64encode(json.dumps({"alg":"HS256","typ":"JWT"}))
    'eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9'

2.2 Payload

JWT 中的 Payload 其實就是真實存儲我們需要傳遞的信息的部分，例如正常我們會存儲些用戶 ID、用戶名之類的。此外，還包含一些例如發布人、過期日期等的元數據。

但是，這部分和 Header 部分不一樣的地方在于這個地方可以加密，而不是簡單得直接進行 BASE64 編碼。但是這里我為了解釋方便就直接使用 BASE64 編碼，需要注意的是，這里的 BASE64 編碼稍微有點不一樣，切確得說應該是 Base64UrlEncoder，和 Base64 編碼的區別在于會忽略最后的 padding（=號），然后 '-' 會被替換成'_'。

舉個例子，例如我們的 Payload 是：

 {"user_id":"zhangsan"}

那么直接 Base64 的話應該是：

    >>> base64.urlsafe_b64encode('{"user_id":"zhangsan"}')
    'eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ=='

然后去掉=號，最后應該是：

'eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ'

2.3 Signature

Signature 部分其實就是對我們前面的 Header 和 Payload 部分進行簽名，保證 Token 在傳輸的過程中沒有被篡改或者損壞，簽名的算法也很簡單，但是，為了加密，所以除了 Header 和 Payload 之外，還多了一個密鑰字段，完整算法為：

    Signature=HMACSHA256(
        base64UrlEncode(header) + "." +
        base64UrlEncode(payload),
        secret)

還是以前面的例子為例，

    base64UrlEncode(header)=》 eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9
    base64UrlEncode(payload)=》 eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ

secret 就設為："secret", 那最后出來的簽名應該是：

    >>> import hmac
    >>> import hashlib
    >>> import base64
    >>> dig=hmac.new('secret',     >>> msg="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ", 
               digestmod=>>> base64.b64encode(dig.digest())
    'ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs='

將上面三個部分組裝起來就組成了我們的 JWT token了，所以我們的

    {'user_id': 'zhangsan'}

的 token 就是：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiemhhbmdzYW4ifQ.ec7IVPU-ePtbdkb85IRnK4t4nUVvF2bBf8fGhJmEwSs

三、工作原理

1.首先，前端通過Web表單將自己的用戶名和密碼發送到后端的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協議），從而避免敏感信息被嗅探。

2.后端核對用戶名和密碼成功后，將用戶的id等其他信息作為JWT Payload（負載），將其與頭部分別進行Base64編碼拼接后簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字符串。

3.后端將JWT字符串作為登錄成功的返回結果返回給前端。前端可以將返回的結果保存在localStorage或sessionStorage上，退出登錄時前端刪除保存的JWT即可。

4.前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)

5.后端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。

6.驗證通過后后端使用JWT中包含的用戶信息進行其他邏輯操作，返回相應結果。

五、JWTs vs. Sessions

5.1 可擴展性

隨著應用程序的擴大和用戶數量的增加，你必將開始水平或垂直擴展。

session數據通過文件或數據庫存儲在服務器的內存中。在水平擴展方案中，你必須開始復制服務器數據，你必須創建一個獨立的中央session存儲系統，以便所有應用程序服務器都可以訪問。否則，由于session存儲的缺陷，你將無法擴展應用程序。

解決這個挑戰的另一種方法是使用 sticky session。

你還可以將session存儲在磁盤上，使你的應用程序在云環境中輕松擴展。這類解決方法在現代大型應用中并沒有真正發揮作用。

建立和維護這種分布式系統涉及到深層次的技術知識，并隨之產生更高的財務成本。在這種情況下，使用JWT是無縫的;由于基于token的身份驗證是無狀態的，所以不需要在session中存儲用戶信息。

我們的應用程序可以輕松擴展，因為我們可以使用token從不同的服務器訪問資源，而不用擔心用戶是否真的登錄到某臺服務器上。你也可以節省成本，因為你不需要專門的服務器來存儲session。為什么？因為沒有session！

注意：如果你正在構建一個小型應用程序，這個程序完全不需要在多臺服務器上擴展，并且不需要RESTful API的，那么session機制是很棒的。如果你使用專用服務器運行像Redis那樣的工具來存儲session，那么session也可能會為你完美地運作！

5.2 安全性

JWT簽名旨在防止在客戶端被篡改，但也可以對其進行加密，以確保token攜帶的claim 非常安全。JWT主要是直接存儲在web存儲（本地/session存儲）或cookies中。 JavaScript可以訪問同一個域上的Web存儲。這意味著你的JWT可能容易受到XSS（跨站腳本）攻擊。惡意JavaScript嵌入在頁面上，以讀取和破壞Web存儲的內容。事實上，很多人主張，由于XSS攻擊，一些非常敏感的數據不應該存放在Web存儲中。一個非常典型的例子是確保你的JWT不將過于敏感/可信的數據進行編碼，例如用戶的社會安全號碼。

最初，我提到JWT可以存儲在cookie中。事實上，JWT在許多情況下被存儲為cookie，并且cookies很容易受到CSRF（跨站請求偽造）攻擊。預防CSRF攻擊的許多方法之一是確保你的cookie只能由你的域訪問。作為開發人員，不管是否使用JWT，確保必要的CSRF保護措施到位以避免這些攻擊。

現在，JWT和session ID也會暴露于未經防范的重放攻擊。建立適合系統的重放防范技術，完全取決于開發者。解決這個問題的一個方法是確保JWT具有短期過期時間。雖然這種技術并不能完全解決問題。然而，解決這個挑戰的其他替代方案是將JWT發布到特定的IP地址并使用瀏覽器指紋。

注意：使用HTTPS / SSL確保你的Cookie和JWT在客戶端和服務器傳輸期間默認加密。這有助于避免中間人攻擊！

5.3 RESTful API服務

現代應用程序的常見模式是從RESTful API查詢使用JSON數據。目前大多數應用程序都有RESTful API供其他開發人員或應用程序使用。由API提供的數據具有幾個明顯的優點，其中之一就是這些數據可以被多個應用程序使用。在這種情況下，傳統的使用session和Cookie的方法在用戶認證方面效果不佳，因為它們將狀態引入到應用程序中。

RESTful API的原則之一是它應該是無狀態的，這意味著當發出請求時，總會返回帶有參數的響應，不會產生附加影響。用戶的認證狀態引入這種附加影響，這破壞了這一原則。保持API無狀態，不產生附加影響，意味著維護和調試變得更加容易。

另一個挑戰是，由一個服務器提供API，而實際應用程序從另一個服務器調用它的模式是很常見的。為了實現這一點，我們需要啟用跨域資源共享（CORS）。Cookie只能用于其發起的域，相對于應用程序，對不同域的API來說，幫助不大。在這種情況下使用JWT進行身份驗證可以確保RESTful API是無狀態的，你也不用擔心API或應用程序由誰提供服務。

5.4 性能

對此的批判性分析是非常必要的。當從客戶端向服務器發出請求時，如果大量數據在JWT內進行編碼，則每個HTTP請求都會產生大量的開銷。然而，在會話中，只有少量的開銷，因為SESSION ID實際上非常小?？聪旅孢@個例子：

JWT有5個claim：

{

  "sub": "1234567890",

  "name": "Prosper Otemuyiwa",

  "admin": true,

  "role": "manager",

  "company": "Auth0"

}

編碼時，JWT的大小將是SESSION ID（標識符）的幾倍，從而在每個HTTP請求中，JWT比SESSION ID增加更多的開銷。而對于session，每個請求在服務器上需要查找和反序列化session。

JWT通過將數據保留在客戶端的方式以空間換時間。你應用程序的數據模型是一個重要的影響因素，因為通過防止對服務器數據庫不間斷的調用和查詢來減少延遲。需要注意的是不要在JWT中存儲太多的claim，以避免發生巨大的，過度膨脹的請求。

值得一提的是，token可能需要訪問后端的數據庫。特別是刷新token的情況。他們可能需要訪問授權服務器上的數據庫以進行黑名單處理。獲取有關刷新token和何時使用它們的更多信息。

5.5 下游服務

現代web應用程序的另一種常見模式是，它們通常依賴于下游服務。例如，在原始請求被解析之前，對主應用服務器的調用可能會向下游服務器發出請求。這里的問題是，cookie不能很方便地流到下游服務器，也不能告訴這些服務器關于用戶的身份驗證狀態。由于每個服務器都有自己的cookie方案，所以阻力很大，并且連接它們也是困難的。JSON Web Token再次輕而易舉地做到了！

5.6 實效性

此外，無狀態JWT的實效性相比session太差，只有等到過期才可銷毀，而session則可手動銷毀。

例如有個這種場景，如果JWT中存儲有權限相關信息，比如當前角色為 admin，但是由于JWT所有者濫用自身權利，高級管理員將權利濫用者的角色降為 user。但是由于 JWT 無法實時刷新，必需要等到 JWT 過期，強制重新登錄時，高級管理員的設置才能生效。

或者是用戶發現賬號被異地登錄，然后修改密碼，此時token還未過期，異地的賬號一樣可以進行操作包括修改密碼。

但這種場景也不是沒有辦法解決，解決辦法就是將JWT生成的token存入到redis或者數據庫中，當用戶登出或作出其他想要讓token失效的舉動，可通過刪除token在數據庫或者redis里面的對應關系來解決這個問題。

六、node中使用JWT

我這個項目中使用的是JWT，使用方法如下：

首先安裝JWT庫：

npm install jsonwebtoken

然后創建簽名數據，生成token：

復制代碼let jwt=require('jsonwebtoken');

var token=jwt.sign({ name: '張三' }, 'shhhhh');
console.log(token);

運行程序可以看到打印出來的內容類似這樣：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoi5byg5LiJIiwiaWF0IjoxNDYyODgxNDM3fQ.uVWC2h0_r1F4FZ3qDLkGN5KoFYbyZrFpRJMONZrJJog

之后，對token字符串，可以這樣解碼：

let decoded=jwt.decode(token);
console.log(decoded);

將打印出：

{ name: '張三', iat: 1462881437 }

其中iat是時間戳，即簽名時的時間（注意：單位是秒）。

不過，一般我們不會使用decode方法，因為它只是簡單的對claims部分的做base64解碼。

我們需要的是驗證claims的內容是否被篡改。

此時我們需要使用verify方法：

let decoded=jwt.verify(token, 'shhhhh');
console.log(decoded);

雖然打印出的內容和decode方法是一樣的。但是是經過校驗的。

我們可以改變校驗用的密鑰，比如改為shzzzz，使之和加密時的密鑰不一致。那么解碼就會出現報錯：

JsonWebTokenError: invalid signature

我們也可以偷偷修改token的claims或者header部分，會得到這樣的報錯：

JsonWebTokenError: invalid token

最后，根據自己的需求，決定是否需要將生成的token存入數據庫或者redis，但建議不要存儲用戶密碼等敏感信息。

在線咨詢

上一篇：前端 - JavaScript 完全自學手冊
下一篇：Htmx走紅，從React“退回去”后：代碼減少 6

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商