token、cookie和session區別以及django中的cookie,csrf

　參考：https://my.oschina.net/xianggao/blog/395675?fromerr=GC9KVenE

【前言】登陸時須要post的表單信息。

　　先跳過具體案例，講解基礎知識：

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

　　本章將系統地講述Cookie與Session機制，並比較說明何時不能用Cookie，何時不能用Session。還有token的應用。

1、Cookie技術

　　Cookie技術是客戶端的解決方案，Cookie就是由服務器發給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，而後客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息。讓咱們說得更具體一些：當用戶使用瀏覽器訪問一個支持Cookie的網站的時候，用戶會提供包括用戶名在內的我的信息而且提交至服務器；接着，服務器在向客戶端回傳相應的超文本的同時也會發回這些我的信息，固然這些信息並非存放在HTTP響應體（Response Body）中的，而是存放於HTTP響應頭（Response Header）；當客戶端瀏覽器接收到來自服務器的響應以後，瀏覽器會將這些信息存放在一個統一的位置，對於Windows操做系統而言，咱們能夠從： [系統盤]:\Documents and Settings[用戶名]\Cookies目錄中找到存儲的Cookie；自此，客戶端再向服務器發送請求的時候，都會把相應的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響應到客戶端

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

2、Session

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

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

　　服務器管理session通訊的方式有不少。在客戶端保持jsessionid只是其中一個，我遇到的是jsessionid放在cookie裏面作一個字段，發送到服務器分配的內存，如此來標識訪問。有的是放在url中，我沒遇到過。requests庫，能夠保持session,簡單方便。jsession只是tomcat—java服務器對session的id的叫法。

　　經過sessionid的方式來實現session只是分佈式服務器下的一種方法，更多可參考這裏。　　

 3、Cookie與Session的區別

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

　　Cookie和Session的方案雖然分別屬於客戶端和服務端，可是服務端的session的實現對客戶端的cookie有依賴關係的，上面我講到服務端執行session機制時候會生成session的id值，這個id值會發送給客戶端，客戶端每次請求都會把這個id值放到http請求的頭部發送給服務端，而這個id值在客戶端會保存下來，保存的容器就是cookie，所以當咱們徹底禁掉瀏覽器的cookie的時候，服務端的session也會不能正常使用。

　　做用：

　　一、保持登陸；二、服務器端可能會作一些信息保存，針對性識別，個性化推薦

4、python中的cookie

http://www.javashuo.com/article/p-udtpjiug-ch.html

5、token

　　token的提出，主要是應對CSRF攻擊（跨站請求僞造）的。簡而言之就是用戶在信任網站A，並保存cookie的狀況下，沒有關閉A（即便關閉了頁面cookie也不必定立刻過時）就去訪問危險網站B了。B就會利用A的cookie去訪問服務器。用戶在保持session()時，post（）還要提交token.

　　下面是在未登錄前，經過get()，解析html獲得的token，其值是一個散列值。post()時要帶上此token.

<div><input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="7f3339af30244a99d366b9dd047080b3"></div>

　　Django中有一個應對CSRF的中間件：CsrfMiddleware。經過在setting中的中間件配置中加上，而後在html表單裏面加上token的位置，就能夠了。具體可參考：我。

6、Django框架中的cookie

　　http://www.cnblogs.com/freely/p/6926253.html