三種常用的會話管理

• 前言
• 基于server-session的管理
• cookie-based的管理方式
• token-based的管理方式
• 總結（安全問題）

前言

在人機互動，會話管理是保持用戶的整個會話活動的互動與計算機系統跟蹤程序，簡單說就是讓用戶和服務器之間保持一種連接的標識，這使得瀏覽器可以在多個請求中”認出“用戶，可以同時在多個頁面之間共享一些資訊，

下面總結三種會話管理的方式，

基于server-session的管理

1、服務端session是用戶第一次訪問應用時，服務器就會創建的物件，代表用戶的一次會話程序，服務器為每一個session都分配一個唯一的sessionid，以保證每個用戶都有一個不同的session物件，

2、服務器在創建完session后，會把sessionid通過cookie回傳給用戶所在的瀏覽器，這樣當用戶第二次及以后向服務器發送請求的時候，就會通過cookie把sessionid傳回給服務器，以便服務器能夠根據sessionid找到與該用戶對應的session物件，

3、session通常有失效時間的設定，比如2個小時，當失效時間到，服務器會銷毀之前的session，并創建新的session回傳給用戶，但是只要用戶在失效時間內，有發送新的請求給服務器，通常服務器都會把他對應的session的失效時間根據當前的請求時間再延長2個小時，

4、session在一開始并不具備會話管理的作用，它只有在用戶登錄認證成功之后，并且往session物件里面放入了用戶登錄成功的憑證，才能用來管理會話，管理會話的邏輯也很簡單，只要拿到用戶的session物件，看它里面有沒有登錄成功的憑證，就能判斷這個用戶是否已經登錄，當用戶主動退出的時候，會把它的session物件里的登錄憑證清掉，所以在用戶登錄前或退出后或者session物件失效時，肯定都是拿不到需要的登錄憑證的，

以上程序可簡單使用流程圖描述如下：

它還有一個比較大的優點就是安全性好，因為在瀏覽器端與服務器端保持會話狀態的媒介始終只是一個sessionid串，只要這個串夠隨機，攻擊者就不能輕易冒充他人的sessionid進行操作；

除非通過CSRF或http劫持的方式，才有可能冒充別人進行操作；

即使冒充成功，也必須被冒充的用戶session里面包含有效的登錄憑證才行，

但是在真正決定用它管理會話之前，也得根據自己的應用情況考慮以下幾個問題：

1. 這種方式將會話資訊存盤在web服務器里面，所以在用戶同時在線量比較多時，這些會話資訊會占據比較多的記憶體；
2. 當應用采用集群部署的時候，會遇到多臺web服務器之間如何做session共享的問題，因為session是由單個服務器創建的，但是處理用戶請求的服務器不一定是那個創建session的服務器，這樣他就拿不到之前已經放入到session中的登錄憑證之類的資訊了；
3. 多個應用要共享session時，除了以上問題，還會遇到跨域問題，因為不同的應用可能部署的主機不一樣，需要在各個應用做好cookie跨域的處理，

針對問題1和問題2，我見過的解決方案是采用redis這種中間服務器來管理session的增刪改查，一來減輕web服務器的負擔，二來解決不同web服務器共享session的問題，

針對問題3，由于服務端的session依賴cookie來傳遞sessionid，所以在實際專案中，只要解決各個專案里面如何實作sessionid的cookie跨域訪問即可，這個是可以實作的，就是比較麻煩，前后端有可能都要做處理，

cookie-based的管理方式

由于前一種方式會增加服務器的負擔和架構的復雜性，所以后來就有人想出直接把用戶的登錄憑證直接存到客戶端的方案，當用戶登錄成功之后，把登錄憑證寫到cookie里面，并給cookie設定有效期，后續請求直接驗證存有登錄憑證的cookie是否存在以及憑證是否有效，即可判斷用戶的登錄狀態，使用它來實作會話管理的整體流程如下：

1、用戶發起登錄請求，服務端根據傳入的用戶密碼之類的身份資訊，驗證用戶是否滿足登錄條件，如果滿足，就根據用戶資訊創建一個登錄憑證，這個登錄憑證簡單來說就是一個物件，最簡單的形式可以只包含用戶id，憑證創建時間和過期時間三個值，

2、服務端把上一步創建好的登錄憑證，先對它做數字簽名，然后再用對稱加密演算法做加密處理，將簽名、加密后的字串，寫入cookie，cookie的名字必須固定（如ticket），因為后面再獲取的時候，還得根據這個名字來獲取cookie值，這一步添加數字簽名的目的是防止登錄憑證里的資訊被篡改，因為一旦資訊被篡改，那么下一步做簽名驗證的時候肯定會失敗，做加密的目的，是防止cookie被別人截取的時候，無法輕易讀到其中的用戶資訊，

3、用戶登錄后發起后續請求，服務端根據上一步存登錄憑證的cookie名字，獲取到相關的cookie值，然后先做解密處理，再做數字簽名的認證，如果這兩步都失敗，說明這個登錄憑證非法；如果這兩步成功，接著就可以拿到原始存入的登錄憑證了，然后用這個憑證的過期時間和當前時間做對比，判斷憑證是否過期，如果過期，就需要用戶再重新登錄；如果未過期，則允許請求繼續，

