理解Cookie和Session機制

簡述

Cookie經過在客戶端記錄信息肯定用戶身份，Session經過在服務器端記錄信息肯定用戶身份。

Cookie機制

Cookie技術是客戶端的解決方案，Cookie就是由服務器發給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，而後客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息。

具體過程

1. 當用戶使用瀏覽器訪問一個支持Cookie的網站的時候，用戶會提供包括用戶名在內的我的信息而且提交至服務器。
2. 服務器在向客戶端回傳相應的超文本的同時也會發回這些我的信息，固然這些信息並非存放在HTTP響應體（Response Body）中的，而是存放於HTTP響應頭（Response Header）。
3. 當客戶端瀏覽器接收到來自服務器的響應以後，瀏覽器會將這些信息存放在一個統一的位置，對於Windows操做系統而言，咱們能夠從： [系統盤]:\Documents and Settings[用戶名]\Cookies目錄中找到存儲的Cookie。
4. 自此，客戶端再向服務器發送請求的時候，都會把相應的Cookie再次發回至服務器。Cookie信息則存放在HTTP請求頭（Request Header）了。

有了Cookie這樣的技術實現，服務器在接收到來自客戶端瀏覽器的請求以後，就可以經過分析存放於請求頭的Cookie獲得客戶端特有的信息，從而動態生成與該客戶端相對應的內容。一般，咱們能夠從不少網站的登陸界面中看到「請記住我」這樣的選項，若是你勾選了它以後再登陸，那麼在下一次訪問該網站的時候就不須要進行重複而繁瑣的登陸動做了，而這個功能就是經過Cookie實現的。

在程序中，會話跟蹤是很重要的事情。理論上，一個用戶的全部請求操做都應該屬於同一個會話，而另外一個用戶的全部請求操做則應該屬於另外一個會話，兩者不能混淆。例如，用戶A在超市購買的任何商品都應該放在A的購物車內，不管是用戶A什麼時間購買的，這都是屬於同一個會話的，不能放入用戶B或用戶C的購物車內，這不屬於同一個會話。

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

Cookie就是這樣的一種機制。它能夠彌補HTTP協議無狀態的不足。在Session出現以前，基本上全部的網站都採用Cookie來跟蹤會話。

若是你把Cookies當作爲http協議的一個擴展的話，理解起來就容易的多了，其實本質上cookies就是http的一個擴展。有兩個http頭部是專門負責設置以及發送cookie的,它們分別是Set-Cookie以及Cookie。當服務器返回給客戶端一個http響應信息時，其中若是包含Set-Cookie這個頭部時，意思就是指示客戶端創建一個cookie，而且在後續的http請求中自動發送這個cookie到服務器端，直到這個cookie過時。若是cookie的生存時間是整個會話期間的話，那麼瀏覽器會將cookie保存在內存中，瀏覽器關閉時就會自動清除這個cookie。另一種狀況就是保存在客戶端的硬盤中，瀏覽器關閉的話，該cookie也不會被清除，下次打開瀏覽器訪問對應網站時，這個cookie就會自動再次發送到服務器端。一個cookie的設置以及發送過程分爲如下四步：

客戶端發送一個http請求到服務器端 服務器端發送一個http響應到客戶端，其中包含Set-Cookie頭部 客戶端發送一個http請求到服務器端，其中包含Cookie頭部 服務器端發送一個http響應到客戶端

這個通信過程也能夠用如下下示意圖來描述：

在客戶端的第二次請求中包含的Cookie頭部中，提供給了服務器端能夠用來惟一標識客戶端身份的信息。這時，服務器端也就能夠判斷客戶端是否啓用了cookies。儘管，用戶可能在和應用程序交互的過程當中忽然禁用cookies的使用，可是，這個狀況基本是不太可能發生的，因此能夠不加以考慮，這在實踐中也被證實是對的。

除了cookies,客戶端還能夠將發送給服務器的數據包含在請求的url中，好比請求的參數或者請求的路徑中。 咱們來看一個常規的http get 請求例子：

GET /index.php?foo=bar HTTP/1.1 Host: example.org

另一種客戶端傳遞數據到服務器端的方式是將數據包含在http請求的內容區域內。 這種方式須要請求的類型是POST的，看下面一個例子：

