http 是無狀態(tài)的，即我們的一次請求結(jié)束后，下一次請求，服務(wù)端他并不知道是哪個(gè)用戶發(fā)來的。

我們在業(yè)務(wù)開發(fā)中通常是不需要關(guān)注是哪個(gè)客戶端發(fā)來的，更多的是關(guān)注是哪個(gè)用戶發(fā)來的。

基于這個(gè)特點(diǎn)，我們在處理業(yè)務(wù)邏輯時(shí)，就得想方設(shè)法地在下一次請求時(shí)讓服務(wù)端知道我是哪個(gè)用戶。

為什么是下一次呢？

因?yàn)槭紫任覀兊孟鹊卿?，才能告訴下一次請求是哪個(gè)，否則我們的很多業(yè)務(wù)就沒法開展，這就是所謂的會(huì)話管理。

那我們在項(xiàng)目里通常是怎么去管理我們的會(huì)話呢？

下面介紹常用的三種方式：

一、基于 server 端 session 的管理

在早期的 web 應(yīng)用中，我們通常都是使用這種方式來管理會(huì)話，它也叫服務(wù)端 session 管理，這里快速給大家介紹下它的處理邏輯：

• 用戶第一次訪問應(yīng)用時(shí)，服務(wù)端就會(huì)給他創(chuàng)建一個(gè)對(duì)象，用來存儲(chǔ)這次會(huì)話需要存儲(chǔ)的數(shù)據(jù)，同時(shí)會(huì)分配一個(gè)唯一的 sessionid（字符串）給這次請求，這樣就把用戶和 sessionid 進(jìn)行了關(guān)聯(lián)。
• 服務(wù)端處理完第一步之后，就會(huì)把 sessionid 以 cookie 的方式返回給客戶端，因?yàn)榭蛻舳嗣看握埱蠖紩?huì)帶上 cookie，所以后續(xù)的請求服務(wù)端都能從 cookie 里面得到 sessionid，以此來知道請求是哪個(gè)用戶發(fā)來的。
• session 是有失效時(shí)間的，比如 30 分鐘，當(dāng)失效時(shí)間到了，服務(wù)端就會(huì)銷毀之前創(chuàng)建的 session，下次客戶端再拿 sessionid 來請求也就找不到了，從而達(dá)到過期的效果。
• 但是只要客戶端在失效期內(nèi)再次訪問，session 的失效時(shí)間就會(huì)被再次延長，以此來保證用戶的良好體驗(yàn)。
• 單純的 session 是不具備會(huì)話管理的，這里面最關(guān)鍵的就是把登陸用戶和 sessionid 進(jìn)行關(guān)聯(lián)，如果不進(jìn)行關(guān)聯(lián)就不能起到會(huì)話管理的作用，在項(xiàng)目里面的體現(xiàn)就是：用戶登錄后就進(jìn)行session里面寫登錄用戶信息，從而實(shí)現(xiàn)關(guān)聯(lián)，用戶退出就刪除 session 里面的用戶信息，從而破壞關(guān)聯(lián)。

我在網(wǎng)上找了一張流程圖，感興趣可以看下：

這種方式有一個(gè)比較大的優(yōu)點(diǎn)就是安全性好，因?yàn)榭蛻舳撕头?wù)端保持會(huì)話的只有 sessionid，只要這個(gè) id 足夠的隨機(jī)，那么別人就很難偽造冒充。

即使偽造了 id 也得是后臺(tái)存在這個(gè) id 才行。

也不是說這種方式就絕對(duì)安全，除非他們通過 CSRF（跨站請求偽造）或者 http 劫持的方式，這又是另個(gè)話題了。

這種方式也存在缺點(diǎn)：

• 在線用戶量很多的時(shí)候，這些會(huì)話信息會(huì)比較占用空間。
• 當(dāng)應(yīng)用采用集群部署時(shí)，會(huì)遇到多臺(tái)服務(wù)器之間 session 共享的問題，因?yàn)楹芸赡芴幚碚埱蟮哪桥_(tái)服務(wù)器，不是創(chuàng)建 session 的那臺(tái)服務(wù)器。
• 假如你有多個(gè)應(yīng)用，想共享 session 時(shí)，還得處理跨域的問題。

前兩個(gè)問題現(xiàn)在已經(jīng)有比較成熟的解決方案了，那就是可以使用 Redis 這種中間服務(wù)來托管 session 的增刪改查。

對(duì)于第三個(gè)問題，解決起來就比較麻煩了，前后端都需要做處理，因?yàn)樗铌P(guān)鍵部分是 cookie，所以只要保證多個(gè)應(yīng)用之間的 cookie 能互通跨域就 OK。

這也是為啥現(xiàn)在的新系統(tǒng)，都很少使用這種方式了，有比較多的局限性。

這種方式也不是不能用了，畢竟與后來出現(xiàn)的兩種管理方式比，這種管理方式他的安全性相對(duì)來說是最高的。

比較適合單體服務(wù)網(wǎng)站使用。

二、cookie-based 的管理方式

