Session，Cookie，jsessionid，Url重寫

在一些投票之類的場合，咱們每每由於公平的原則要求每人只能投一票，在一些WEB開發中也有相似的狀況，這時候咱們一般會使用COOKIE來實現，例如以下的代碼：

< % cookie[]cookies = request.getCookies();

if (cookies.lenght == 0 || cookies == null){

doStuffForNewbie();

//沒有訪問過

}else{

doStuffForReturnVisitor(); //已經訪問過了

}

% >

這是很淺顯易懂的道理，檢測COOKIE的存在，若是存在說明已經運行過寫入COOKIE的代碼了，然而運行以上的代碼後，不管什麼時候結果都是執行doStuffForReturnVisitor()，經過控制面板-Internet選項-設置-察看文件卻始終看不到生成的cookie文件，奇怪，代碼明明沒有問題，不過既然有cookie，那就顯示出來看看。

cookie[]cookies = request.getCookies();

if (cookies.lenght == 0 || cookies == null)

out.println("Has not visited this website");

}else{

for (int i = 0; i < cookie.length; i++){

out.println("cookie name:" + cookies[i].getName() + "cookie value:" +

cookie[i].getValue());

}

}

運行結果:

cookie name:JSESSIONID cookie value:KWJHUG6JJM65HS2K6

爲何會有cookie呢,你們都知道，http是無狀態的協議，客戶每次讀取web頁面時，服務器都打開新的會話，並且服務器也不會自動維護客戶的上下文信息，那麼要怎麼才能實現網上商店中的購物車呢，session就是一種保存上下文信息的機制，它是針對每個用戶的，變量的值保存在服務器端，經過SessionID來區分不一樣的客戶,session是以cookie或URL重寫爲基礎的，默認使用cookie來實現，系統會創造一個名爲JSESSIONID的輸出cookie，咱們叫作session cookie,以區別persistent cookies,也就是咱們一般所說的cookie,注意session cookie是存儲於瀏覽器內存中的，並非寫到硬盤上的，這也就是咱們剛纔看到的JSESSIONID，咱們一般情是看不到JSESSIONID的，可是當咱們把瀏覽器的cookie禁止後，web服務器會採用URL重寫的方式傳遞Sessionid，咱們就能夠在地址欄看到sessionid=KWJHUG6JJM65HS2K6之類的字符串。

明白了原理，咱們就能夠很容易的分辨出persistent cookies和session cookie的區別了，網上那些關於二者安全性的討論也就一目瞭然了，session cookie針對某一次會話而言，會話結束session cookie也就隨着消失了，而persistent cookie只是存在於客戶端硬盤上的一段文本（一般是加密的），並且可能會遭到cookie欺騙以及針對cookie的跨站腳本攻擊，天然不如session cookie安全了。

一般session cookie是不能跨窗口使用的，當你新開了一個瀏覽器窗口進入相同頁面時，系統會賦予你一個新的sessionid，這樣咱們信息共享的目的就達不到了，此時咱們能夠先把sessionid保存在persistent cookie中，而後在新窗口中讀出來，就能夠獲得上一個窗口SessionID了，這樣經過session cookie和persistent cookie的結合咱們就實現了跨窗口的session tracking（會話跟蹤）。

在一些web開發的書中，每每只是簡單的把Session和cookie做爲兩種並列的http傳送信息的方式，session cookies位於服務器端，persistent cookie位於客戶端，但是session又是以cookie爲基礎的，明白的二者之間的聯繫和區別，咱們就不難選擇合適的技術來開發web service了。

cookie和session機制之間的區別與聯繫

 具體來講cookie機制採用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他須要用戶打開客戶端的cookie支持。cookie的做用就是爲了解決HTTP協議無狀態的缺陷所做的努力.

而session機制採用的是一種在客戶端與服務器之間保持狀態的解決方案。同時咱們也看到，因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式

session是針對每個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪一個用戶session變量,這個值是經過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器。

就安全性來講：當你訪問一個使用session 的站點，同時在本身機子上創建一個cookie，建議在服務器端的SESSION機制更安全些.由於它不會任意讀取客戶存儲的信息。

正統的cookie分發是經過擴展HTTP協議來實現的，服務器經過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也能夠生成cookie。而cookie的使用是由瀏覽器按照必定的原則在後臺自動發送給服務器的。瀏覽器檢查全部存儲的cookie，若是某個cookie所聲明的做用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。