這種方式最大的優點就是實作了服務端的無狀態化，徹底移除了服務端對會話的管理的邏輯，服務端只需要負責創建和驗證登錄cookie即可，無需保持用戶的狀態資訊，

對于第一種方式的第二個問題，用戶會話資訊共享的問題，它也能很好解決：因為如果只是同一個應用做集群部署，由于驗證登錄憑證的代碼都是一樣的，所以不管是哪個服務器處理用戶請求，總能拿到cookie中的登錄憑證來進行驗證；

如果是不同的應用，只要每個應用都包含相同的登錄邏輯，那么他們也是能輕易實作會話共享的，不過這種情況下，登錄邏輯里面數字簽名以及加密解密要用到的密鑰檔案或者密鑰串，需要在不同的應用里面共享，總而言之，就是需要演算法完全保持一致，

這種方式由于把登錄憑證直接存放客戶端，并且需要cookie傳來傳去，所以它的缺點也比較明顯：

1. cookie有大小限制，存盤不了太多資料，所以要是登錄憑證存的訊息過多，導致加密簽名后的串太長，就會引發別的問題，比如其它業務場景需要cookie的時候，就有可能沒那么多空間可用了；所以用的時候得謹慎，得觀察實際的登錄cookie的大小；比如太長，就要考慮是非是數字簽名的演算法太嚴格，導致簽名后的串太長，那就適當調整簽名邏輯；比如如果一開始用4096位的RSA演算法做數字簽名，可以考慮換成1024、2048位；
2. 每次傳送cookie，增加了請求的數量，對訪問性能也有影響；
3. 也有跨域問題，畢竟還是要用cookie，

前面兩種會話管理方式因為都用到cookie，不適合用在native app里面：native app不好管理cookie，畢竟它不是瀏覽器，這兩種方案都不適合用來做純api服務的登錄認證，要實作api服務的登錄認證，就要考慮下面要介紹的第三種會話管理方式，

token-based的管理方式

這種方式從流程和實作上來說，跟cookie-based的方式沒有太多區別，只不過cookie-based里面寫到cookie里面的ticket在這種方式下稱為token，這個token在回傳給客戶端之后，后續請求都必須通過url引數或者是http header的形式，主動帶上token，這樣服務端接收到請求之后就能直接從http header或者url里面取到token進行驗證：

這種方式不通過cookie進行token的傳遞，而是每次請求的時候，主動把token加到http header里面或者url后面，所以即使在native app里面也能使用它來呼叫我們通過web發布的api介面，app里面還要做兩件事情：

1、有效存盤token，得保證每次調介面的時候都能從同一個位置拿到同一個token；

2、每次調介面的的代碼里都得把token加到header或者介面地址里面，

看起來麻煩，其實也不麻煩，這兩件事情，對于app來說，很容易做到，只要對介面呼叫的模塊稍加封裝即可，

這種方式同樣適用于網頁應用，token可以存于localStorage或者sessionStorage里面，然后每發ajax請求的時候，都把token拿出來放到ajax請求的header里即可，不過如果是非介面的請求，比如直接通過點擊鏈接請求一個頁面這種，是無法自動帶上token的，所以這種方式也僅限于走純介面的web應用，

這種方式用在web應用里也有跨域的問題，比如應用如果部署在a.com，api服務部署在b.com，從a.com里面發出ajax請求到b.com，默認情況下是會報跨域錯誤的，這種問題可以用CORS（跨域資源共享）的方式來快速解決，

這種方式跟cookie-based的方式同樣都還有的一個問題就是ticket或者token重繪的問題，有的產品里面，你肯定不希望用戶登錄后，操作了半個小時，結果ticket或者token到了過期時間，然后用戶又得去重新登錄的情況出現，這個時候就得考慮ticket或token的自動重繪的問題，簡單來說，可以在驗證ticket或token有效之后，自動把ticket或token的失效時間延長，然后把它再回傳給客戶端；客戶端如果檢測到服務器有回傳新的ticket或token，就替換原來的ticket或token，

總結（安全問題）

在web應用里面，會話管理的安全性始終是最重要的安全問題，這個對用戶的影響極大，

首先從會話管理憑證來說

第一種方式的會話憑證僅僅是一個sessionid，所以只要這個sessionid足夠隨機，而不是一個自增的數字id值，那么其它人就不可能輕易地冒充別人的sessionid進行操作；

第二種方式的憑證ticket以及第三種方式的憑證token都是一個在服務端做了數字簽名，和加密處理的串，所以只要密鑰不泄露，別人也無法輕易地拿到這個串中的有效資訊并對它進行篡改，

總之，這三種會話管理方式的憑證本身是比較安全的，

然后從客戶端和服務端的http程序來說，當別人截獲到客戶端請求中的會話憑證，就能拿這個憑證冒充原用戶，做一些非法操作，而服務器也認不出來，這種安全問題，可以簡單采用https來解決，雖然可能還有http劫持這種更高程度的威脅存在，但是我們從代碼能做的防范，確實也就是這個層次了，

標籤：其他

上一篇：云原生系列2 部署你的第一個k8s應用

下一篇：簡單介紹Java中的【方法多載】