Cookie/Session機制詳解

會話跟蹤是Web程序中經常使用技術，用來跟蹤用戶的整個會話。經常使用的會話跟蹤技術是cookie與session。cookie經過客戶端肯定記錄信息肯定用戶身份，session經過服務器端記錄信息肯定用戶身份。

三者的異同

特性	Cookie	localStorage	sessionStorage
數據的生命期	通常由服務器生成，可設置失效時間。若是在瀏覽器端生成Cookie，默認是關閉瀏覽器後失效	除非被清除，不然永久保存	僅在當前會話下有效，關閉頁面或瀏覽器後被清除
存放數據大小	4K左右	通常爲5MB
與服務器端通訊	每次都會攜帶在HTTP頭中，若是使用cookie保存過多數據會帶來性能問題	僅在客戶端（即瀏覽器）中保存，不參與和服務器的通訊
易用性	須要程序員本身封裝，源生的Cookie接口不友好	源生接口能夠接受，亦可再次封裝來對Object和Array有更好的支持

 

1.cookie機制

理論上，一個用戶的全部操做請求都應該屬於同一個會話，而另外一個用戶的全部請求操做則應該屬於另外一個會話。

而web應用程序是使用http協議傳輸數據的。http是無狀態的協議。一旦數據交換完畢，客戶端與服務端的鏈接就會關閉，再次交換數據須要從新創建鏈接。這意味着服務器沒法跟蹤會話。即永華A購買了一件商品放入購物車內，當再次購買商品時，服務器已經沒法判斷該購買行爲屬於用戶A仍是用戶B的會話了，要想跟蹤會話，必須引入一種機制。

1.1 什麼是cookie

因爲http是無狀態協議，服務器單從網絡鏈接上無從得知客戶身份，就給客戶端頒發一個通行證吧，每人一個，不管訪問什麼都必須攜帶本身的通行證。這樣服務器就能從通行證確認客戶身份了。這就是cookie的工做原理。

查看一個網站的cookie很簡單，在瀏覽器控制檯輸入alert(document.cookie)就能夠了。

1.2 記錄永華訪問次數

經過request.getCookie()獲取客戶端提交的全部Cookie（以Cookie[]數組形式返回），經過response.addCookie(Cookiecookie)向客戶端設置Cookie。

Cookie對象使用key-value屬性對的形式保存用戶狀態，一個Cookie對象保存一個屬性對，一個request或者response同時使用多個Cookie。

1.3 cookie不可跨域名

Cookie具備不可跨域名性。根據Cookie規範，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。Google也只能操做Google的Cookie，而不能操做Baidu的Cookie。須要注意的是，雖然網站images.google.com與網站www.google.com同屬於Google，可是域名不同，兩者一樣不能互相操做彼此的Cookie。注意：用戶登陸網站www.google.com以後會發現訪問images.google.com時登陸信息仍然有效，而普通的Cookie是作不到的。這是由於Google作了特殊處理。本章後面也會對Cookie作相似的處理。

1.4  Unicode編碼：保存中文

中文與英文字符不一樣，中文屬於Unicode字符，在內存中佔4個字符，而英文屬於ASCII字符，內存中只佔2個字節。Cookie中使用Unicode字符時須要對Unicode字符進行編碼，不然會亂碼。 

提示：Cookie中保存中文只能編碼。通常使用UTF-8編碼便可。不推薦使用GBK等中文編碼，由於瀏覽器不必定支持，並且JavaScript也不支持GBK編碼。

1.5  BASE64編碼：保存二進制圖片

Cookie不只可使用ASCII字符與Unicode字符，還可使用二進制數據。例如在Cookie中使用數字證書，提供安全度。使用二進制數據時也須要進行編碼。

%注意：本程序僅用於展現Cookie中能夠存儲二進制內容，並不實用。因爲瀏覽器每次請求服務器都會攜帶Cookie，所以Cookie內容不宜過多，不然影響速度。Cookie的內容應該少而精。

1.6  設置Cookie的全部屬性

先在瀏覽器中看一下cookie包含哪些內容：

除了name與value以外，Cookie還具備其餘幾個經常使用的屬性。每一個屬性對應一個getter方法與一個setter方法。Cookie類的全部屬性如表1.1所示。

表1.1  Cookie經常使用屬性