從網絡服務器觀點看全部HTTP請求都獨立於先前請求。就是說每個HTTP響應徹底依賴於相應請求中包含的信息狀態管理機制克服了HTTP的一些限制並容許網絡客戶端及服務器端維護請求間的關係。在這種關係維持的期間叫作會話(session)。

Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規範。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。

cookie的內容主要包括：名字，值，過時時間，路徑和域。路徑與域一塊兒構成cookie的做用範圍。若不設置過時時間，則表示這個cookie的生命期爲瀏覽器會話期間，關閉瀏覽器窗口，cookie就消失。這種生命期爲瀏覽器會話期的cookie被稱爲會話cookie。會話cookie通常不存儲在硬盤上而是保存在內存裏，固然這種行爲並非規範規定的。若設置了過時時間，瀏覽器就會把cookie保存到硬盤上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過時時間。存儲在硬盤上的cookie能夠在不一樣的瀏覽器進程間共享，好比兩個IE窗口。而對於保存在內存裏的cookie，不一樣的瀏覽器有不一樣的處理方式。

session機制。session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。

當程序須要爲某個客戶端的請求建立一個session時，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識（稱爲session id），若是已包含則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

保存這個session id的方式能夠採用cookie，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發揮給服務器。通常這個cookie的名字都是相似於SEEESIONID。但cookie能夠被人爲的禁止，則必須有其餘機制以便在cookie被禁止時仍然可以把session id傳遞迴服務器。

常常被使用的一種技術叫作URL重寫，就是把session id直接附加在URL路徑的後面。還有一種技術叫作表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時可以把session id傳遞迴服務器。好比：

<form name="testform" action="/xxx">

<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">

<input type="text">

</form>

什麼是Url重寫?

服務器也能夠經過URL重寫的方式來傳遞SessionID的值，所以不是徹底依賴Cookie。若是客戶端Cookie禁用，則服務器能夠自動經過重寫URL的方式來保存Session的值，而且這個過程對程序員透明。

能夠試一下，即便不寫Cookie，在使用request.getCookies();取出的Cookie數組的長度也是1，而這個Cookie的名字就是JSESSIONID，還有一個很長的二進制的字符串，是SessionID的值。

實質上 URL 重寫是經過向 URL 鏈接添加參數，並把 session ID 做爲值包含在鏈接中。然而，爲使這生效，你須要爲你的 servlet 響應部分的每一個鏈接添加 session ID.

利用Url進行Session重寫如何實現?

JSP實現

把 session ID 加到一個鏈接可使用一對方法來簡化：response.encodeURL() 使 URL包含 session ID，若是你須要使用重定向，可使用 response.encodeRedirectURL ()來對 URL 進行編碼。encodeURL () 及 encodeRedirectedURL () 方法首先判斷 cookie是否被瀏覽器支持；若是支持，則參數 URL 被原樣返回，session ID 將經過 cookies 來維持。

代碼示例:

不使用Url重寫:<a href=http://wwww.myserver.com/servelet/user;userName=awaysrain>Link</a>

使用Url重寫:經過HttpServletResponse接口中的encodeURL()方法編碼.

String myURL = response.encodeURL(http://wwww.myserver.com/servelet/user);

<a href= <%=myURL%> _fcksavedurl=" <%=myURL%>" _fcksavedurl=" <%=myURL%>" _fcksavedurl=" <%=myURL%>" >

JSTL實現

<c:url>能夠爲會話管理重寫 URL

<a href="<c:url value='/content/sitemap.jsp'/>">View sitemap</a>

Struts實現:

struts配置文件中：設置屬性redirect, contextRelative

<forward name="listArticlesForBlog"

path="/template/listArticlesForBlog.jsp"

redirect="true"

contextRelative="true"/>

最後一個比較搞的問題:

那麼在瀏覽器容許cookie的狀況下，不要求瀏覽器關閉cookie的狀況下使用

url重寫如何實現?

http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

Context支持cookies參數。 設置cookies="false"，強制只從url解析sessionid。

cookies

Set to true if you want cookies to be used for session identifierContext

communication if supported by the client (this is the default). Set to

false if you want to disable the use of cookies for session identifier

communication, and rely only on URL rewriting by the application.