當時做登錄這塊的時候，被session、cookie、token各種概念差點整蒙圈了，上網查詢相關概念，發現很多人都是類似的疑惑，比如：

來了字節跳動之后，前端很少接觸HTTP請求之后的事情，而且登錄相關的SDK封裝的很好，所以這篇文章就簡單的學習記錄一下。

為什么會有登錄這回事

首先這是因為HTTP是無狀態的協議，所謂無狀態就是在兩次請求之間服務器并不會保存任何的數據，相當于你和一個人說一句話之后他就把你忘掉了。所以，登錄就是用某種方法讓服務器在多次請求之間能夠識別出你，而不是每次發請求都得帶上用戶名密碼這樣的識別身份的信息。 從登錄成功到登出的這個過程，服務器一直維護了一個可以識別出用戶信息的數據結構，廣義上來說，這個過程就叫做session，也就是保持了一個會話。

常見的兩種登錄

忽然想到一點，看了網上很多問題，我覺得大家應該區分兩個概念：廣義的session和狹義的session

廣義的session：廣義的session就是從登錄成功到登出的過程，在這個過程中客戶端和服務器端維持了保持登錄的狀態，至于具體怎么維持住這種登錄的狀態，沒有要求。

狹義的session：狹義的session就是登錄成功后，服務器端存儲了一些必須的用戶信息，這部分存在服務器端的用戶信息就叫做session，也就是接下來要說的第一種登錄的實現方式。

服務器session+客戶端sessionId

先用圖來看：

詳細說的說一下，這里面主要是這么幾個過程：

1. 客戶端帶著用戶名和密碼去訪問 /login 接口，服務器端收到后校驗用戶名和密碼，校驗正確就會在服務器端存儲一個sessionId和session的映射關系

2.服務器端返回response，并且將sessionId以set-cookie的方式種在客戶端，這樣一來，sessionId就存在了客戶端。這里要注意的是，將sessionId存在cookie并不是一種強制的方案，而是大家一般都這么做，而且發請求的時候符合domain和path的時候，會自動帶上cookie，省去了手動塞的過程。

3.客戶端發起非登錄請求時，服務端通過cookie中的sessionId找到對應的session來知道此次請求是誰發出的。

token

前面說到sessionId的方式本質是把用戶狀態信息維護在server端，token的方式就是把用戶的狀態信息加密成一串token傳給前端，然后每次發請求時把token帶上，傳回給服務器端；服務器端收到請求之后，解析token并且驗證相關信息；

所以跟第一種登錄方式最本質的區別是：通過解析token的計算時間換取了session的存儲空間

業界通用的加密方式是jwt（json web token），jwt的具體格式如圖：

簡單的介紹一下jwt，它主要由3部分組成：

header 頭部
{
 "alg": "HS256",
 "typ": "JWT"
}
payload 負載
{
 "sub": "1234567890",
 "name": "John Doe",
 "iat": 1516239022,
 "exp": 1555341649998
}
signature 簽名復制代碼

header里面描述加密算法和token的類型，類型一般都是JWT；

payload里面放的是用戶的信息，也就是第一種登錄方式中需要維護在服務器端session中的信息；

signature是對前兩部分的簽名，也可以理解為加密；實現需要一個密鑰（secret），這個secret只有服務器才知道，然后使用header里面的算法按照如下方法來加密：

HMACSHA256(
 base64UrlEncode(header) + "." +
 base64UrlEncode(payload),
 secret)復制代碼

總之，最后的 jwt = base64url(header) + "." + base64url(payload) + "." + signature

jwt可以放在response中返回，也可以放在cookie中返回，這都是具體的返回方式，并不重要。

客戶端發起請求時，官方推薦放在HTTP header中：

Authorization: Bearer 復制代碼

這樣子確實也可以解決cookie跨域的問題，不過具體放在哪兒還是根據業務場景來定，并沒有一定之規。

兩種登錄方案存在的問題

session方式

1. session方式由于會在服務器端維護session信息，單機還好說，如果是多機的話，服務器之間需要同步session信息，服務橫向擴展不方便。
2. session數量隨著登錄用戶的增多而增多，存儲會增加很多。
3. session+cookie里面存sessionId的方式可能會有csrf攻擊的問題，常見的方式是使用csrf_token來解決

jwt方式

1. jwt的過期時間需要結合業務做設置，而且jwt一旦派發出去，后端無法強行使其作廢

后話

理清概念，一身輕松

當前標題：前端設計中應該了解的web登錄
文章路徑：http://m.kartarina.com/news/100248.html

成都網站建設公司_創新互聯，為您提供網站設計、App設計、微信公眾號、網站導航、品牌網站建設、品牌網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