node.js極速入門(mén)課程：進(jìn)入學(xué)習(xí)

目前絕大多數(shù)的系統(tǒng)都少不了登錄驗(yàn)證的功能，這主要是為了保存用戶(hù)的狀態(tài)，以此來(lái)限制用戶(hù)的各種行為，從而方便有效的控制用戶(hù)的權(quán)限。比如一個(gè)用戶(hù)登陸微博，發(fā)布、關(guān)注、評(píng)論的操作都應(yīng)是在登錄后的用戶(hù)狀態(tài)下進(jìn)行的。

實(shí)現(xiàn)登錄驗(yàn)證的功能主要有Cookie&Session、JWT兩種方式，這一節(jié)我們將先對(duì) Cookie&Session的工作原理 做詳細(xì)的介紹，在之后的文章中會(huì)陸續(xù)對(duì)JWT，以及如何使用Cookie&Session和JWT來(lái)完善前幾節(jié)我們搭建的簡(jiǎn)易用戶(hù)管理系統(tǒng)進(jìn)行講解。【相關(guān)教程推薦：nodejs視頻教程】

1️⃣ Cookie&Session

我們知道，HTTP 是無(wú)狀態(tài)的。也就是說(shuō)，HTTP 請(qǐng)求方和響應(yīng)方間無(wú)法維護(hù)狀態(tài)，都是一次性的，它不知道前后的請(qǐng)求都發(fā)生了什么。但有的場(chǎng)景下，我們需要維護(hù)狀態(tài)。最典型的，一個(gè)用戶(hù)登陸微博，發(fā)布、關(guān)注、評(píng)論，都應(yīng)是在登錄后的用戶(hù)狀態(tài)下的。

這個(gè)時(shí)候就可以引入Cookie與Session來(lái)保存用戶(hù)的登錄狀態(tài)。

本篇文章主要介紹使用Cookie-Session來(lái)做登錄驗(yàn)證的工作原理，關(guān)于Cookie與Session的詳細(xì)介紹可查閱這位大佬的文章：Cookie和Session詳解

為什么不單獨(dú)使用Cookie？

Cookie是存放在瀏覽器中的，可以在瀏覽器中打開(kāi)控制臺(tái)，選擇應(yīng)用，找到存儲(chǔ)中的Cookie進(jìn)行查看：

當(dāng)客戶(hù)端向服務(wù)端發(fā)送網(wǎng)絡(luò)請(qǐng)求時(shí)瀏覽器會(huì)自動(dòng)將Cookie添加到請(qǐng)求頭中，這樣服務(wù)端就能獲取這個(gè)Cookie，如下：

知道了這個(gè)原理后，我們就可以想到，如果在用戶(hù)登錄系統(tǒng)時(shí)：客戶(hù)端由用戶(hù)的部分登錄信息（比如username、id等）生成一個(gè)Cookie存放到瀏覽器中，那么在這之后的每一次網(wǎng)絡(luò)請(qǐng)求都會(huì)自動(dòng)攜帶上該Cookie。

之后讓服務(wù)端根據(jù)請(qǐng)求中是否攜帶Cookie并且攜帶的Cookie中是否存在有效的username、id來(lái)判斷用戶(hù)是否已經(jīng)登錄過(guò)了，這樣一來(lái)用戶(hù)的登錄狀態(tài)不就被保存下來(lái)了嗎。

回到上面我們提到的微博的例子，按照這種過(guò)程來(lái)說(shuō)，當(dāng)用戶(hù)登錄過(guò)后Cookie已經(jīng)被保存，這時(shí)當(dāng)用戶(hù)進(jìn)行發(fā)布、關(guān)注、評(píng)論等需要登錄才能使用的操作時(shí)我們就能提前判斷是否存在Cookie，如果存在并且Cookie中含有該用戶(hù)的id，那么我們就可以允許該用戶(hù)的這些操作（這些操作一般都是需要用戶(hù)的id的，這時(shí)就可以從Cookie中進(jìn)行獲取）。相反的，如果Cookie不存在或者Cookie無(wú)效，那么就禁止該用戶(hù)的這些操作。

