我想經過將全部cookie移到本地存儲中來減小其加載時間,由於它們彷佛具備相同的功能。 除了明顯的兼容性問題之外,使用本地存儲替換cookie功能是否有任何利弊(特別是性能方面的優點)? html
好吧,本地存儲速度很大程度上取決於客戶端使用的瀏覽器以及操做系統。 Mac上的Chrome或Safari可能比PC上的Firefox快得多,尤爲是使用較新的API時。 與往常同樣,測試是您的朋友(我找不到任何基準)。 html5
我真的沒有看到Cookie與本地存儲的巨大差別。 另外,您應該更加擔憂兼容性問題:並非全部的瀏覽器都已經開始支持新的HTML5 API,所以cookie是提升速度和兼容性的最佳選擇。 web
Cookies和本地存儲有不一樣的用途。 Cookies主要用於讀取服務器端 ,本地存儲只能由客戶端讀取。 所以,問題是,在您的應用程序中,誰須要此數據-客戶端仍是服務器? 瀏覽器
若是它是您的客戶端(您的JavaScript),則必定要切換。 經過在每一個HTTP標頭中發送全部數據來浪費帶寬。 緩存
若是是您的服務器,則本地存儲不是那麼有用,由於您必須以某種方式(使用Ajax或隱藏的表單字段或其餘方式)轉發數據。 若是服務器僅須要每一個請求的所有數據的一小部分,則能夠這樣作。 安全
不管哪一種方式,您都但願將會話cookie保留爲cookie。 服務器
根據技術差別以及個人理解: cookie
除了做爲一種古老的數據保存方式以外,Cookie還爲您提供了4096個字節的限制(實際上爲4095 個字節),即每一個cookie的限制。 每一個域的本地存儲最大爲5MB - SO Question也提到了它 網絡
localStorage
是Storage
接口的實現。 它存儲沒有到期日期的數據,而且僅經過JavaScript或清除瀏覽器緩存/本地存儲的數據來清除-與cookie到期不一樣。 session
使用localStorage
,Web應用程序能夠在用戶的瀏覽器中本地存儲數據。 在HTML5以前,應用程序數據必須存儲在cookie中,幷包含在每一個服務器請求中。 大量數據能夠存儲在本地,而不會影響網站性能。 儘管localStorage
更現代,但這兩種技術都有其優缺點。
優勢
缺點
優勢
缺點
localStorage
用法與會話一的用法幾乎相同。 它們有不少精確的方法,所以從會話切換到localStorage
確實是小孩子的玩法。 可是,若是存儲的數據對於您的應用程序確實相當重要,則在localStorage
不可用的狀況下,您可能會使用cookie做爲備份。 若是要檢查瀏覽器對localStorage
支持,則只需運行如下簡單腳本便可:
/* * function body that test if storage is available * returns true if localStorage is available and false if it's not */ function lsTest(){ var test = 'test'; try { localStorage.setItem(test, test); localStorage.removeItem(test); return true; } catch(e) { return false; } } /* * execute Test and run our custom script */ if(lsTest()) { // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar window.localStorage.setItem(name, 1); console.log('localStorage where used'); // log } else { document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC"; console.log('Cookie where used'); // log }
有人注意到, 「安全(SSL)頁面上的localStorage值是隔離的」 ,請記住,若是您從「 http」安全協議轉換爲「 https」安全協議,則該cookie仍可訪問,則localStorage將不可用。 若是您使用安全協議,請務必注意這一點。
在JWT的上下文中 ,Stormpath寫了一篇至關有幫助的文章,概述了存儲它們的可能方法以及與每種方法有關的(缺點)優勢。
它還簡要概述了XSS和CSRF攻擊,以及如何應對它們。
我在下面附上了一些簡短的摘錄,以防他們的文章脫機/其站點出現故障。
問題:
Web存儲(localStorage / sessionStorage)可經過同一域上的JavaScript訪問。 這意味着您網站上運行的全部JavaScript均可以訪問Web存儲,所以,它很容易受到跨站點腳本(XSS)攻擊的攻擊。 簡而言之,XSS是攻擊者能夠注入將在您的頁面上運行的JavaScript的一種漏洞。 基本的XSS攻擊會嘗試經過表單輸入注入JavaScript,攻擊者會在其中輸入警報(「您被黑」); 轉換爲表單,以查看它是否由瀏覽器運行而且能夠被其餘用戶查看。
預防:
爲了防止XSS,常見的響應是對全部不受信任的數據進行轉義和編碼。 可是,這還遠沒有完整。 2015年,現代網絡應用使用託管在CDN或外部基礎架構上的JavaScript。 現代網絡應用程序包括用於A / B測試,渠道/市場分析和廣告的第三方JavaScript庫。 咱們使用Bower等軟件包管理器將其餘人的代碼導入咱們的應用程序。
若是隻破壞了您使用的一個腳本怎麼辦? 惡意JavaScript能夠嵌入到頁面中,而且Web存儲受到損害。 這些類型的XSS攻擊可能會致使全部人在不知情的狀況下訪問您站點的Web存儲。 這可能就是爲何許多組織建議不要在網絡存儲中存儲任何有價值的東西或信任任何信息的緣由。 這包括會話標識符和令牌。
做爲一種存儲機制,Web存儲在傳輸期間不會強制執行任何安全標準。 讀取並使用Web存儲的任何人都必須進行盡職調查,以確保他們始終經過HTTPS發送JWT,而不經過HTTP發送JWT。
問題:
與HttpOnly cookie標誌一塊兒使用時,cookie沒法經過JavaScript訪問,而且不受XSS的影響。 您還能夠設置安全cookie標誌,以確保僅經過HTTPS發送cookie。 這是過去曾利用Cookie存儲令牌或會話數據的主要緣由之一。 現代開發人員不肯使用Cookie,由於傳統上他們要求將狀態存儲在服務器上,從而破壞了RESTful最佳實踐。 若是將JWT存儲在cookie中,則cookie做爲一種存儲機制不須要在服務器上存儲狀態。 這是由於JWT封裝了服務器處理請求所需的全部內容。
可是,cookie容易受到其餘類型的攻擊:跨站點請求僞造(CSRF)。 CSRF攻擊是一種攻擊,當惡意網站,電子郵件或博客致使用戶的Web瀏覽器在當前已對其進行身份驗證的受信任站點上執行有害操做時,會發生這種攻擊。 這是對瀏覽器如何處理Cookie的一種利用。 Cookie只能發送到容許它的域。 默認狀況下,這是最初設置cookie的域。 不管您是在galaxies.com仍是hahagonnahackyou.com上,都會發送Cookie進行請求。
預防:
能夠經過使用同步令牌模式來防止CSRF。 這聽起來很複雜,可是全部現代Web框架都對此提供支持。
例如,AngularJS提供了一種解決方案來驗證cookie僅可被您的域訪問。 直接來自AngularJS文檔:
執行XHR請求時,$ http服務從cookie(默認狀況下爲XSRF-TOKEN)讀取令牌,並將其設置爲HTTP標頭(X-XSRF-TOKEN)。 因爲只有在您的域上運行的JavaScript才能讀取Cookie,所以能夠確保您的服務器XHR來自在您的域上運行的JavaScript。 經過包含
xsrfToken
JWT聲明,可使此CSRF保護成爲無狀態的:{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }利用Web應用程序框架的CSRF保護,cookie能夠堅固地存儲JWT。 經過檢查API中的HTTP Referer和Origin標頭,也能夠部分阻止CSRF。 CSRF攻擊將具備與您的應用程序無關的Referer和Origin頭。
完整的文章能夠在這裏找到: https : //stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/
關於令牌自己的結構,他們還提供了有關如何最佳設計和實現JWT的有用文章: https ://stormpath.com/blog/jwt-the-right-way/
本地存儲最多可存儲5mb的脫機數據,而會話也最多可存儲5mb的數據。 可是Cookie只能以文本格式存儲4kb數據。
LOCA1和Session以JSON格式存儲數據,所以易於解析。 可是Cookies數據是字符串格式。