2、Django用戶認證之cookie和session

一、cookie原理

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

爲了維持用戶在網站的狀態，好比登錄、購物車等，出現了前後出現了四種技術，分別是隱藏表單域、URL重寫、cookie、session。

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

當你在瀏覽網站的時候，WEB 服務器會先送一小小資料放在你的計算機上，Cookie 會幫你在網站上所打的文字或是一些選擇，都記錄下來。當下次你再光臨同一個網站，WEB 服務器會先看看有沒有它上次留下的 Cookie 資料，有的話，就會依據 Cookie裏的內容來判斷使用者，送出特定的網頁內容給你。 Cookie 的使用很廣泛，許多有提供我的化服務的網站，都是利用 Cookie來辨認使用者，以方便送出使用者量身定作的內容，同時也能夠緩解服務端的壓力，好比使用cookie以後，用戶不須要在短時間內頻繁查詢數據庫進行登陸，他能夠經過cookie進行直接登陸，固然，這也會帶來安全問題，一旦你的cookie被盜用，其餘人也能夠登陸網址。

 

二、session原理

Session 是存放在服務器端的，相似於Session結構來存放用戶數據，當瀏覽器 第一次發送請求時，服務器自動生成了一個Session和一個Session ID用來惟一標識這個Session，並將其經過響應發送到瀏覽器。當瀏覽器第二次發送請求，會將前一次服務器響應中的Session ID放在請求中一併發送到服務器上，服務器從請求中提取出Session ID，並和保存的全部Session ID進行對比，找到這個用戶對應的Session。

 

通常狀況下，服務器會在必定時間內（默認30分鐘）保存這個 Session，過了時間限制，就會銷燬這個Session。在銷燬以前，程序員能夠將用戶的一些數據以Key和Value的形式暫時存放在這個 Session中。固然，也有使用數據庫將這個Session序列號後保存起來的，這樣的好處是沒了時間的限制，壞處是隨着時間的增長，這個數據庫會急速膨脹，特別是訪問量增長的時候。通常仍是採起前一種方式，以減輕服務器壓力。

具體來講cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。同時咱們也看到，因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助於cookie機制來達到保存標識的目的，但實際上它還有其餘選擇。

 

三、cookie與session的區別

簡單來講，cookie數據保存在客戶端，session數據保存在服務器端。

瀏覽器cookie

若是瀏覽器使用的是 cookie，那麼全部的數據都保存在瀏覽器端，好比你登陸之後，服務器設置了 cookie用戶名(username),那麼，當你再次請求服務器的時候，瀏覽器會將username一塊發送給服務器，這些變量有必定的特殊標記。服務器會解釋爲 cookie變量。因此只要不關閉瀏覽器，那麼 cookie變量便一直是有效的，因此可以保證長時間不掉線。若是你可以截獲某個用戶的 cookie變量，而後僞造一個數據包發送過去，那麼服務器仍是認爲你是合法的。因此，使用 cookie被攻擊的可能性比較大。若是設置了的有效時間，那麼它會將 cookie保存在客戶端的硬盤上，下次再訪問該網站的時候，瀏覽器先檢查有沒有 cookie，若是有的話，就讀取該 cookie，而後發送給服務器。若是你在機器上面保存了某個論壇 cookie，有效期是一年，若是有人入侵你的機器，將你的 cookie拷走，而後放在他的瀏覽器的目錄下面，那麼他登陸該網站的時候就是用你的的身份登陸的。因此 cookie是能夠僞造的。固然，僞造的時候須要主意，直接copy cookie文件到 cookie目錄，瀏覽器是不認的，他有一個index.dat文件，存儲了 cookie文件的創建時間，以及是否有修改，因此你必須先要有該網站的 cookie文件，而且要從保證時間上騙過瀏覽器。

服務端session，客戶端sessionID