屬  性  名	描    述
String name	該Cookie的名稱。Cookie一旦建立，名稱便不可更改
Object value	該Cookie的值。若是值爲Unicode字符，須要爲字符編碼。若是值爲二進制數據，則須要使用BASE64編碼
int maxAge	該Cookie失效的時間，單位秒。若是爲正數，則該Cookie在maxAge秒以後失效。若是爲負數，該Cookie爲臨時Cookie，關閉瀏覽器即失效，瀏覽器也不會以任何形式保存該Cookie。若是爲0，表示刪除該Cookie。默認爲–1
boolean secure	該Cookie是否僅被使用安全協議傳輸。安全協議。安全協議有HTTPS，SSL等，在網絡上傳輸數據以前先將數據加密。默認爲false
String path	該Cookie的使用路徑。若是設置爲「/sessionWeb/」，則只有contextPath爲「/sessionWeb」的程序能夠訪問該Cookie。若是設置爲「/」，則本域名下contextPath均可以訪問該Cookie。注意最後一個字符必須爲「/」
String domain	能夠訪問該Cookie的域名。若是設置爲「.google.com」，則全部以「google.com」結尾的域名均可以訪問該Cookie。注意第一個字符必須爲「.」
String comment	該Cookie的用處說明。瀏覽器顯示Cookie信息的時候顯示該說明
int version	該Cookie使用的版本號。0表示遵循Netscape的Cookie規範，1表示遵循W3C的RFC 2109規範

設置一個有效期爲 7 天的 cookie：

$.cookie('the_cookie', 'the_value', {expires: 7});

注：$.cookie 第三個參數是一個對象，除了能夠設置有效期（expires: 7），還能夠設置有效路徑（path: '/'）、有效域（domain: 'jquery.com'）及安全性（secure: true）。

讀取 cookie：

$.cookie('the_cookie'); 

注：若是沒有該 cookie，返回 null。

刪除 cookie：

$.cookie('the_cookie', null);

咱們只須要給須要刪除的 cookie 設置爲 null，就能夠刪除該 cookie。

1.7  Cookie的有效期

Cookie的maxAge決定着Cookie的有效期，單位爲秒（Second）。Cookie中經過getMaxAge()方法與setMaxAge(int maxAge)方法來讀寫maxAge屬性。

若是maxAge屬性爲正數，則表示該Cookie會在maxAge秒以後自動失效。瀏覽器會將maxAge爲正數的Cookie持久化，即寫到對應的Cookie文件中。不管客戶關閉了瀏覽器仍是電腦，只要還在maxAge秒以前，登陸網站時該Cookie仍然有效。下面代碼中的Cookie信息將永遠有效。

 

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(Integer.MAX_VALUE);           // 設置生命週期爲MAX_VALUE

response.addCookie(cookie);                    // 輸出到客戶端

 

若是maxAge爲負數，則表示該Cookie僅在本瀏覽器窗口以及本窗口打開的子窗口內有效，關閉窗口後該Cookie即失效。maxAge爲負數的Cookie，爲臨時性Cookie，不會被持久化，不會被寫到Cookie文件中。Cookie信息保存在瀏覽器內存中，所以關閉瀏覽器該Cookie就消失了。Cookie默認的maxAge值爲–1。

若是maxAge爲0，則表示刪除該Cookie。Cookie機制沒有提供刪除Cookie的方法，所以經過設置該Cookie即時失效實現刪除Cookie的效果。失效的Cookie會被瀏覽器從Cookie文件或者內存中刪除，

 

例如：

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(0);                          // 設置生命週期爲0，不能爲負數

response.addCookie(cookie);                    // 必須執行這一句

 

response對象提供的Cookie操做方法只有一個添加操做add(Cookie cookie)。

要想修改Cookie只能使用一個同名的Cookie來覆蓋原來的Cookie，達到修改的目的。刪除時只須要把maxAge修改成0便可。

 

注意：從客戶端讀取Cookie時，包括maxAge在內的其餘屬性都是不可讀的，也不會被提交。瀏覽器提交Cookie時只會提交name與value屬性。maxAge屬性只被瀏覽器用來判斷Cookie是否過時。

 

1.8  Cookie的修改、刪除

Cookie並不提供修改、刪除操做。若是要修改某個Cookie，只須要新建一個同名的Cookie，添加到response中覆蓋原來的Cookie。