POST /index.php HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Content-Length: 7

foo=bar

另一種客戶端傳遞數據到服務器端的方式是將數據包含在http請求的內容區域內。 這種方式須要請求的類型是POST的，看下面一個例子：

POST /index.php HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Content-Length: 7

foo=bar

在一個請求中，能夠同時包含這兩種形式的數據：

POST /index.php?myget=foo HTTP/1.1 Host: example.orgContent-Type: application/x-www-form-urlencoded Content-Length: 11

mypost=bar

這兩種傳遞數據的方式，比起用cookies來傳遞數據更穩定，由於cookie可能被禁用，可是以GET以及POST方式傳遞數據時，不存在這種狀況。咱們能夠將PHPSESSID包含在http請求的url中，就像下面的例子同樣：

GET /index.php?PHPSESSID=12345 HTTP/1.1 Host: example.org

什麼是Cookie

Cookie意爲「甜餅」，是由W3C組織提出，最先由Netscape社區發展的一種機制。目前Cookie已經成爲標準，全部的主流瀏覽器如IE、Netscape、Firefox、Opera等都支持Cookie。

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

Cookie其實是一小段的文本信息。客戶端請求服務器，若是服務器須要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還能夠根據須要修改Cookie的內容。

查看某個網站頒發的Cookie很簡單。在 Console控制欄 輸入javascript:alert (document. cookie)就能夠了（須要有網才能查看）。JavaScript腳本會彈出一個對話框顯示本網站頒發的全部Cookie的內容，如圖所示。

上圖中彈出的對話框中顯示的爲Baidu網站的Cookie。其中第一行BAIDUID記錄的就是筆者的身份helloweenvsfei，只是Baidu使用特殊的方法將Cookie信息加密了。

注意：Cookie功能須要瀏覽器的支持。若是瀏覽器不支持Cookie（如大部分手機中的瀏覽器）或者把Cookie禁用了，Cookie功能就會失效。不一樣的瀏覽器採用不一樣的方式保存Cookie。IE瀏覽器會在「C:\Documents and Settings\你的用戶名\Cookies」文件夾下以文本文件形式保存，一個文本文件保存一個Cookie。

記錄用戶訪問次數

Java中把Cookie封裝成了javax.servlet.http.Cookie類。每一個Cookie都是該Cookie類的對象。服務器經過操做Cookie類對象對客戶端Cookie進行操做。經過request.getCookie()獲取客戶端提交的全部Cookie（以Cookie[]數組形式返回），經過response.addCookie(Cookie cookie)向客戶端設置Cookie。

Cookie對象使用key-value屬性對的形式保存用戶狀態，一個Cookie對象保存一個屬性對，一個request或者response同時使用多個Cookie。由於Cookie類位於包javax.servlet.http.*下面，因此JSP中不須要import該類。

Cookie的不可跨域名性

不少網站都會使用Cookie。例如，Google會向客戶端頒發Cookie，Baidu也會向客戶端頒發Cookie。那瀏覽器訪問Google會不會也攜帶上Baidu頒發的Cookie呢？或者Google能不能修改Baidu頒發的Cookie呢？

結果是否認的。Cookie具備不可跨域名性。根據Cookie規範，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。Google也只能操做Google的Cookie，而不能操做Baidu的Cookie。

Cookie在客戶端是由瀏覽器來管理的。瀏覽器可以保證Google只會操做Google的Cookie而不會操做Baidu的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網站是否能操做另外一個網站Cookie的依據是域名。Google與Baidu的域名不同，所以Google不能操做Baidu的Cookie。

須要注意的是，雖然網站images.google.com與網站www.google.com同屬於Google，可是域名不同，兩者一樣不能互相操做彼此的Cookie。

注意：用戶登陸網站www.google.com以後會發現訪問images.google.com時登陸信息仍然有效，而普通的Cookie是作不到的。這是由於Google作了特殊處理。本章後面也會對Cookie作相似的處理。

Unicode編碼：保存中文

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

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

BASE64編碼：保存二進制圖片

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

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

設置Cookie的全部屬性

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

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

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是否過時。

Cookie的修改、刪除

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

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

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); // 輸出到客戶端

