session,cookie,sessionStorage,localStorage的區別及應用場景

瀏覽器的緩存機制提供了能夠將用戶數據存儲在客戶端上的方式，能夠利用cookie,session等跟服務端進行數據交互。

1、cookie和session

cookie和session都是用來跟蹤瀏覽器用戶身份的會話方式。

區別：

一、保持狀態：cookie保存在瀏覽器端，session保存在服務器端

二、使用方式：

（1）cookie機制：若是不在瀏覽器中設置過時時間，cookie被保存在內存中，生命週期隨瀏覽器的關閉而結束，這種cookie簡稱會話cookie。若是在瀏覽器中設置了cookie的過時時間，cookie被保存在硬盤中，關閉瀏覽器後，cookie數據仍然存在，直到過時時間結束才消失。

     Cookie是服務器發給客戶端的特殊信息，cookie是以文本的方式保存在客戶端，每次請求時都帶上它

（2）session機制：當服務器收到請求須要建立session對象時，首先會檢查客戶端請求中是否包含sessionid。若是有sessionid，服務器將根據該id返回對應session對象。若是客戶端請求中沒有sessionid，服務器會建立新的session對象，並把sessionid在本次響應中返回給客戶端。一般使用cookie方式存儲sessionid到客戶端，在交互中瀏覽器按照規則將sessionid發送給服務器。若是用戶禁用cookie，則要使用URL重寫，能夠經過response.encodeURL(url) 進行實現；API對encodeURL的結束爲，當瀏覽器支持Cookie時，url不作任何處理；當瀏覽器不支持Cookie的時候，將會重寫URL將SessionID拼接到訪問地址後。

三、存儲內容：cookie只能保存字符串類型，以文本的方式；session經過相似與Hashtable的數據結構來保存，能支持任何類型的對象(session中可含有多個對象)

四、存儲的大小：cookie：單個cookie保存的數據不能超過4kb；session大小沒有限制。

五、安全性：cookie：針對cookie所存在的攻擊：Cookie欺騙，Cookie截獲；session的安全性大於cookie。

　　　　　　緣由以下：（1）sessionID存儲在cookie中，若要攻破session首先要攻破cookie；

　　　　　　　　　　　（2）sessionID是要有人登陸，或者啓動session_start纔會有，因此攻破cookie也不必定能獲得sessionID；

　　　　　　　　　　　（3）第二次啓動session_start後，前一次的sessionID就是失效了，session過時後，sessionID也隨之失效。

　　　　　　　　　　　（4）sessionID是加密的

　　　　　　　　　　　（5）綜上所述，攻擊者必須在短期內攻破加密的sessionID，這很難。

六、應用場景：

cookie：（1）判斷用戶是否登錄過網站，以便下次登陸時可以實現自動登陸（或者記住密碼）。若是咱們刪除cookie，則每次登陸必須重新填寫登陸的相關信息。

　　　　（2）保存上次登陸的時間等信息。

　　　　（3）保存上次查看的頁面

　　　　（4）瀏覽計數

session：Session用於保存每一個用戶的專用信息，變量的值保存在服務器端，經過SessionID來區分不一樣的客戶。

　　（1）網上商城中的購物車

　　（2）保存用戶登陸信息

　　（3）將某些數據放入session中，供同一用戶的不一樣頁面使用

　　（4）防止用戶非法登陸

 七、缺點：cookie：（1）大小受限

　　　　　　　　（2）用戶能夠操做（禁用）cookie，使功能受限

　　　　　　　　（3）安全性較低

　　　　　　　　（4）有些狀態不可能保存在客戶端。

　　　　　　　　（5）每次訪問都要傳送cookie給服務器，浪費帶寬。

　　　　　　　　（6）cookie數據有路徑（path）的概念，能夠限制cookie只屬於某個路徑下。

 　　　　session：（1）Session保存的東西越多，就越佔用服務器內存，對於用戶在線人數較多的網站，服務器的內存壓力會比較大。

　　　　　　　　（2）依賴於cookie（sessionID保存在cookie），若是禁用cookie，則要使用URL重寫，不安全

　　　　　　　　（3）建立Session變量有很大的隨意性，可隨時調用，不須要開發者作精確地處理，因此，過分使用session變量將會致使代碼不可讀並且很差維護。

2、WebStorage

WebStorage的目的是克服由cookie所帶來的一些限制，當數據須要被嚴格控制在客戶端時，不須要持續的將數據發回服務器。

WebStorage兩個主要目標：（1）提供一種在cookie以外存儲會話數據的路徑。（2）提供一種存儲大量能夠跨會話存在的數據的機制。

HTML5的WebStorage提供了兩種API：localStorage（本地存儲）和sessionStorage（會話存儲）。

一、生命週期：localStorage:localStorage的生命週期是永久的，關閉頁面或瀏覽器以後localStorage中的數據也不會消失。localStorage除非主動刪除數據，不然數據永遠不會消失。

　　　　　　  sessionStorage的生命週期是在僅在當前會話下有效。sessionStorage引入了一個「瀏覽器窗口」的概念，sessionStorage是在同源的窗口中始終存在的數據。只要這個瀏覽器窗口沒有關閉，即便刷新頁面或者進入同源另外一個頁面，數據依然存在。可是sessionStorage在關閉了瀏覽器窗口後就會被銷燬。同時獨立的打開同一個窗口同一個頁面，sessionStorage也是不同的。