當你登陸一個網站的時候，若是web服務器端使用的是session,那麼全部的數據都保存在服務器上面，客戶端每次請求服務器的時候會發送當前會話的sessionid，服務器根據當前sessionid判斷相應的用戶數據標誌，以肯定用戶是否登陸，或具備某種權限。因爲數據是存儲在服務器 上面，因此你不能僞造，可是若是你可以獲取某個登陸用戶的sessionid，用特殊的瀏覽器僞造該用戶的請求也是可以成功的。sessionid是服務 器和客戶端連接時候隨機分配的，通常來講是不會有重複，但若是有大量的併發請求，也不是沒有重複的可能性，我曾經就遇到過一次。登陸某個網站，開始顯示的 是本身的信息，等一段時間超時了，一刷新，竟然顯示了別人的信息。

Session是由應用服務器維持的一個服務器端的存儲空間，用戶在鏈接服務器時，會由服務器生成一個惟一的SessionID,用該SessionID 爲標識符來存取服務器端的Session存儲空間。而SessionID這一數據則是保存到客戶端，用Cookie保存的，用戶提交頁面時，會將這一 SessionID提交到服務器端，來存取Session數據。這一過程，是不用開發人員干預的。因此一旦客戶端禁用Cookie，那麼Session也會失效。

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

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

 

四、cookie和session的關係

Cookies是屬於Session對象的一種。但有不一樣，Cookies不會佔服務器資源，是存在客服端內存或者一個cookie的文本文件中；而「Session」則會佔用服務器資源。因此，儘可能不要使用Session，而使用Cookies。可是咱們通常認爲cookie是不可靠的，session是可靠的，可是目前不少著名的站點也都用cookie。有時候爲了解決禁用cookie後的頁面處理，一般採用url重寫技術，調用session中大量有用的方法從session中獲取數據後置入頁面。

 

五、Cookies與Session的應用場景

Cookies的安全性能一直是倍受爭議的。雖然Cookies是保存在本機上的，可是其信息的徹底可見性且易於本地編輯性，每每能夠引發不少的安全問題。因此Cookies到底該不應用，到底該怎樣用，就有了一個須要給定的底線。

session應用場景

1. 經過session累計用戶數據。例如，一個未登陸用戶訪問了京東網站，這個時候京東對其下發了一個 cookie，假設cookie的名字叫作abc，那這條記錄就是 abc＝001，同時京東的後臺也生成了一個 session id， 它的值也爲 001， 001 這個客戶在 2 點、 3 點、 4 點分別添加了三件商品到購物車，這樣後臺也記錄了 session id 爲 001的用戶的購物車裏面已經有三件商品，而且只要每次客戶端 cookie 帶上來的值裏面包含session id，後臺都可以展現相應的數據，若是這個時候，在瀏覽器裏面清空 cookie，cookie 數據消失以後，後臺和客戶端沒法創建對應關係，購物車的數據就會失效了。
2. 經過session實現單點登陸。一個用戶賬號成功登陸後，在該次session還未失效以前，不能在其餘機器上登陸同一個賬號。登陸後將用戶信息保存到session中，若是此時在另一臺機器上一個相同的賬號請求登陸，經過遍歷（遍歷的意思就是將全部session都查看一遍）Web服務器中全部session並判斷其中是否包含一樣的用戶信息，若是有，在另外一臺機器上是不能登陸該賬號的。

cookie應用場景