若是要刪除某個Cookie，只須要新建一個同名的Cookie，並將maxAge設置爲0，並添加到response中覆蓋原來的Cookie。注意是0而不是負數。負數表明其餘的意義。讀者能夠經過上例的程序進行驗證，設置不一樣的屬性。

 

注意：修改、刪除Cookie時，新建的Cookie除value、maxAge以外的全部屬性，例如name、path、domain等，都要與原Cookie徹底同樣。不然，瀏覽器將視爲兩個不一樣的Cookie不予覆蓋，致使修改、刪除失敗。

 

1.9  Cookie的域名

Cookie是不可跨域名的。域名www.google.com頒發的Cookie不會被提交到域名www.baidu.com去。這是由Cookie的隱私安全機制決定的。隱私安全機制可以禁止網站非法獲取其餘網站的Cookie。

正常狀況下，同一個一級域名下的兩個二級域名如www.helloweenvsfei.com和images.helloweenvsfei.com也不能交互使用Cookie，由於兩者的域名並不嚴格相同。若是想全部helloweenvsfei.com名下的二級域名均可以使用該Cookie，須要設置Cookie的domain參數，例如：

Cookie cookie = new Cookie("time","20080808"); // 新建Cookie

cookie.setDomain(".helloweenvsfei.com");           // 設置域名

cookie.setPath("/");                              // 設置路徑

cookie.setMaxAge(Integer.MAX_VALUE);               // 設置有效期

response.addCookie(cookie);                       // 輸出到客戶端

注意：domain參數必須以點(".")開始。另外，name相同但domain不一樣的兩個Cookie是兩個不一樣的Cookie。若是想要兩個域名徹底不一樣的網站共有Cookie，能夠生成兩個Cookie，domain屬性分別爲兩個域名，輸出到客戶端。

 

1.10  Cookie的路徑

domain屬性決定運行訪問Cookie的域名，而path屬性決定容許訪問Cookie的路徑（ContextPath）。例如，若是隻容許/sessionWeb/下的程序使用Cookie，能夠這麼寫：

Cookie cookie = new Cookie("time","20080808");     // 新建Cookie

cookie.setPath("/session/");                          // 設置路徑

response.addCookie(cookie);                           // 輸出到客戶端

設置爲「/」時容許全部路徑使用Cookie。path屬性須要使用符號「/」結尾。name相同但domain相同的兩個Cookie也是兩個不一樣的Cookie。

 

注意：頁面只能獲取它屬於的Path的Cookie。例如/session/test/a.jsp不能獲取到路徑爲/session/abc/的Cookie。使用時必定要注意。

 

1.11  Cookie的安全屬性

HTTP協議不只是無狀態的，並且是不安全的。使用HTTP協議的數據不通過任何加密就直接在網絡上傳播，有被截獲的可能。使用HTTP協議傳輸很機密的內容是一種隱患。若是不但願Cookie在HTTP等非安全協議中傳輸，能夠設置Cookie的secure屬性爲true。瀏覽器只會在HTTPS和SSL等安全協議中傳輸此類Cookie。下面的代碼設置secure屬性爲true：

 

Cookie cookie = new Cookie("time", "20080808"); // 新建Cookie

cookie.setSecure(true);                           // 設置安全屬性

response.addCookie(cookie);                        // 輸出到客戶端

 

提示：secure屬性並不能對Cookie內容加密，於是不能保證絕對的安全性。若是須要高安全性，須要在程序中對Cookie內容加密、解密，以防泄密。

 

1.12  JavaScript操做Cookie

Cookie是保存在瀏覽器端的，所以瀏覽器具備操做Cookie的先決條件。瀏覽器可使用腳本程序如JavaScript或者VBScript等操做Cookie。這裏以JavaScript爲例介紹經常使用的Cookie操做。例以下面的代碼會輸出本頁面全部的Cookie。

<script>document.write(document.cookie);</script>

因爲JavaScript可以任意地讀寫Cookie，有些好事者便想使用JavaScript程序去窺探用戶在其餘網站的Cookie。不過這是徒勞的，W3C組織早就意識到JavaScript對Cookie的讀寫所帶來的安全隱患並加以防備了，W3C標準的瀏覽器會阻止JavaScript讀寫任何不屬於本身網站的Cookie。換句話說，A網站的JavaScript程序讀寫B網站的Cookie不會有任何結果。

 

1.13  永久登陸

