資訊專欄INFORMATION COLUMN
摘要：客戶端發(fā)起非登錄請求時，服務(wù)端通過中的找到對應(yīng)的來知道此次請求是誰發(fā)出的。數(shù)量隨著登錄用戶的增多而增多，存儲會增加很多。
還記得在上家公司做全干工程師的時候，基本從頁面寫到運維，當時做登錄這塊的時候，被session、cookie、token各種概念差點整蒙圈了，上網(wǎng)查詢相關(guān)概念，發(fā)現(xiàn)很多人都是類似的疑惑，比如：來了字節(jié)跳動之后，前端很少接觸HTTP請求之后的事情，而且登錄相關(guān)的SDK封裝的很好，所以這篇文章就簡單的學(xué)習(xí)記錄一下。
首先這是因為HTTP是無狀態(tài)的協(xié)議，所謂無狀態(tài)就是在兩次請求之間服務(wù)器并不會保存任何的數(shù)據(jù)，相當于你和一個人說一句話之后他就把你忘掉了。所以，登錄就是用某種方法讓服務(wù)器在多次請求之間能夠識別出你，而不是每次發(fā)請求都得帶上用戶名密碼這樣的識別身份的信息。
從登錄成功到登出的這個過程，服務(wù)器一直維護了一個可以識別出用戶信息的數(shù)據(jù)結(jié)構(gòu)，廣義上來說，這個過程就叫做session，也就是保持了一個會話。
忽然想到一點，看了網(wǎng)上很多問題，我覺得大家應(yīng)該區(qū)分兩個概念：廣義的session和狹義的session
廣義的session：廣義的session就是從登錄成功到登出的過程，在這個過程中客戶端和服務(wù)器端維持了保持登錄的狀態(tài)，至于具體怎么維持住這種登錄的狀態(tài)，沒有要求。
狹義的session：狹義的session就是登錄成功后，服務(wù)器端存儲了一些必須的用戶信息，這部分存在服務(wù)器端的用戶信息就叫做session，也就是接下來要說的第一種登錄的實現(xiàn)方式。
服務(wù)器session+客戶端sessionId先用圖來看：
詳細說的說一下，這里面主要是這么幾個過程：
客戶端帶著用戶名和密碼去訪問 /login 接口，服務(wù)器端收到后校驗用戶名和密碼，校驗正確就會在服務(wù)器端存儲一個sessionId和session的映射關(guān)系
服務(wù)器端返回response，并且將sessionId以set-cookie的方式種在客戶端，這樣一來，sessionId就存在了客戶端。這里要注意的是，將sessionId存在cookie并不是一種強制的方案，而是大家一般都這么做，而且發(fā)請求的時候符合domain和path的時候，會自動帶上cookie，省去了手動塞的過程。
?客戶端發(fā)起非登錄請求時，服務(wù)端通過cookie中的sessionId找到對應(yīng)的session來知道此次請求是誰發(fā)出的。
前面說到sessionId的方式本質(zhì)是把用戶狀態(tài)信息維護在server端，token的方式就是把用戶的狀態(tài)信息加密成一串token傳給前端，然后每次發(fā)請求時把token帶上，傳回給服務(wù)器端；服務(wù)器端收到請求之后，解析token并且驗證相關(guān)信息；
所以跟第一種登錄方式最本質(zhì)的區(qū)別是：通過解析token的計算時間換取了session的存儲空間
業(yè)界通用的加密方式是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里面放的是用戶的信息，也就是第一種登錄方式中需要維護在服務(wù)器端session中的信息；
signature是對前兩部分的簽名，也可以理解為加密；實現(xiàn)需要一個密鑰（secret），這個secret只有服務(wù)器才知道，然后使用header里面的算法按照如下方法來加密：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)總之，最后的 jwt = base64url(header) + "." + base64url(payload) + "." + signature
jwt可以放在response中返回，也可以放在cookie中返回，這都是具體的返回方式，并不重要。
客戶端發(fā)起請求時，官方推薦放在HTTP header中：
Authorization: Bearer
這樣子確實也可以解決cookie跨域的問題，不過具體放在哪兒還是根據(jù)業(yè)務(wù)場景來定，并沒有一定之規(guī)。
session方式由于會在服務(wù)器端維護session信息，單機還好說，如果是多機的話，服務(wù)器之間需要同步session信息，服務(wù)橫向擴展不方便。
session數(shù)量隨著登錄用戶的增多而增多，存儲會增加很多。
session+cookie里面存sessionId的方式可能會有csrf攻擊的問題，常見的方式是使用csrf_token來解決
jwt的過期時間需要結(jié)合業(yè)務(wù)做設(shè)置，而且jwt一旦派發(fā)出去，后端無法強行使其作廢
理清概念，一身輕松
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/7311.html
摘要：我拖拖拖拖放基礎(chǔ)篇前端掘金不要搞錯，本文不是講如何拖地的。結(jié)構(gòu)說明前端應(yīng)該從哪些方面來優(yōu)化網(wǎng)站前端掘金不知道是哪位大牛的文章，轉(zhuǎn)過來回答。 我拖拖拖 --H5 拖放 API 基礎(chǔ)篇 - 前端 - 掘金不要搞錯，本文不是講如何拖地的?？催^《javascript精粹》朋友應(yīng)該知道，他實現(xiàn)拖放的過程比較復(fù)雜，現(xiàn)在時代不同了，我們用H5的新的拖放API就能非常方便的實現(xiàn)拖放效果了。最近在園子見...
摘要：在使用非對稱加密算法進行簽名的時候，還可以用于驗證的發(fā)件人是否與中申明的發(fā)件人是同一個人。如果沒有用非對稱加密算法的話，把復(fù)制之后直接可以去官網(wǎng)在線解析。 這篇博客主要是簡單介紹了一下什么是JWT，以及如何在Spring Boot項目中使用JWT(JSON Web Token)。 1.關(guān)于JWT 1.1 什么是JWT 老生常談的開頭，我們要用這樣一種工具，首先得知道以下幾個問題。 這...
摘要：探究系統(tǒng)登錄驗證碼的實現(xiàn)后端掘金驗證碼生成類手把手教程后端博客系統(tǒng)第一章掘金轉(zhuǎn)眼間時間就從月份到現(xiàn)在的十一月份了。提供了與標準不同的工作方式我的后端書架后端掘金我的后端書架月前本書架主要針對后端開發(fā)與架構(gòu)。 Spring Boot干貨系列總綱 | 掘金技術(shù)征文 - 掘金原本地址：Spring Boot干貨系列總綱博客地址：http://tengj.top/ 前言 博主16年認識Spin...
摘要：搭建簡單登錄注冊還是我又來了近來突然對數(shù)據(jù)庫和后臺有點感興趣就開始了漫長的學(xué)習(xí)之路想想自己只是一個前端只會斯科瑞普所以就開始看看著看著突然發(fā)現(xiàn)和更配哦遂就開了我的之路由于我的表達能力有限下面的文章可能寫的不是那么詳細有看不懂的可以去我上看源 nodejs+mongodb搭建簡單登錄注冊 biu!biu!biu!還是我又來了!!! 近來突然對數(shù)據(jù)庫和后臺有點感興趣,就開始了漫長的學(xué)習(xí)之...
閱讀 525·2021-10-09 09:57
閱讀 545·2019-08-29 18:39
閱讀 878·2019-08-29 12:27
閱讀 3083·2019-08-26 11:38
閱讀 2737·2019-08-26 11:37
閱讀 1343·2019-08-26 10:59
閱讀 1433·2019-08-26 10:58
閱讀 1036·2019-08-26 10:48
