本章我們來講解cookie和session ,這兩個東西相信大家一定不陌生,概念就不多講了,我們直接來看其用法,首先是cookie,我們在view中添加三個視圖,一個是顯示cookie的,一個是設定cookie的,如下:
配置urls.py，輸入testCookie/show/顯示cookie的值，輸入testCookie/set/XXX/則是把cookie的值修改成為XXX，urls.py如下：
如果這時你運作testCookie/show/，會顯示：
如果運作testCookie/set/hemeng80/則會出錯：
這時因為編碼格式不正确，需要做以下處理在view.py的頭部加上:
這時在運作testCookie/set/hemeng80/
這樣就對了，在執行一遍testCookie/show/，就會看到結果了：
cookie的存儲是自願的，一個用戶端不一定要去接受或存儲cookie。事實上，所有的浏覽器都讓使用者自己控制是否接受cookies。如果你想知道cookies對于Web應用有多重要，你可以試着打開這個浏覽器的選項：
盡管cookies廣為使用，但仍被認為是不可靠的的。這意味着，開發者使用cookies之前必須檢查使用者是否可以接收cookie。
Cookie(特别是那些沒通過HTTPS傳輸的)是非常不安全的。因為HTTP資料是以明文發送的，是以特别容易受到嗅探攻擊。也就是說，嗅探攻擊者可以在網絡中攔截并讀取cookies，是以你要絕對避免在cookies中存儲敏感資訊。這就意味着您不應該使用cookie來在存儲任何敏感資訊。
是以不能在cookies中存儲可能會被篡改的敏感資料。在cookies中存儲 IsLoggedIn=1 ，以辨別使用者已經登入。犯這類錯誤的站點數量多的令人難以置信；繞過這些網站的安全系統也是易如反掌。
由于存在的限制與安全漏洞，cookies和持續性會話已經成為Web開發中令人頭疼的典範。 好消息是，Django的目标正是高效的“頭疼殺手”，它自帶的session架構會幫你搞定這些問題。
你可以用session 架構來存取每個通路者任意資料，這些資料在伺服器端存儲，并對cookie的收發進行了抽象。 Cookies隻存儲資料的哈希會話ID，而不是資料本身，進而避免了大部分的常見cookie問題。
下面我們來看看如何打開session功能，并在視圖中使用它。
確定在settings.py檔案中：
1. 編輯 MIDDLEWARE_CLASSES 配置，確定 MIDDLEWARE_CLASSES 中包含‘django.contrib.sessions.middleware.SessionMiddleware‘。
2. 确認 INSTALLED_APPS 中有 ‘django.contrib.sessions‘ (如果你是剛打開這個應用，别忘了運作manage.py syncdb )
這些其實預設的就有，不用擔心了。SessionMiddleware 激活後，每個傳給視圖(view)函數的第一個參數``HttpRequest``
對象都有一個 session 屬性，這是一個字典型的對象。 你可以象用普通字典一樣來用它。
代碼編寫過程很想cookie,這裡直接把代碼貼出來了,不再解釋.
修改我們的view：
修改一下urls.py
運作結果如圖:
如果這時候你運作set的視圖時，就會看到如下内容。
原因是因為你沒有建立session等表格，在指令行狀态輸入：<code>manage.py syncdb</code><code>，如下圖所示：</code>
這時在運作這個程式就會發現:
其實我們執行了<code>manage.py syncdb</code><code>以後，實際上是自動建立了一下幾個表在資料庫中。如果我們要把這些代碼上傳到sae</code><code>中，顯然還是會出現上述錯誤，因為sae</code><code>中也并沒有session</code><code>相關的表格。</code>
這時候我們就必須在sae中也建立相應的表格。
首先進入Mysql-Front,選購中新增加的9個表格：
右鍵，輸出sql檔案：
點選下一步，完成。進入sae的資料庫管理界面：
把剛才的代碼貼近來，執行，建立表格
這個原因是因為sae的InnoDB沒有啟用，修改SQL語句中的引擎InnoDB為MyISAM，一般MyISAM都是啟用的。在執行：
這時在運作一下網上的代碼：
大功告成。
PS:
你可能注意到了，Google給我們發送的cookie中有 expires=Sun, 17-Jan-2038 19:14:07 GMT; cookie可以有過期時間，這樣浏覽器就知道什麼時候可以删除cookie了。
如果cookie沒有設定過期時間，當使用者關閉浏覽器的時候，cookie就自動過期了。 你可以改變 SESSION_EXPIRE_AT_BROWSER_CLOSE 的設定來控制session架構的這一行為。
預設情況下， SESSION_EXPIRE_AT_BROWSER_CLOSE 設定為 False ，這樣，會話cookie可以在使用者浏覽器中保持有效達 SESSION_COOKIE_AGE 秒（預設設定是兩周，即1,209,600 秒）。如果你不想使用者每次打開浏覽器都必須重新登陸的話，用這個參數來幫你。
如果 SESSION_EXPIRE_AT_BROWSER_CLOSE 設定為 True ，當浏覽器關閉時，Django會使cookie失效。
如果想得到session生命周期和浏覽器生命周期相同方法：
在setting.py檔案添加：
SESSION_EXPIRE_AT_BROWSER_CLOSE = True
除了上面提到的設定，還有一些其他的設定可以影響Django session架構如何使用cookie，詳見表 14-2.
表 14-2. 影響cookie行為的設定
設定
描述
預設
SESSION_COOKIE_DOMAIN
使用會話cookie（session cookies）的站點。 将它設成一個字元串，就好象`` “.example.com”`` 以用于跨站點（cross-domain）的cookie，或`` None`` 以用于單個站點。
None
SESSION_COOKIE_NAME
會話中使用的cookie的名字。 它可以是任意的字元串。
"sessionid"
SESSION_COOKIE_SECURE
是否在session中使用安全cookie。 如果設定 True , cookie就會标記為安全， 這意味着cookie隻會通過HTTPS來傳輸。
False