讀者能夠修改本機C:\WINDOWS\system32\drivers\etc下的hosts文件來配置多個臨時域名，而後使用setCookie.jsp程序來設置跨域名Cookie驗證domain屬性。

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

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. domain表示的是cookie所在的域，默認爲請求的地址，如網址爲www.test.com/test/test.aspx，那麼domain默認爲www.test.com。而跨域訪問，如域A爲t1.test.com，域B爲t2.test.com，那麼在域A生產一個令域A和域B都能訪問的cookie就要將該cookie的domain設置爲.test.com；若是要在域A生產一個令域A不能訪問而域B能訪問的cookie就要將該cookie的domain設置爲t2.test.com。

2. path表示cookie所在的目錄，默認爲/，就是根目錄。在同一個服務器上有目錄以下：/test/,/test/cd/,/test/dd/，現設一個cookie1的path爲/test/，cookie2的path爲/test/cd/，那麼test下的全部頁面均可以訪問到cookie1，而/test/和/test/dd/的子頁面不能訪問cookie2。這是由於cookie能讓其path路徑下的頁面訪問。

3. 瀏覽器會將domain和path都相同的cookie保存在一個文件裏，cookie間用*隔開。

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內容加密、解密，以防泄密。

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不會有任何結果。

案例：永久登陸

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

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

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

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

本例將採用另外一種方案，只在登陸時查詢一次數據庫，之後訪問驗證登陸信息時再也不查詢數據庫。實現方式是把帳號按照必定的規則加密後，連同帳號一塊保存到Cookie中。下次訪問時只須要判斷帳號的加密規則是否正確便可。本例把帳號保存到名爲account的Cookie中，把帳號連同密鑰用MD1算法加密後保存到名爲ssid的Cookie中。驗證時驗證Cookie中的帳號與密鑰加密後是否與Cookie中的ssid相等。相關代碼以下： loginCookie.jsp：