說(shuō)到這，你可能會(huì)問(wèn)：既然一個(gè)Cookie就能實(shí)現(xiàn)我們想要的效果，那為何還要使用Session呢？

這是因?yàn)?Cookie很容易被偽造！ ，如果我們知道了Cookie中存放的信息是username和id（就算不知道，也可以在登錄后的網(wǎng)絡(luò)請(qǐng)求的請(qǐng)求體中找到Cookie），那么我們完全可以在不登錄的情況下手動(dòng)向?yàn)g覽器存儲(chǔ)一個(gè)偽造的Cookie：

說(shuō)到這，你應(yīng)該就能明白為什么不能單獨(dú)使用Cookie了吧。

Session是如何與Cookie結(jié)合的？

Session其實(shí)是基于Cookie實(shí)現(xiàn)的，并且Session存儲(chǔ)在服務(wù)端的內(nèi)存或者數(shù)據(jù)庫(kù)中。

當(dāng)用戶(hù)登錄成功時(shí)，使用Cookie&Session的登錄驗(yàn)證會(huì)進(jìn)行以下操作：

• 由服務(wù)端生成Session與SessionId；

  Session一般是根據(jù)用戶(hù)登錄的信息，如用戶(hù)名、id等進(jìn)行生成。
  如果把Session比作是一把鎖，那么SessionId就相當(dāng)于是這把鎖的鑰匙。

• 服務(wù)端將Session存儲(chǔ)到內(nèi)存或者數(shù)據(jù)庫(kù)中；

• 服務(wù)端將SessionId存放到請(qǐng)求的響應(yīng)頭（response對(duì)象）中的Set-Cookie字段中發(fā)送給客戶(hù)端；

• 客戶(hù)端收到Set-Cookie后會(huì)自動(dòng)將Set-Cookie的值（也就是SessionId）存放到Cookie中；

• 之后的每次網(wǎng)絡(luò)請(qǐng)求都會(huì)自動(dòng)帶上Cookie，也就是帶上這個(gè)SessionId；

• 服務(wù)端收到后續(xù)請(qǐng)求時(shí)獲取請(qǐng)求上的Cookie，也就是獲取到了SessionId，然后通過(guò)SessionId查詢(xún)并校驗(yàn)服務(wù)端存儲(chǔ)的Session，若校驗(yàn)成功說(shuō)明這個(gè)SessionId有效則通過(guò)此次請(qǐng)求，反之則阻止此次請(qǐng)求。

圖示：

2️⃣ Cookie&Session的缺陷

存儲(chǔ)問(wèn)題

為了保存用戶(hù)的登錄狀態(tài)，我們需要為每一位登錄的用戶(hù)生成并存儲(chǔ)Session，這勢(shì)必就會(huì)造成以下問(wèn)題：

• 如果Session存放到內(nèi)存中，那么當(dāng)服務(wù)端重啟時(shí)，這些內(nèi)存中的Session都將被清除，那么所有用戶(hù)的登錄狀態(tài)都將會(huì)過(guò)期，并且當(dāng)用戶(hù)量較大時(shí)，過(guò)多的內(nèi)存占用也勢(shì)必會(huì)影響服務(wù)端的性能。
• 如果Session存放到數(shù)據(jù)庫(kù)中，雖然能夠解決因服務(wù)端重啟造成用戶(hù)登錄狀態(tài)過(guò)期的問(wèn)題，但當(dāng)用戶(hù)量較大時(shí)，對(duì)于這個(gè)數(shù)據(jù)庫(kù)的維護(hù)也會(huì)變得相對(duì)困難。
• 如果前端頁(yè)面中調(diào)用的接口來(lái)自?xún)蓚€(gè)服務(wù)器（也就是兩套數(shù)據(jù)庫(kù)），為了實(shí)現(xiàn)Session在兩個(gè)服務(wù)器間共享通常會(huì)將Session存放到一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)中，這樣就使得整個(gè)項(xiàng)目變得更為復(fù)雜也更加難以維護(hù)。
  