若是用戶是在本身家的電腦上上網，登陸時就能夠記住他的登陸信息，下次訪問時不須要再次登陸，直接訪問便可。實現方法是把登陸信息如帳號、密碼等保存在Cookie中，並控制Cookie的有效期，下次訪問時再驗證Cookie中的登陸信息便可。

保存登陸信息有多種方案。最直接的是把用戶名與密碼都保持到Cookie中，下次訪問時檢查Cookie中的用戶名與密碼，與數據庫比較。這是一種比較危險的選擇，通常不把密碼等重要信息保存到Cookie中。

還有一種方案是把密碼加密後保存到Cookie中，下次訪問時解密並與數據庫比較。這種方案略微安全一些。若是不但願保存密碼，還能夠把登陸的時間戳保存到Cookie與數據庫中，到時只驗證用戶名與登陸時間戳就能夠了。

這幾種方案驗證帳號時都要查詢數據庫。

本例將採用另外一種方案，只在登陸時查詢一次數據庫，之後訪問驗證登陸信息時再也不查詢數據庫。實現方式是把帳號按照必定的規則加密後，連同帳號一塊保存到Cookie中。下次訪問時只須要判斷帳號的加密規則是否正確便可。

 

2. Session機制

除了使用Cookie，Web應用程序中還常用Session來記錄客戶端狀態。Session是服務器端使用的一種記錄客戶端狀態的機制，使用上比Cookie簡單一些，相應的也增長了服務器的存儲壓力。

2.1  什麼是Session

Session是另外一種記錄客戶狀態的機制，不一樣的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session。客戶端瀏覽器再次訪問時只須要從該Session中查找該客戶的狀態就能夠了。

若是說Cookie機制是經過檢查客戶身上的「通行證」來肯定客戶身份的話，那麼Session機制就是經過檢查服務器上的「客戶明細表」來確認客戶身份。Session至關於程序在服務器上創建的一份客戶檔案，客戶來訪的時候只須要查詢客戶檔案表就能夠了。

2.2  實現用戶登陸

Session對應的類爲javax.servlet.http.HttpSession類。每一個來訪者對應一個Session對象，全部該客戶的狀態信息都保存在這個Session對象裏。Session對象是在客戶端第一次請求服務器的時候建立的。Session也是一種key-value的屬性對，經過getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法讀寫客戶狀態信息。Servlet裏經過request.getSession()方法獲取該客戶的Session，

例如：

HttpSession session = request.getSession();       // 獲取Session對象

session.setAttribute("loginTime", new Date());     // 設置Session中的屬性

   

out.println("登陸時間爲：" +(Date)session.getAttribute("loginTime"));      // 獲取Session屬性

request還可使用getSession(boolean create)來獲取Session。區別是若是該客戶的Session不存在，request.getSession()方法會返回null，而getSession(true)會先建立Session再將Session返回。

Servlet中必須使用request來編程式獲取HttpSession對象，而JSP中內置了Session隱藏對象，能夠直接使用。若是使用聲明瞭<%@page session="false" %>，則Session隱藏對象不可用。下面的例子使用Session記錄客戶帳號信息。

2.3  Session的生命週期

Session保存在服務器端。爲了得到更高的存取速度，服務器通常把Session放在內存裏。每一個用戶都會有一個獨立的Session。若是Session內容過於複雜，當大量客戶訪問服務器時可能會致使內存溢出。所以，Session裏的信息應該儘可能精簡。

Session在用戶第一次訪問服務器的時候自動建立。須要注意只有訪問JSP、Servlet等程序時纔會建立Session，只訪問HTML、IMAGE等靜態資源並不會建立Session。若是還沒有生成Session，也可使用request.getSession(true)強制生成Session。

Session生成後，只要用戶繼續訪問，服務器就會更新Session的最後訪問時間，並維護該Session。用戶每訪問服務器一次，不管是否讀寫Session，服務器都認爲該用戶的Session「活躍（active）」了一次。

 

1.2.4  Session的有效期

因爲會有愈來愈多的用戶訪問服務器，所以Session也會愈來愈多。爲防止內存溢出，服務器會把長時間內沒有活躍的Session從內存刪除。這個時間就是Session的超時時間。若是超過了超時時間沒訪問過服務器，Session就自動失效了。

Session的超時時間爲maxInactiveInterval屬性，能夠經過對應的getMaxInactiveInterval()獲取，經過setMaxInactiveInterval(longinterval)修改。