<%@ page language="java" pageEncoding="UTF-8" isErrorPage="false" %>
<%!                                                  // JSP方法
    private static final String KEY =":cookie@helloweenvsfei.com"; // 密鑰 
 
    public final static String calcMD1(String ss) { // MD1 加密算法
       String s = ss == null ? "" : ss; // 若爲null返回空
       char hexDigits[] = { '0','1', '2', '3', '4', '1', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' }; // 字典
       try {
           byte[] strTemp = s.getBytes();                          // 獲取字節
           MessageDigestmdTemp = MessageDigest.getInstance("MD1"); // 獲取MD1
           mdTemp.update(strTemp);                                // 更新數據
           byte[] md =mdTemp.digest();                        // 加密
           int j =md.length;                                 // 加密後的長度
           char str[] = new char[j * 2];                       // 新字符串數組
           int k =0;                                         // 計數器k
           for (int i = 0; i< j; i++) {                       // 循環輸出
               byte byte0 = md[i];
               str[k++] = hexDigits[byte0 >>> 4 & 0xf];
               str[k++] = hexDigits[byte0 & 0xf];
           }
           return new String(str);                             // 加密後字符串
       } catch (Exception e){return null; }
    }
%>
<%
   request.setCharacterEncoding("UTF-8");          // 設置request編碼
   response.setCharacterEncoding("UTF-8");        // 設置response編碼
 
   String action =request.getParameter("action"); // 獲取action參數
 
   if("login".equals(action)) {                       // 若是爲login動做
        String account =request.getParameter("account"); // 獲取account參數
        String password =request.getParameter("password"); // 獲取password參數
        int timeout = new Integer(request.getParameter("timeout")); // 獲取timeout參數
 
        String ssid =calcMD1(account + KEY); // 把帳號、密鑰使用MD1加密後保存
 
        Cookie accountCookie = new Cookie("account", account); // 新建Cookie
        accountCookie.setMaxAge(timeout);              // 設置有效期
 
        Cookie ssidCookie =new Cookie("ssid", ssid);   // 新建Cookie
       ssidCookie.setMaxAge(timeout);                 // 設置有效期
 
       response.addCookie(accountCookie);             // 輸出到客戶端
       response.addCookie(ssidCookie);            // 輸出到客戶端
 
       // 從新請求本頁面，參數中帶有時間戳，禁止瀏覽器緩存頁面內容
       response.sendRedirect(request.getRequestURI() + "?" + System.currentTimeMillis());
       return;
    } else if("logout".equals(action)) {                  // 若是爲logout動做
       CookieaccountCookie = new Cookie("account", ""); // 新建Cookie，內容爲空
       accountCookie.setMaxAge(0); // 設置有效期爲0，刪除
 
       Cookie ssidCookie =new Cookie("ssid", ""); // 新建Cookie，內容爲空
       ssidCookie.setMaxAge(0);                   // 設置有效期爲0，刪除
       response.addCookie(accountCookie);         // 輸出到客戶端
       response.addCookie(ssidCookie);         // 輸出到客戶端
       // 從新請求本頁面，參數中帶有時間戳，禁止瀏覽器緩存頁面內容
       response.sendRedirect(request.getRequestURI() + "?" + System.currentTimeMillis());
       return;
    }
    boolean login = false;                        // 是否登陸
    String account = null;                        // 帳號
    String ssid = null;                           // SSID標識
 
    if(request.getCookies() !=null) {               // 若是Cookie不爲空
        for(Cookie cookie : request.getCookies()) {  // 遍歷Cookie
           if(cookie.getName().equals("account"))  // 若是Cookie名爲 account
               account = cookie.getValue();       // 保存account內容
           if(cookie.getName().equals("ssid")) // 若是爲SSID
               ssid = cookie.getValue();          // 保存SSID內容
        }
    }
    if(account != null && ssid !=null) {    // 若是account、SSID都不爲空
        login = ssid.equals(calcMD1(account + KEY)); // 若是加密規則正確, 則視爲已經登陸
    }
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01Transitional//EN">
       <legend><%= login ? "歡迎您回來" : "請先登陸"%></legend>
        <% if(login){%>
            歡迎您, ${cookie.account.value }. &nbsp;&nbsp;
           <a href="${pageContext.request.requestURI }?action=logout">
            註銷</a>
        <% } else { %>
        <form action="${ pageContext.request.requestURI }?action=login" method="post">
           <table>
               <tr><td>帳號： </td>
                   <td><input type="text"name="account" style="width:
                   200px; "></td>
               </tr>
               <tr><td>密碼： </td>
                   <td><inputtype="password" name="password"></td>
               </tr>
               <tr>
                   <td>有效期： </td>
                   <td><inputtype="radio" name="timeout" value="-1"
                   checked> 關閉瀏覽器即失效 <br/> <input type="radio"
                   name="timeout" value="<%= 30 *24 * 60 * 60 %>"> 30天
                   內有效 <br/><input type="radio" name="timeout" value= 
                   "<%= Integer.MAX_VALUE %>"> 永久有效 <br/> </td> </tr>
               <tr><td></td>
                   <td><input type="submit"value=" 登  錄 " class= 
                   "button"></td>
               </tr>
           </table>
        </form>
        <% } %>

登陸時能夠選擇登陸信息的有效期：關閉瀏覽器即失效、30天內有效與永久有效。經過設置Cookie的age屬性來實現，注意觀察代碼。運行效果如圖1.7所示。

Session機制

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

Session技術則是服務端的解決方案，它是經過服務器來保持狀態的。因爲Session這個詞彙包含的語義不少，所以須要在這裏明確一下 Session的含義。

首先，咱們一般都會把Session翻譯成會話，所以咱們能夠把客戶端瀏覽器與服務器之間一系列交互的動做稱爲一個 Session。從這個語義出發，咱們會提到Session持續的時間，會提到在Session過程當中進行了什麼操做等等；

其次，Session指的是服務器端爲客戶端所開闢的存儲空間，在其中保存的信息就是用於保持狀態。從這個語義出發，咱們則會提到往Session中存放什麼內容，如何根據鍵值從 Session中獲取匹配的內容等。

要使用Session，第一步固然是建立Session了。那麼Session在什麼時候建立呢？固然仍是在服務器端程序運行的過程當中建立的，不一樣語言實現的應用程序有不一樣建立Session的方法，而在Java中是經過調用HttpServletRequest的getSession方法（使用true做爲參數）建立的。在建立了Session的同時，服務器會爲該Session生成惟一的Session id，而這個Session id在隨後的請求中會被用來從新得到已經建立的Session；

在Session被建立以後，就能夠調用Session相關的方法往Session中增長內容了，而這些內容只會保存在服務器中，發到客戶端的只有Session id；當客戶端再次發送請求的時候，會將這個Session id帶上，服務器接受到請求以後就會依據Session id找到相應的Session，從而再次使用之。正式這樣一個過程，用戶的狀態也就得以保持了。

什麼是Session

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

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

實現用戶登陸

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隱藏對象，能夠直接使用。若是使用聲明瞭<font color=#c7254e><%@page session="false" %>，則Session隱藏對象不可用。下面的例子使用Session記錄客戶帳號信息。

session.jsp：

<%@ page language="java" pageEncoding="UTF-8"%>
<jsp:directive.page import="com.helloweenvsfei.sessionWeb.bean.Person"/>
<jsp:directive.page import="java.text.SimpleDateFormat"/>
<jsp:directive.page import="java.text.DateFormat"/>
<jsp:directive.page import="java.util.Date"/>
<%!
    DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd");         // 日期格式化器
%>
<%
    response.setCharacterEncoding("UTF-8");        // 設置request編碼
    Person[] persons =
    {           
       // 基礎數據，保存三我的的信息
        new Person("Liu Jinghua","password1", 34, dateFormat.parse
        ("1982-01-01")),
        new Person("Hello Kitty","hellokitty", 23, dateFormat.parse
        ("1984-02-21")),
        new Person("Garfield", "garfield_pass",23, dateFormat.parse
        ("1994-09-12"))
     };
 
    String message = "";                      // 要顯示的消息
 
    if(request.getMethod().equals("POST"))
    { 
        // 若是是POST登陸       
        for(Person person :persons)
        {           
           // 遍歷基礎數據，驗證帳號、密碼
           // 若是用戶名正確且密碼正確
           if(person.getName().equalsIgnoreCase(request.getParameter("username"))&&person.getPassword().equals(request.getParameter("password")))
           {              
               // 登陸成功，設置將用戶的信息以及登陸時間保存到Session
               session.setAttribute("person", person);                   // 保存登陸的Person
               session.setAttribute("loginTime", new Date());          // 保存登陸的時間              
               response.sendRedirect(request.getContextPath() + "/welcome.jsp");
               return;
            }
        }      
        message = "用戶名密碼不匹配，登陸失敗。";       // 登陸失敗
    }
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01Transitional//EN">
<html>
    // ... HTML代碼爲一個FORM表單，代碼略，請看隨書光盤
</html>

登陸界面驗證用戶登陸信息，若是登陸正確，就把用戶信息以及登陸時間保存進Session，而後轉到歡迎頁面welcome.jsp。welcome.jsp中從Session中獲取信息，並將用戶資料顯示出來。 welcome.jsp：

<%@ page language="java" pageEncoding="UTF-8"%>
<jsp:directive.pageimport="com.helloweenvsfei.sessionWeb.bean.Person"/>
<jsp:directive.page import="java.text.SimpleDateFormat"/>
<jsp:directive.page import="java.text.DateFormat"/>
<jsp:directive.page import="java.util.Date"/>
<%!
    DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd");         // 日期格式化器
%>
<%
    Person person =(Person)session.getAttribute("person");                       // 獲取登陸的person
    Date loginTime =(Date)session.getAttribute("loginTime");                     // 獲取登陸時間
%>
    // ... 部分HTML代碼略
            <table>
               <tr><td>您的姓名：</td>
                   <td><%= person.getName()%></td>
               </tr>
               <tr><td>登陸時間：</td>
                   <td><%= loginTime%></td>
               </tr>
               <tr><td>您的年齡：</td>
                   <td><%= person.getAge()%></td>
               </tr>
               <tr><td>您的生日：</td>
                   <td><%=dateFormat.format(person.getBirthday()) %></td>
               </tr>
            </table>

程序運行效果如圖所示。

注意：程序中Session中直接保存了Person類對象與Date類對象，使用起來要比Cookie方便。當多個客戶端執行程序時，服務器會保存多個客戶端的Session。獲取Session的時候也不須要聲明獲取誰的Session。Session機制決定了當前客戶只會獲取到本身的Session，而不會獲取到別人的Session。各客戶的Session也彼此獨立，互不可見。

提示：Session的使用比Cookie方便，可是過多的Session存儲在服務器內存中，會對服務器形成壓力。

Session的生命週期

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

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

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

Session的有效期

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

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

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

Session的經常使用方法

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

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

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

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

注意：參數的單位爲分鐘，而setMaxInactiveInterval(int s)單位爲秒。 在server.xml中定義context時採用以下定義（單位爲秒）：

<Context path="/livsorder" docBase="/home/httpd/html/livsorder" defaultSessionTimeOut="3600" isWARExpanded="true"
    isWARValidated="false" isInvokerEnabled="true"
    isWorkDirPersistent="false"/>

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地址重寫。

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>
    <a href="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了。

因爲Cookie能夠被人爲的禁止，必須有其餘機制以便在Cookie被禁止時仍然可以把session id傳遞迴服務器。常常被使用的一種技術叫作URL重寫，就是把session id直接附加在URL路徑的後面，附加方式也有兩種： 一種是做爲URL路徑的附加信息，表現形式爲http://...../xxx;jsessionid= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 一種是做爲查詢字符串附加在URL後面，表現形式爲http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

這兩種方式對於用戶來講是沒有區別的，只是服務器在解析的時候處理的方式不一樣，採用第一種方式也有利於把session id的信息和正常程序參數區分開來。爲了在整個交互過程當中始終保持狀態，就必須在每一個客戶端可能請求的路徑後面都包含這個session id。

另外一種技術叫作表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時可以把session id傳遞迴服務器。好比下面的表單：

<form name="testform" action="/xxx">
    <input type="text">
</form>

在被傳遞給客戶端以前將被改寫成：

<form name="testform" action="/xxx">
    <input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
    <input type="text">
</form>

這種技術如今已較少應用。

在談論session機制的時候，經常聽到這樣一種誤解「只要關閉瀏覽器，session就消失了」。其實能夠想象一下會員卡的例子，除非顧客主動對店家提出銷卡，不然店家絕對不會輕易刪除顧客的資料。對session來講也是同樣的，除非程序通知服務器刪除一個session，不然服務器會一直保留，程序通常都是在用戶作log off的時候發個指令去刪除session。然而瀏覽器歷來不會主動在關閉以前通知服務器它將要關閉，所以服務器根本不會有機會知道瀏覽器已經關閉，之因此會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器後這個 session id就消失了，再次鏈接服務器時也就沒法找到原來的session。若是服務器設置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發出的HTTP請求頭，把原來的session id發送給服務器，則再次打開瀏覽器仍然可以找到原來的session。

偏偏是因爲關閉瀏覽器不會致使session被刪除，迫使服務器爲seesion設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就能夠認爲客戶端已經中止了活動，纔會把session刪除以節省存儲空間。

Session中禁止使用Cookie

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

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

<?xml version='1.0' encoding='UTF-8'?>
    <Context path="/sessionWeb"cookies="false">
</Context>

或者修改Tomcat全局的conf/context.xml，修改內容以下： 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。

Cookie與Session的區別

• cookie數據存放在客戶的瀏覽器上，session數據放在服務器上；
• cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙，考慮到安全應當使用session；
• session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能。考慮到減輕服務器性能方面，應當使用COOKIE；
• 單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能超過3K；

Cookie和Session的方案雖然分別屬於客戶端和服務端，可是服務端的session的實現對客戶端的cookie有依賴關係的，上面我講到服務端執行session機制時候會生成session的id值，這個id值會發送給客戶端，客戶端每次請求都會把這個id值放到http請求的頭部發送給服務端，而這個id值在客戶端會保存下來，保存的容器就是cookie，所以當咱們徹底禁掉瀏覽器的cookie的時候，服務端的session也會不能正常使用（注意：有些資料說ASP解決這個問題，當瀏覽器的cookie被禁掉，服務端的session任然能夠正常使用，ASP我沒試驗過，可是對於網絡上不少用php和jsp編寫的網站，我發現禁掉cookie，網站的session都沒法正常的訪問）。