前端設(shè)計(jì)中應(yīng)該了解的web登錄

當(dāng)時(shí)做登錄這塊的時(shí)候，被session、cookie、token各種概念差點(diǎn)整蒙圈了，上網(wǎng)查詢相關(guān)概念，發(fā)現(xiàn)很多人都是類似的疑惑，比如：

來(lái)了字節(jié)跳動(dòng)之后，前端很少接觸HTTP請(qǐng)求之后的事情，而且登錄相關(guān)的SDK封裝的很好，所以這篇文章就簡(jiǎn)單的學(xué)習(xí)記錄一下。

為什么會(huì)有登錄這回事

首先這是因?yàn)镠TTP是無(wú)狀態(tài)的協(xié)議，所謂無(wú)狀態(tài)就是在兩次請(qǐng)求之間服務(wù)器并不會(huì)保存任何的數(shù)據(jù)，相當(dāng)于你和一個(gè)人說(shuō)一句話之后他就把你忘掉了。所以，登錄就是用某種方法讓服務(wù)器在多次請(qǐng)求之間能夠識(shí)別出你，而不是每次發(fā)請(qǐng)求都得帶上用戶名密碼這樣的識(shí)別身份的信息。 從登錄成功到登出的這個(gè)過(guò)程，服務(wù)器一直維護(hù)了一個(gè)可以識(shí)別出用戶信息的數(shù)據(jù)結(jié)構(gòu)，廣義上來(lái)說(shuō)，這個(gè)過(guò)程就叫做session，也就是保持了一個(gè)會(huì)話。

常見(jiàn)的兩種登錄

忽然想到一點(diǎn)，看了網(wǎng)上很多問(wèn)題，我覺(jué)得大家應(yīng)該區(qū)分兩個(gè)概念：廣義的session和狹義的session

廣義的session：廣義的session就是從登錄成功到登出的過(guò)程，在這個(gè)過(guò)程中客戶端和服務(wù)器端維持了保持登錄的狀態(tài)，至于具體怎么維持住這種登錄的狀態(tài)，沒(méi)有要求。

狹義的session：狹義的session就是登錄成功后，服務(wù)器端存儲(chǔ)了一些必須的用戶信息，這部分存在服務(wù)器端的用戶信息就叫做session，也就是接下來(lái)要說(shuō)的第一種登錄的實(shí)現(xiàn)方式。

服務(wù)器session+客戶端sessionId

先用圖來(lái)看：

詳細(xì)說(shuō)的說(shuō)一下，這里面主要是這么幾個(gè)過(guò)程：

1. 客戶端帶著用戶名和密碼去訪問(wèn) /login 接口，服務(wù)器端收到后校驗(yàn)用戶名和密碼，校驗(yàn)正確就會(huì)在服務(wù)器端存儲(chǔ)一個(gè)sessionId和session的映射關(guān)系

2.服務(wù)器端返回response，并且將sessionId以set-cookie的方式種在客戶端，這樣一來(lái)，sessionId就存在了客戶端。這里要注意的是，將sessionId存在cookie并不是一種強(qiáng)制的方案，而是大家一般都這么做，而且發(fā)請(qǐng)求的時(shí)候符合domain和path的時(shí)候，會(huì)自動(dòng)帶上cookie，省去了手動(dòng)塞的過(guò)程。

3.客戶端發(fā)起非登錄請(qǐng)求時(shí)，服務(wù)端通過(guò)cookie中的sessionId找到對(duì)應(yīng)的session來(lái)知道此次請(qǐng)求是誰(shuí)發(fā)出的。

token

前面說(shuō)到sessionId的方式本質(zhì)是把用戶狀態(tài)信息維護(hù)在server端，token的方式就是把用戶的狀態(tài)信息加密成一串token傳給前端，然后每次發(fā)請(qǐng)求時(shí)把token帶上，傳回給服務(wù)器端；服務(wù)器端收到請(qǐng)求之后，解析token并且驗(yàn)證相關(guān)信息；

所以跟第一種登錄方式最本質(zhì)的區(qū)別是：通過(guò)解析token的計(jì)算時(shí)間換取了session的存儲(chǔ)空間

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

簡(jiǎn)單的介紹一下jwt，它主要由3部分組成：

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

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

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

signature是對(duì)前兩部分的簽名，也可以理解為加密；實(shí)現(xiàn)需要一個(gè)密鑰（secret），這個(gè)secret只有服務(wù)器才知道，然后使用header里面的算法按照如下方法來(lái)加密：

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

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

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

客戶端發(fā)起請(qǐng)求時(shí)，官方推薦放在HTTP header中：

Authorization: Bearer 復(fù)制代碼

這樣子確實(shí)也可以解決cookie跨域的問(wèn)題，不過(guò)具體放在哪兒還是根據(jù)業(yè)務(wù)場(chǎng)景來(lái)定，并沒(méi)有一定之規(guī)。

兩種登錄方案存在的問(wèn)題

session方式

1. session方式由于會(huì)在服務(wù)器端維護(hù)session信息，單機(jī)還好說(shuō)，如果是多機(jī)的話，服務(wù)器之間需要同步session信息，服務(wù)橫向擴(kuò)展不方便。
2. session數(shù)量隨著登錄用戶的增多而增多，存儲(chǔ)會(huì)增加很多。
3. session+cookie里面存sessionId的方式可能會(huì)有csrf攻擊的問(wèn)題，常見(jiàn)的方式是使用csrf_token來(lái)解決

jwt方式

1. jwt的過(guò)期時(shí)間需要結(jié)合業(yè)務(wù)做設(shè)置，而且jwt一旦派發(fā)出去，后端無(wú)法強(qiáng)行使其作廢

后話

理清概念，一身輕松

當(dāng)前標(biāo)題：前端設(shè)計(jì)中應(yīng)該了解的web登錄
文章路徑：http://www.bm7419.com/news/100248.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、App設(shè)計(jì)、微信公眾號(hào)、網(wǎng)站導(dǎo)航、品牌網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)