1. 判斷註冊用戶是否已經登陸網站：用戶可能會獲得提示，是否在下一次進入此網站時保留用戶信息以便簡化登陸流程。
2. 根據用戶的愛好定製內容：網站建立包含用戶瀏覽內容的cookies，在用戶下次訪問時，網站根據用戶的狀況對顯示的內容進行調整，將用戶感興趣的內容放在前列。
3. 實現永久登陸：若是用戶是在本身家的電腦上上網，登陸時就能夠記住他的登陸信息，下次訪問時不須要再次登陸，直接訪問便可。
4. 實現自動登陸：當用戶註冊網站後，就會收到一個唯一用戶ID的cookie。用戶再次鏈接時，這個用戶ID會自動返回，服務器對它進行檢查，肯定它是不是註冊用戶且選擇了自動登陸，從而使用戶無需給出明確的用戶名和密碼，就能夠訪問服務器上的資源。
5. 使用cookie記錄各個用戶的訪問計數：獲取cookie數組中專門用於統計用戶訪問次數的cookie的值，將值加1並將最新cookie輸出。
6. 使用cookie記住用戶名與用戶密碼。用戶勾選了「自動登陸」，就把用戶名和密碼的信息放到cookie中。同時可設置有效期。
7. 用cookie實現新手大禮包等彈窗功能。同理，將新手大禮包彈窗邏輯寫入到cookie中，並設置相應的有效期。好比在有效期內只彈出一次該彈窗，超過有效期登陸後再次彈出彈窗。
   
   
   

六、cookie參數

語法：Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

a、value

value 部分，一般是一個 name=value 格式的字符串。事實上，這種格式是原始規範中指定的格式，可是瀏覽器並不會對 cookie 值按照此格式來驗證。實際上，你能夠指定一個不含等號的字符串，它一樣會被存儲。然而，最經常使用的使用方式是按照 name=value 格式來指定 cookie 的值（大多數接口只支持該格式）。

發送回服務器的cookie只包含cookie設置的值，而不包含cookie的其餘可選項,並且瀏覽器不會對cookie作任何更改，會原封不動的發送回服務器。當存在多個cookie時，用分號和空格隔開：

Cookie: name=value; name1=value1; name2=value2/pre>

b、cookie過時時間

若是不設置cookie過時時間，cookie會在會話結束後銷燬，稱爲會話cookie。若是想將會話cookie設置爲持久cookie，只需設置一下cookie的過時時間便可，該選項的值是一個 Wdy, DD-Mon-YYYY HH:MM:SS GMT 日期格式的值。注意這個失效日期則關聯了以 name-domain-path-secure 爲標識的 cookie。要改變一個 cookie 的失效日期，你必須指定一樣的組合。

持久cookie是沒法改爲會話cookie，除非刪除這個cookie，而後從新創建這個cookie。

c、domain 選項

domian選項設置了cookie的域，只有發向這個域的http請求才能攜帶這些cookie。通常狀況下domain會被設置爲建立該cookie的頁面所在的域名。

像 Yahoo! 這種大型網站，都會有許多 name.yahoo.com 形式的站點（例如：my.yahoo.com, finance.yahoo.com 等等）。將一個 cookie 的 domain 選項設置爲 yahoo.com，就能夠將該 cookie 的值發送至全部這些站點。瀏覽器會把 domain 的值與請求的域名作一個尾部比較（即從字符串的尾部開始比較），並將匹配的 cookie 發送至服務器。

d、path 選項

path選項和domain選項相似，只有包含指定path的http請求才能攜帶這些cookie。這個比較一般是將 path 選項的值與請求的 URL 從頭開始逐字符比較完成的。若是字符匹配，則發送 Cookie 消息頭，例如：

set-cookie:namevalue;path=/blog

因此包含/blog的http請求都會攜帶cookie信息。

e、secure 選項

該選項只是一個標記而沒有值。只有當一個請求經過 SSL 或 HTTPS 建立時，包含 secure 選項的 cookie 才能被髮送至服務器。這種 cookie 的內容具備很高的價值，若是以純文本形式傳遞頗有可能被篡改。

事實上,機密且敏感的信息毫不應該在 cookie 中存儲或傳輸，由於 cookie 的整個機制本來都是不安全的。默認狀況下，在 HTTPS 連接上傳輸的 cookie 都會被自動添加上 secure 選項。

f、HTTP-Only

HTTP-Only 的意思是告之瀏覽器該 cookie 毫不能經過 JavaScript 的 document.cookie 屬性訪問。設計該特徵意在提供一個安全措施來幫助阻止經過 JavaScript 發起的跨站腳本攻擊 (XSS) 竊取 cookie 的行爲。