Session的超時時間也能夠在web.xml中修改。另外，經過調用Session的invalidate()方法可使Session失效。

 

2.5  Session的經常使用方法

Session中包括各類方法，使用起來要比Cookie方便得多。Session的經常使用方法如表1.2所示。

表1.2  HttpSession的經常使用方法

方  法  名	描    述
void setAttribute(String attribute, Object value)	設置Session屬性。value參數能夠爲任何Java Object。一般爲Java Bean。value信息不宜過大
String getAttribute(String attribute)	返回Session屬性
Enumeration getAttributeNames()	返回Session中存在的屬性名
void removeAttribute(String attribute)	移除Session屬性
String getId()	返回Session的ID。該ID由服務器自動建立，不會重複
long getCreationTime()	返回Session的建立日期。返回類型爲long，常被轉化爲Date類型，例如：Date createTime = new Date(session.get CreationTime())
long getLastAccessedTime()	返回Session的最後活躍時間。返回類型爲long
int getMaxInactiveInterval()	返回Session的超時時間。單位爲秒。超過該時間沒有訪問，服務器認爲該Session失效
void setMaxInactiveInterval(int second)	設置Session的超時時間。單位爲秒
void putValue(String attribute, Object value)	不推薦的方法。已經被setAttribute(String attribute, Object Value)替代
Object getValue(String attribute)	不被推薦的方法。已經被getAttribute(String attr)替代
boolean isNew()	返回該Session是不是新建立的
void invalidate()	使該Session失效

Tomcat中Session的默認超時時間爲20分鐘。經過setMaxInactiveInterval(int seconds)修改超時時間。能夠修改web.xml改變Session的默認超時時間。例如修改成60分鐘：

<session-config>

   <session-timeout>60</session-timeout>      <!-- 單位：分鐘 -->

</session-config>

 

注意：<session-timeout>參數的單位爲分鐘，而setMaxInactiveInterval(int s)單位爲秒。

 

2.6  Session對瀏覽器的要求

雖然Session保存在服務器，對客戶端是透明的，它的正常運行仍然須要客戶端瀏覽器的支持。這是由於Session須要使用Cookie做爲識別標誌。HTTP協議是無狀態的，Session不能依據HTTP鏈接來判斷是否爲同一客戶，所以服務器向客戶端瀏覽器發送一個名爲JSESSIONID的Cookie，它的值爲該Session的id（也就是HttpSession.getId()的返回值）。Session依據該Cookie來識別是否爲同一用戶。

該Cookie爲服務器自動生成的，它的maxAge屬性通常爲–1，表示僅當前瀏覽器內有效，而且各瀏覽器窗口間不共享，關閉瀏覽器就會失效。

所以同一機器的兩個瀏覽器窗口訪問服務器時，會生成兩個不一樣的Session。可是由瀏覽器窗口內的連接、腳本等打開的新窗口（也就是說不是雙擊桌面瀏覽器圖標等打開的窗口）除外。這類子窗口會共享父窗口的Cookie，所以會共享一個Session。

 

注意：新開的瀏覽器窗口會生成新的Session，但子窗口除外。子窗口會共用父窗口的Session。例如，在連接上右擊，在彈出的快捷菜單中選擇「在新窗口中打開」時，子窗口即可以訪問父窗口的Session。

若是客戶端瀏覽器將Cookie功能禁用，或者不支持Cookie怎麼辦？例如，絕大多數的手機瀏覽器都不支持Cookie。Java Web提供了另外一種解決方案：URL地址重寫。

 

2.7  URL地址重寫

URL地址重寫是對客戶端不支持Cookie的解決方案。URL地址重寫的原理是將該用戶Session的id信息重寫到URL地址中。服務器可以解析重寫後的URL獲取Session的id。這樣即便客戶端不支持Cookie，也可使用Session來記錄用戶狀態。HttpServletResponse類提供了encodeURL(Stringurl)實現URL地址重寫，例如：

<td>

    <a href="<%=response.encodeURL("index.jsp?c=1&wd=Java") %>"> 
    Homepage</a>

</td>

該方法會自動判斷客戶端是否支持Cookie。若是客戶端支持Cookie，會將URL原封不動地輸出來。若是客戶端不支持Cookie，則會將用戶Session的id重寫到URL中。重寫後的輸出多是這樣的：

<td>

    <ahref="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=
    1&wd=Java">Homepage</a>

</td>