CSRF問(wèn)題

CSRF全稱(chēng)為 Cross-site request forgery 即 跨站請(qǐng)求偽造，使用Cookie進(jìn)行驗(yàn)證的網(wǎng)站都會(huì)面臨或大或小的CSRF威脅，我們以一個(gè)銀行網(wǎng)站的例子來(lái)介紹CSRF的攻擊原理：

假如一家銀行網(wǎng)站A的登錄驗(yàn)證采用的是Cookie&Session，并且該網(wǎng)站上用以運(yùn)行轉(zhuǎn)賬操作的Api地址為：http://www.grillbankapi.com/?account=AccoutName&amount=1000

api參數(shù)：account代表賬戶(hù)名，amount代表轉(zhuǎn)賬金額。

那么，一個(gè)惡意攻擊者可以在另一個(gè)網(wǎng)站B上放置如下代碼：

<img src="http://www.grillbankapi.com/?account=Ailjx&amount=1000">

注意：img標(biāo)簽的src是網(wǎng)站A轉(zhuǎn)賬操作的api地址，并且參數(shù)account為Ailjx，amount為1000，也就是說(shuō)這個(gè)api地址相當(dāng)于是賬戶(hù)名為 Ailjx 轉(zhuǎn)賬1000 時(shí)調(diào)用的api。

如果有賬戶(hù)名為 Ailjx 的用戶(hù)剛訪(fǎng)問(wèn)過(guò)網(wǎng)站A不久，登錄信息尚未過(guò)期（網(wǎng)站A的Cookie存在且有效）。

那么當(dāng) Ailjx 訪(fǎng)問(wèn)了這個(gè)惡意網(wǎng)站B時(shí)，上面的img標(biāo)簽將被加載，瀏覽器就會(huì)自動(dòng)請(qǐng)求img標(biāo)簽的src路由，也就是請(qǐng)求http://www.grillbankapi.com/?account=Ailjx&amount=1000 （我們將這個(gè)請(qǐng)求記為請(qǐng)求Q），并且因?yàn)?code>Cookie存放在瀏覽器中且瀏覽器發(fā)送請(qǐng)求時(shí)會(huì)自動(dòng)帶上Cookie，所以請(qǐng)求Q上就會(huì)自動(dòng)攜帶 Ailjx 在網(wǎng)站A上的Cookie憑證，結(jié)果就是這個(gè) 請(qǐng)求Q將會(huì)被通過(guò)，那么 Ailjx 就會(huì)損失1000資金。

這種惡意的網(wǎng)址可以有很多種形式，藏身于網(wǎng)頁(yè)中的許多地方。 此外，攻擊者也不需要控制放置惡意網(wǎng)址的網(wǎng)站。例如他可以將這種地址藏在論壇，博客等任何用戶(hù)生成內(nèi)容的網(wǎng)站中。這意味著如果服務(wù)端沒(méi)有合適的防御措施的話(huà)，用戶(hù)即使訪(fǎng)問(wèn)熟悉的可信網(wǎng)站也有受攻擊的危險(xiǎn)。

透過(guò)例子能夠看出，攻擊者并不能通過(guò)CSRF攻擊來(lái)直接獲取用戶(hù)的賬戶(hù)控制權(quán)，也不能直接竊取用戶(hù)的任何信息。他們能做到的，是欺騙用戶(hù)瀏覽器，讓其以用戶(hù)的名義運(yùn)行操作。

這些就是使用Cookie&Session來(lái)做登錄驗(yàn)證的問(wèn)題所在，那么我們?nèi)绾谓鉀Q這些問(wèn)題呢？這就需要引入JWT的概念，使用token來(lái)做登錄驗(yàn)證，這些我們將在之后的文章中進(jìn)行講解。