HTML5學習筆記（二十九）：Cookie和Session

HTTP協議自己是無狀態的，這和HTTP最初的設計是相符的，每次請求都是建立一個短鏈接，發送請求，獲得數據後就關閉鏈接。即每次鏈接都是獨立的一次鏈接。

這樣的話，致使的問題就是當我在一個頁面登錄了帳號以後，點擊鏈接打開的新界面或者關閉後再打開我都須要再次登錄帳號，因此咱們須要藉助Cookie和Session來記錄網頁的狀態。

Cookie

Cookie，有時也用其複數形式 Cookies。能夠簡單的理解爲存儲在瀏覽器的文本數據。

Cookie按域名來進行存儲，不一樣的域名存儲的Cookie相互之間不能訪問時隔絕的。而在當前域名存在Cookie時，每次向服務端進行請求時都會在HTTP請求頭中，把當前域名下的全部Cookie都一塊兒進行提交。這樣服務端就能夠獲取當前網站存儲的全部Cookie數據。而服務端在進行返回時也能夠在HTTP響應頭中附帶上新的Cookie，瀏覽器接收到返回時，會保存服務端發送的Cookie，這樣下次請求，服務端又能夠得到新發送的Cookie數據。

下面咱們來詳細的看看Cookie的一些特性。

不可跨域名

根據Cookie的規範，這是由Cookie的隱私安全機制決定的。隱私安全機制可以禁止網站非法獲取其餘網站的Cookie。不一樣域名的網站下面的Cookie是互相不能訪問的，你當前在cnblog下，就不能獲取和操做的baidu的Cookie，這是比較好理解的。

域名

正常狀況下，同一個一級域名下的兩個二級域名如www.baidu.com和images.baidu.com也不能交互使用Cookie，由於兩者的域名並不嚴格相同。

若是想全部baidu.com名下的二級域名均可以使用該Cookie，須要設置Cookie的domain參數爲.baidu.com。這樣全部二級三級域名，均可以訪問這個Cookie。

注意：domain參數必須以點(".")開始。

路徑

domain屬性決定運行訪問Cookie的域名，而path屬性決定容許訪問Cookie的路徑。

例如，若是隻容許/session/下的程序使用Cookie，能夠設定path參數爲/session/。

設置爲「/」時容許全部路徑使用Cookie。path屬性須要使用符號「/」結尾。

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

有效期

Cookie的maxAge決定着Cookie的有效期，單位爲秒（Second）。

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

若是maxAge爲負數，則表示該Cookie僅在本瀏覽器窗口以及本窗口打開的子窗口內有效，關閉窗口後該Cookie即失效。maxAge爲負數的Cookie，爲臨時性Cookie，不會被持久化，不會被寫到Cookie文件中。

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

Cookie默認的maxAge值爲–1。

安全屬性

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

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

存儲中文和圖片

中文須要使用escape和unescape兩個方法進行編碼和解碼，不然會出現亂碼。

圖片可使用Base64編碼爲字符串來保存。

瀏覽器發送cookie規則

在發起一個請求時，瀏覽器會選擇什麼樣的Cookie數據傳遞到服務端呢？

根據請求url中的域名在cookie列表中找全部與當前域名同樣的cookie，而後再根據指定的路徑進行匹配，若是當前請求在域匹配的基礎上還與路徑匹配那麼就會將全部匹配的cookie發送給服務器。

也能夠手動指定cookie的適用的域（domain），而後手動指定路徑（path）。

一些須要注意的地方

• 可能會被用戶禁用：Cookie是保存在瀏覽器端的，因此用戶有權利選擇關閉Cookie。
• 存儲大小有限制：不一樣的瀏覽器都對Cookie的存儲大小有限制，Cookie不宜存儲過多的數據。
• 容易被刪除：用戶能夠隨時清空Cookie。
• 安全性不夠高：Cookie是用明文的方式存儲的，不適合保存敏感的數據。

Session

在Web端保存用戶狀態的方式除了Cookie外，還可使用Session來進行保存，不一樣的是Cookie保存在瀏覽器，而Session保存在服務端。

Session的存取都只能在服務端進行操做，因此瀏覽器是不能直接對Session的數據進行讀取和操做的（間接固然是能夠的，瀏覽器能夠發送數據給服務端用來存Session的值，服務端也能夠直接把Session的值做爲返回值返回到瀏覽器）。

惟一要解決的問題就是，由於每次請求都是獨立的，因此服務端須要知道每次的請求的身份，好比我和李雷同時請求，服務端須要知道那些請求是個人，那些是李雷的。

解決這個問題的方式通常以下：當服務端開始使用Session時，會生成一個guid用來標記本次請求的客戶端，能夠把這個guid看作是這個客戶端的id，而後，會把這個guid做爲Cookie發送給瀏覽器。瀏覽器會自動保存這個guid，下次客戶端再次請求時，這個Cookie會傳遞給服務端，服務端獲得guid後，就能夠獲取以前的Session的全部數據了。

示例

下面咱們以NodeJS的Express框架爲例，來看一下Session的例子。

咱們第一次請求時，瀏覽器的請求頭沒有包含任何的Cookie信息，可是服務端的響應頭裏包含了一個名爲connect.sid的Cookie信息返回到瀏覽器，這個connect.sid就是服務端生成的SessionID。

後續的請求，瀏覽器的請求頭中就會包含名爲connect.sid的SessionID，服務端能夠知道當前請求的SessionID，就能夠獲取前面請求保存的數據了，因爲瀏覽器已經有了SessionID，那麼本次的服務端響應頭的Cookie就沒有再發送connect.sid到瀏覽器了。

有效期

Session在設定時，都有一個有效時間（這個時間通常均可以配置，不一樣的語言框架配置方式各異），實際上就是傳遞到瀏覽器的Cookie的有效時間，因爲Session通常存放在服務端的內存中，若是不清除則會致使內存佔用愈來愈多，最終整個服務器奔潰。因此服務端會在必定的時間清除過時或者長時間不使用的Session及數據。

URL地址重寫

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

這兩種方式對於用戶來講是沒有區別的，只是服務器在解析的時候處理的方式不一樣，採用第一種方式也有利於把SessionID的信息和正常程序參數區分開來。