由于第一種方式會(huì)增加服務(wù)端的負(fù)擔(dān)和架構(gòu)的復(fù)雜性，所以后來的人想，那我把用戶的登錄憑證直接存到客戶端這樣就不會(huì)增加服務(wù)端的負(fù)擔(dān)了哇。

于是就有了第二種，cookie-based 的管理方式。

即：當(dāng)用戶登錄成功后，直接把用戶的信息寫到 cookie 里面，這樣的話，上面的前兩個(gè)缺點(diǎn)都解決了。

他的流程大致為：

• 用戶發(fā)起登錄請求，登錄信息驗(yàn)證通過后，把用戶信息處理成一個(gè)登錄憑證，這個(gè)憑證需要有創(chuàng)建時(shí)間和過期時(shí)間，便于服務(wù)端處理過期。
• 服務(wù)端把登錄憑證進(jìn)行簽名，加密等操作（這步非常關(guān)鍵），保證其相對(duì)安全，然后寫入 cookie。
• 登錄后發(fā)起的請求，服務(wù)端就能根據(jù) cookie 里面的登錄憑證來知道是哪個(gè)用戶發(fā)起的請求了。

我又找了一張流程圖，請看：

這種方式最大的優(yōu)點(diǎn)就是實(shí)現(xiàn)了服務(wù)端的無狀態(tài)化，就是服務(wù)端不用再去管理會(huì)話了，服務(wù)端只需要處理?創(chuàng)建和驗(yàn)證?cookie 里面的登陸憑證就好了。

但是也存在缺點(diǎn)：

• cookie 是有大小限制的，存儲(chǔ)不了太多數(shù)據(jù)，所以對(duì)寫入的數(shù)據(jù)量有非常大的要求。
• cookie 也依舊存在跨域的問題。

最關(guān)鍵的是，不是所有客戶端都是瀏覽器，如果是 APP 這類不太好管理 cookie 的客戶端，這兩種方式都不太適用。

于是人們便又有了新方式！

三、token-based 的管理方式

這是目前用的比較多的方式，他本質(zhì)上和第二種沒太大區(qū)別，只不過第二種登憑證是放 cookie 里面，token-based 是丟給客戶端自己管理。

只需要下次請求時(shí)把 token（登錄憑證） 放請求頭里，或者和服務(wù)端約定好的地方，只要能獲取到的地方，就能達(dá)到驗(yàn)證的目的，從而進(jìn)行會(huì)話的管理。

看下流程圖：

這種方式服務(wù)端不再通過固定的 cookie 進(jìn)行 token 傳遞，所以他的靈活性更大，我們只需要：

• 存儲(chǔ)好服務(wù)端返回的 token，得保證每次調(diào)用接口的時(shí)候能拿到 token。
• 每次調(diào)用接口時(shí)，把 token 加到和服務(wù)端約定的地方，比如請求頭里面即可。

這種方式解決了第一種方式遺留的的三個(gè)問題：資源占用，共享，跨域。

但是也讓想偽造 token 的朋友們，更加容易偽造了，所以這種方式最關(guān)鍵的部分就是簽名了，簽名被破譯就等于完全打開了你家的大門。

四、總結(jié)

市面上在處理 token 的問題上，用得比較多就是?JWT 標(biāo)準(zhǔn)。

JWT 本身并沒有任何技術(shù)實(shí)現(xiàn)，他只是定義了 token 的生成的過程和方法，因此不同開發(fā)語言也就有了非常多開源的庫，實(shí)際開發(fā)中沒太大必要自己再去重復(fù)造一個(gè) JWT 的輪子。

第三種方式使用起來固然便捷，但是相對(duì)第一種和第二種來說，token 被偽造的可能性高出不是一點(diǎn)半點(diǎn)。

最關(guān)鍵的地方就是簽名的算法，相關(guān)的加密 Key 千萬千萬不能泄露了。

這三種方式都有一個(gè)終結(jié)問題，就是 CSRF 攻擊（跨站請求偽造）。

其原理就是通過各種方法偷偷拿到別人的登錄憑證，然后偽造請求。

其解決方案針對(duì)不同的攻擊方式解決方案不一樣，完全取決于開發(fā)人員對(duì)這種攻擊方式的了解程度，所以親們，有空多看看 CSRF 這方面的知識(shí)吧！

這里提供一種非常具有代表性的攻擊方式：

假如你的 token 是放在 cookie 里面的，正常情況下別人是很難拿到的。

但是假如你的網(wǎng)站里，用戶有填寫外鏈的地方，比如評(píng)論，此時(shí)如果其他地方填寫了他的服務(wù)地址，又或者你掛了外網(wǎng)的圖片地址等。

這樣你網(wǎng)站在請求這些外網(wǎng)地址的時(shí)候，也就間接的泄露了你的 cookie，假如這個(gè)地址是別人的惡意地址，后果就可想而知了。

這就是一種典型的 CSRF 跨站攻擊方式。

安全無小事，防范需謹(jǐn)慎！

原文鏈接：https://mp.weixin.qq.com/s/Njss-eZz6LMgpcRsmDFbOw