Web會話管理

基於token的管理

重新整理安全問題

web應用通常使用的是http請求，但是http是無狀態的，一次請求結束，連線就會自動斷開，伺服器只能知道每個請求的**位址，可是這對會話的管理毫無意義。根本無法對使用者進行認證和許可權控制。於是，就有了相應的方案來解決這問題。常用的方法有三個：

在早期的web應用中，基本上採用的都是此種方式來進行會話管理。session是服務端建立的乙個全域性物件，在這個物件中儲存使用者的登入資訊，就可以達到會話管理的目的。

主要問題：

使用者第一次訪問應用是，服務端會建立session物件，可以在session中儲存使用者的資訊，從而進行會話管理。每個session有個唯一的sessionid，會寫回到客戶端的cookie中，每次伺服器從cookie中讀取id並通過id獲取session，但是當使用者量過大時，伺服器壓力會特別大

session是由伺服器建立的，在集群是，其本身並不具備共享的特性

如果多個應用共用乙個session，就會存在跨域的問題

後來用redis來儲存session，成功避免了伺服器的壓力。共享也可以通過redis實現，但是，由於session的傳遞依賴sessionid，而sessionid依賴cookie，所以cookie就出現了跨域的問題。

由於這種方式，在使用者量上公升之後，會大幅度的提公升伺服器壓力以及架構複雜性。所以，很快就被淘汰了。

為了減小伺服器的壓力和架構複雜性，於是就想到了把使用者的登入資訊放在客戶端來解決這個問題。cookie正好可以實現這個功能。把登入憑證放在cookie中並設定有效期，每次登入就驗證cookie中登入憑證即可。

基本流程

使用者發起登陸請求，請求引數包括使用者名稱（也可以是郵箱、手機號等）、密碼，有時候還會有驗證碼之類的，服務端使用這些東西，建立乙個憑證（一般稱為ticket），這個憑證至少要包含2個值：

服務端建立完ticket後，最好不要直接返回，而是先做乙個數字簽名，數字簽名演算法可以使用常用的rsa，如有必要再複雜化演算法從而保證資料完整性

ticket加密完畢後，寫到客戶端的cookie中，後續客戶端發起任何請求都要帶著這個cookie，伺服器會自動進行解密、驗證，驗證失敗，則需要重新登入

優點對伺服器的壓力基本為0，伺服器只是每次解密驗證一下ticket。只需要保證不同的應用伺服器中部署的**中的加解密演算法一樣就行。缺點

實現與流程上來說，與cookie的方式一樣，區別是，token會放在請求頭（這種方式用的比較多）或者請求引數中，而不是cookie中。服務端從請求頭或者請求引數中獲取到token進行驗證。

這種方式對前端的友好度是最高的，前端只需要做兩件事：

有效的儲存token，保證需要的時候都能拿得到

保證每次呼叫介面時都可以準確的攜帶token

這兩件事都是可以通過全域性的元件或者模組封裝來實現的，所以說，前端的工作量基本上是0。

ticket和token都存在乙個問題，那就是重新整理的問題。因為不管token的期限多久，總會有過期的時候，而如果過期的時候，使用者恰好就在應用中操作，那麼這時候使用者會突然被踢出去，並要求重新登入，這肯定是不合理的。所以這時候就需要為使用者自動更新token。

最簡單的方式，就是前端捕獲錯誤，而後靜默自動登入獲取新的token。這種方式的安全性不夠，存在無限獲取token的bug。於是oauth2.0推出了refresh token的概念。以此來驗證是否有獲取新token的許可權。

基於session的方式，它的安全重心就是sessionid，要保證足夠隨機才能避免被他人冒充。

基於cookie和token的方式，憑證都是乙個在服務端簽名加密過的字串，安全中心就是簽名和加密的演算法，要保證金鑰的安全性才能避免被篡改憑證，冒充他人。

web應用最難解決的安全問題就是csrf了。這種問題，從本質上來說，是**的bug造成的，但是這種bug已經不是表層bug，有的bug甚至是和作業系統關聯造成的。這種安全問題是很難遇到的，但是也是最難防護的。只能去了解常見的攻擊方式並使用大佬給的應對方法。

至於更高階的，如http劫持等，這些靠**就已經防護不了了。就需要專業的安全工程師來對伺服器就行安全防護。