即在文件名的後面，在URL參數的前面添加了字符串「;jsessionid=XXX」。其中XXX爲Session的id。分析一下能夠知道，增添的jsessionid字符串既不會影響請求的文件名，也不會影響提交的地址欄參數。用戶單擊這個連接的時候會把Session的id經過URL提交到服務器上，服務器經過解析URL地址得到Session的id。

若是是頁面重定向（Redirection），URL地址重寫能夠這樣寫：

<%

    if(「administrator」.equals(userName))

    {

       response.sendRedirect(response.encodeRedirectURL(「administrator.jsp」));

        return;

    }

%>

效果跟response.encodeURL(String url)是同樣的：若是客戶端支持Cookie，生成原URL地址，若是不支持Cookie，傳回重寫後的帶有jsessionid字符串的地址。

對於WAP程序，因爲大部分的手機瀏覽器都不支持Cookie，WAP程序都會採用URL地址重寫來跟蹤用戶會話。好比用友集團的移動商街等。

 

注意：TOMCAT判斷客戶端瀏覽器是否支持Cookie的依據是請求中是否含有Cookie。儘管客戶端可能會支持Cookie，可是因爲第一次請求時不會攜帶任何Cookie（由於並沒有任何Cookie能夠攜帶），URL地址重寫後的地址中仍然會帶有jsessionid。當第二次訪問時服務器已經在瀏覽器中寫入Cookie了，所以URL地址重寫後的地址中就不會帶有jsessionid了。

 

2.8  Session中禁止使用Cookie

既然WAP上大部分的客戶瀏覽器都不支持Cookie，索性禁止Session使用Cookie，統一使用URL地址重寫會更好一些。Java Web規範支持經過配置的方式禁用Cookie。下面舉例說一下怎樣經過配置禁止使用Cookie。

打開項目sessionWeb的WebRoot目錄下的META-INF文件夾（跟WEB-INF文件夾同級，若是沒有則建立），打開context.xml（若是沒有則建立），編輯內容以下：

代碼1.11 /META-INF/context.xml

<?xml version='1.0' encoding='UTF-8'?>

<Context path="/sessionWeb"cookies="false">

</Context>

 

或者修改Tomcat全局的conf/context.xml，修改內容以下：

代碼1.12  context.xml

<!-- The contents of this file will be loaded for eachweb application -->

<Context cookies="false">

    <!-- ... 中間代碼略 -->

</Context>

部署後TOMCAT便不會自動生成名JSESSIONID的Cookie，Session也不會以Cookie爲識別標誌，而僅僅以重寫後的URL地址爲識別標誌了。 

注意：該配置只是禁止Session使用Cookie做爲識別標誌，並不能阻止其餘的Cookie讀寫。也就是說服務器不會自動維護名爲JSESSIONID的Cookie了，可是程序中仍然能夠讀寫其餘的Cookie。

應用場景

有了對上面這些差異的直觀理解，咱們就能夠討論三者的應用場景了。

由於考慮到每一個 HTTP 請求都會帶着 Cookie 的信息，因此 Cookie 固然是能精簡就精簡啦，比較經常使用的一個應用場景就是判斷用戶是否登陸。針對登陸過的用戶，服務器端會在他登陸時往 Cookie 中插入一段加密過的惟一辨識單一用戶的辨識碼，下次只要讀取這個值就能夠判斷當前用戶是否登陸啦。曾經還使用 Cookie 來保存用戶在電商網站的購物車信息，現在有了 localStorage，彷佛在這個方面也能夠給 Cookie 放個假了~

而另外一方面 localStorage 接替了 Cookie 管理購物車的工做，同時也能勝任其餘一些工做。好比HTML5遊戲一般會產生一些本地數據，localStorage 也是很是適用的。若是遇到一些內容特別多的表單，爲了優化用戶體驗，咱們可能要把表單頁面拆分紅多個子頁面，而後按步驟引導用戶填寫。這時候 sessionStorage 的做用就發揮出來了。

安全性的考慮

須要注意的是，不是什麼數據都適合放在 Cookie、localStorage 和 sessionStorage 中的。使用它們的時候，須要時刻注意是否有代碼存在 XSS 注入的風險。由於只要打開控制檯，你就隨意修改它們的值，也就是說若是你的網站中有 XSS 的風險，它們就能對你的 localStorage 肆意妄爲。因此千萬不要用它們存儲你係統中的敏感數據。