二、存儲大小：localStorage和sessionStorage的存儲數據大小通常都是：5MB

三、存儲位置：localStorage和sessionStorage都保存在客戶端，不與服務器進行交互通訊。

四、存儲內容類型：localStorage和sessionStorage只能存儲字符串類型，對於複雜的對象可使用ECMAScript提供的JSON對象的stringify和parse來處理

五、獲取方式：localStorage：window.localStorage;；sessionStorage：window.sessionStorage;。

六、應用場景：localStoragese：經常使用於長期登陸（+判斷用戶是否已登陸），適合長期保存在本地的數據。sessionStorage：敏感帳號一次性登陸；

WebStorage的優勢：

（1）存儲空間更大：cookie爲4KB，而WebStorage是5MB；

（2）節省網絡流量：WebStorage不會傳送到服務器，存儲在本地的數據能夠直接獲取，也不會像cookie同樣美詞請求都會傳送到服務器，因此減小了客戶端和服務器端的交互，節省了網絡流量；

（3）對於那種只須要在用戶瀏覽一組頁面期間保存而關閉瀏覽器後就能夠丟棄的數據，sessionStorage會很是方便；

（4）快速顯示：有的數據存儲在WebStorage上，再加上瀏覽器自己的緩存。獲取數據時能夠從本地獲取會比從服務器端獲取快得多，因此速度更快；

（5）安全性：WebStorage不會隨着HTTP header發送到服務器端，因此安全性相對於cookie來講比較高一些，不會擔憂截獲，可是仍然存在僞造問題；

（6）WebStorage提供了一些方法，數據操做比cookie方便；

　　　　setItem (key, value) ——  保存數據，以鍵值對的方式儲存信息。

      　　 getItem (key) ——  獲取數據，將鍵值傳入，便可獲取到對應的value值。

        　　removeItem (key) ——  刪除單個數據，根據鍵值移除對應的信息。

        　　clear () ——  刪除全部的數據

        　　key (index) —— 獲取某個索引的key

 

登錄信息用cookie好仍是localStorage好？

你的需求能夠拆成兩個部分：認證 和 鑑權
認證識別這個用戶的身份
鑑權肯定這個用戶訪問首頁以後是否須要跳轉到綁定支付頁面

cookie 天生就是最適合作認證，除了你提出的可否設置過時時間上的區別， cookie 和 localStorage 最大的區別是：每次 request 都會自動在 header 中帶上全部的 cookie。因此若是你爲了鑑權，設置不少 cookie ，還會引起一個問題就是，每次 request 的包都會很大。

個人解決方案很簡單：鑑權就應該交給後端去作。不管你多麼細心的在 client 中維護用戶權限標識，都須要確保一點：用戶的真實權限是否保持同步？因此你仍是須要向後端查詢用戶權限設置，幹嗎不簡單些：
用戶認證以後，後端鑑權，提示是否跳轉，或者乾脆在 header 頭中設置跳轉連接。

首先，是登陸信息：

登陸信息存在 cookie 中是一直以來的作法，並且實現的很好，不用考慮各類問題。
而 localStorage 是在這個 API 誕生以後，一些 JS 黨帶起來的另外一種實現方式。

使用 localStorage，你須要在每次請求的時候，都手動帶上這個信息，這大大增長了開發過程當中帶來的困難，很是麻煩，並且還要手動維護過時時間。
而使用 cookie 的話，只須要在後端的 Auth 模塊放個設置 header 的代碼便可，其餘徹底不用考慮。爲何：

• 用戶未登陸的狀況下，Auth 判斷沒有權限，設置個跳轉到登陸頁（或者是其餘邏輯，好比以訪客身份瀏覽之類的）
• 用戶登陸時：將帳號和密碼 POST 到 Auth 模塊後，Auth 設置一個 header，設置 Cookie 及過時時間
• 用戶登陸後，在 Cookie 的有效期內（設置了過時時間就是過時時間內，沒設置就是瀏覽器關閉前），任何請求都會自動帶上 cookie，徹底不用人工干預（fetch 請求除外，須要額外指定配置）
• 在用戶自動帶上 cookie 請求後，須要受權的請求必定會通過 Auth 模塊，判斷 cookie 是否有效（防止惡意無效的 cookie），若 cookie 無效，則設置 header 刪除 cookie（可選步驟），並將用戶重定向到登陸頁。若 cookie 有效，則設置 header，爲 cookie 續期（cookie 內容均可以徹底不變）。

Auth 模塊：
if (POST 方法請求登陸) { if (帳號密碼不正確) { return 重定向到登陸頁面，並提示錯誤 } 設置 cookie，並指定過時時間爲當前時間 +n 天 return Auth 模塊邏輯結束，進入其餘模塊邏輯 } if (沒有 cookie) { return 重定向到登陸頁面 } if (cookie 無效) { // 可選步驟：設置 cookie 過時時間爲 -1 （刪除 cookie） return 重定向到登陸頁面 } // 帶了有效的 cookie 設置 cookie 過時時間爲當前時間 +n 天（爲 cookie 續期） return Auth 模塊邏輯結束，進入其餘模塊邏輯

注意：只有請求 Auth 模塊纔會給 cookie 續期，其餘模塊不續。因此權限認證的模塊都統一到一塊兒了