Django基礎八之cookie和session
本節目錄html
咱們須要先了解一下什麼是會話！能夠把會話理解爲客戶端與服務器之間的一次會晤，在一次會晤中可能會包含屢次請求和響應。例如你給10086打個電話，你就是客戶端，而10086服務人員就是服務器了。從雙方接通電話那一刻起，會話就開始了，到某一方掛斷電話表示會話結束。在通話過程當中，你會向10086發出多個請求，那麼這多個請求都在一個會話中。 客戶向某一服務器發出第一個請求開始，會話就開始了，直到客戶關閉了瀏覽器會話結束。web
在一個會話的多個請求中共享數據，這就是會話跟蹤技術。例如在一個會話中的請求以下： 數據庫
- 請求銀行主頁；
- 請求登陸（請求參數是用戶名和密碼）；
- 請求轉帳（請求參數與轉帳相關的數據）；
- 請求信譽卡還款（請求參數與還款相關的數據）。
在這上會話中當前用戶信息必須在這個會話中共享的，由於登陸的是張三，那麼在轉帳和還款時必定是相對張三的轉帳和還款！這就說明咱們必須在一個會話過程當中有共享數據的能力。而web中這種能力的實現就要依靠cookie和sessiondjango
Cookie的由來
你們都知道HTTP協議是無狀態的。瀏覽器
無狀態的意思是每次請求都是獨立的，它的執行狀況和結果與前面的請求和以後的請求都無直接關係，它不會受前面的請求響應狀況直接影響，也不會直接影響後面的請求響應狀況。緩存
一句有意思的話來描述就是人生只如初見，對服務器來講，每次的請求都是全新的。安全
狀態能夠理解爲客戶端和服務器在某次會話中產生的數據，那無狀態的就覺得這些數據不會被保留。會話中產生的數據又是咱們須要保存的，也就是說要「保持狀態」。所以Cookie就是在這樣一個場景下誕生。服務器
而且還有一個問題就是，你登錄個人網站的時候，我無法肯定你是否是登錄了，以前咱們學的django，雖然寫了不少頁面，可是用戶不用登錄都是能夠看全部網頁的，只要他知道網址就行，可是咱們爲了本身的安全機制，咱們是否是要作驗證啊，訪問哪個網址，都要驗證用戶的身份，可是還有保證什麼呢，用戶登錄過以後，還要保證登錄了的用戶不須要再重複登錄，就可以訪問我網站的其餘的網址的頁面，對不對，可是http無狀態啊，怎麼保證這個事情呢？此時就要找cookie了。cookie
什麼是Cookie
首先來說，cookie是瀏覽器的技術，Cookie具體指的是一段小信息，它是服務器發送出來存儲在瀏 覽器上的一組組鍵值對，能夠理解爲服務端給客戶端的一個小甜點，下次訪問服務器時瀏覽器會自動攜帶這些鍵值對，以便服務器提取有用信息。session
Cookie的原理
cookie的工做原理是：瀏覽器訪問服務端，帶着一個空的cookie，而後由服務器產生內容，瀏覽器收到相應後保存在本地；當瀏覽器再次訪問時，瀏覽器會自動帶上Cookie，這樣服務器就能經過Cookie的內容來判斷這個是「誰」了。
查看Cookie
咱們使用Chrome瀏覽器，打開開發者工具。
cookie圖解
Cookie規範
- Cookie大小上限爲4KB；
- 一個服務器最多在客戶端瀏覽器上保存20個Cookie；
- 一個瀏覽器最多保存300個Cookie，由於一個瀏覽器能夠訪問多個服務器。
上面的數據只是HTTP的Cookie規範，但在瀏覽器大戰的今天，一些瀏覽器爲了戰勝對手，爲了展示本身的能力起見，可能對Cookie規範「擴展」了一些，例如每一個Cookie的大小爲8KB，最多可保存500個Cookie等！但也不會出現把你硬盤佔滿的可能！
注意，不一樣瀏覽器之間是不共享Cookie的。也就是說在你使用IE訪問服務器時，服務器會把Cookie發給IE，而後由IE保存起來，當你在使用FireFox訪問服務器時，不可能把IE保存的Cookie發送給服務器。
Cookie與HTTP頭
Cookie是經過HTTP請求和響應頭在客戶端和服務器端傳遞的：
- Cookie：請求頭，客戶端發送給服務器端；
- 格式：Cookie: a=A; b=B; c=C。即多個Cookie用分號離開； Set-Cookie：響應頭，服務器端發送給客戶端；
- 一個Cookie對象一個Set-Cookie： Set-Cookie: a=A Set-Cookie: b=B Set-Cookie: c=C
Cookie的覆蓋
若是服務器端發送重複的Cookie那麼會覆蓋原有的Cookie，例如客戶端的第一個請求服務器端發送的Cookie是：Set-Cookie: a=A；第二請求服務器端發送的是：Set-Cookie: a=AA，那麼客戶端只留下一個Cookie，即：a=AA。
Ctrl + Shift + del三個鍵來清除頁面緩存和cookie，未來這個操做你會用的不少。
獲取Cookie
request.COOKIES['key'] request.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
參數：
default: 默認值
salt: 加密鹽
max_age: 後臺控制過時時間
設置Cookie
rep = HttpResponse(...) rep ＝ render(request, ...) rep.set_cookie(key,value,...) rep.set_signed_cookie(key,value,salt='加密鹽', max_age=None, ...)
參數：
key, 鍵
value='', 值
max_age=None, 超時時間
expires=None, 超時時間(IE requires expires, so set it if hasn't been already.)
path='/', Cookie生效的路徑，/ 表示根路徑，特殊的：根路徑的cookie能夠被任何url的頁面訪問
domain=None, Cookie生效的域名
secure=False, https傳輸
httponly=False 只能http協議傳輸，沒法被JavaScript獲取（不是絕對，底層抓包能夠獲取到也能夠被覆蓋）
set_cookie方法源碼：
class HttpResponseBase:
def set_cookie(self, key, 鍵
value='', 值
max_age=None, 超長時間 ,有效事件，max_age=20意思是這個cookie20秒後就消失了，默認時長是2周,這個是以秒爲單位的
cookie須要延續的時間（以秒爲單位）
若是參數是\ None`` ，這個cookie會延續到瀏覽器關閉爲止。
expires=None, 超長時間，值是一個datetime類型的時間日期對象，到這個日期就失效的意思，用的很少
expires默認None ,cookie失效的實際日期/時間。
path='/', Cookie生效的路徑，就是訪問哪一個路徑能夠獲得cookie，'/'是全部路徑都能得到cookie
瀏覽器只會把cookie回傳給帶有該路徑的頁面，這樣能夠避免將
cookie傳給站點中的其餘的應用。
/ 表示根路徑，特殊的：根路徑的cookie能夠被任何url的頁面訪問
domain=None, Cookie生效的域名
你可用這個參數來構造一個跨站cookie。
如， domain=".example.com"
所構造的cookie對下面這些站點都是可讀的：
www.example.com 、 www2.example.com
和an.other.sub.domain.example.com 。
若是該參數設置爲 None ，cookie只能由設置它的站點讀取。
secure=False, 若是設置爲 True ，瀏覽器將經過HTTPS來回傳cookie。
httponly=False 只能http協議傳輸，沒法被JavaScript獲取
（不是絕對，底層抓包能夠獲取到也能夠被覆蓋）
): pass
刪除Cookie
def logout(request):
rep = redirect("/login/")
rep.delete_cookie("user") # 刪除用戶瀏覽器上以前設置的usercookie值
return rep
Cookie版登錄校驗示例：
def check_login(func):
@wraps(func)
def inner(request, *args, **kwargs):
next_url = request.get_full_path()
if request.get_signed_cookie("login", salt="SSS", default=None) == "yes":
# 已經登陸的用戶...
return func(request, *args, **kwargs)
else:
# 沒有登陸的用戶，跳轉剛到登陸頁面
return redirect("/login/?next={}".format(next_url))
return inner
def login(request):
if request.method == "POST":
username = request.POST.get("username")
passwd = request.POST.get("password")
if username == "xxx" and passwd == "dashabi":
next_url = request.GET.get("next")
if next_url and next_url != "/logout/":
response = redirect(next_url)
else:
response = redirect("/class_list/")
response.set_signed_cookie("login", "yes", salt="SSS")
return response
return render(request, "login.html")
留兩個小練習吧：
案例1:顯示上次訪問時間。
案例2:顯示上次瀏覽過的商品。
Session是服務器端技術，利用這個技術，服務器在運行時能夠 爲每個用戶的瀏覽器建立一個其獨享的session對象，因爲 session爲用戶瀏覽器獨享，因此用戶在訪問服務器的web資源時 ，能夠把各自的數據放在各自的session中，當用戶再去訪問該服務器中的其它web資源時，其它web資源再從用戶各自的session中 取出數據爲用戶服務。
Cookie雖然在必定程度上解決了「保持狀態」的需求，可是因爲Cookie自己最大支持4096字節，以及Cookie自己保存在客戶端，可能被攔截或竊取，所以就須要有一種新的東西，它能支持更多的字節，而且他保存在服務器，有較高的安全性。這就是Session。
問題來了，基於HTTP協議的無狀態特徵，服務器根本就不知道訪問者是「誰」。那麼上述的Cookie就起到橋接的做用。
咱們能夠給每一個客戶端的Cookie分配一個惟一的id，這樣用戶在訪問時，經過Cookie，服務器就知道來的人是「誰」。而後咱們再根據不一樣的Cookie的id，在服務器上保存一段時間的私密資料，如「帳號密碼」等等。
總結而言：Cookie彌補了HTTP無狀態的不足，讓服務器知道來的人是「誰」；可是Cookie以文本的形式保存在本地，自身安全性較差；因此咱們就經過Cookie識別不一樣的用戶，對應的在Session裏保存私密的信息以及超過4096字節的文本。
另外，上述所說的Cookie和Session實際上是共通性的東西，不限於語言和框架。
Django中Session相關方法
# 獲取、設置、刪除Session中數據
#取值 request.session['k1'] request.session.get('k1',None) #request.session這句是幫你從cookie裏面將sessionid的值取出來，將django-session表裏面的對應sessionid的值的那條記錄中的session-data字段的數據給你拿出來（並解密）,get方法就取出k1這個鍵對應的值
#設置值 request.session['k1'] = 123 request.session.setdefault('k1',123) # 存在則不設置
#幫你生成隨機字符串，幫你將這個隨機字符串和用戶數據（加密後）和過時時間保存到了django-session表裏面，幫你將這個隨機字符串以sessionid：隨機字符串的形式添加到cookie裏面返回給瀏覽器,這個sessionid名字是能夠改的，之後再說
#可是注意一個事情，django-session這個表，你不能經過orm來直接控制，由於你的models.py裏面沒有這個對應關係
#刪除值
del request.session['k1'] #django-session表裏面同步刪除
# 全部 鍵、值、鍵值對
request.session.keys()
request.session.values()
request.session.items()
# 會話session的key
session_key = request.session.session_key 獲取sessionid的值
# 將全部Session失效日期小於當前日期的數據刪除，將過時的刪除
request.session.clear_expired()
# 檢查會話session的key在數據庫中是否存在
request.session.exists("session_key") #session_key就是那個sessionid的值
# 刪除當前會話的全部Session數據
request.session.delete()
# 刪除當前的會話數據並刪除會話的Cookie。
request.session.flush() #經常使用，清空全部cookie---刪除session表裏的這個會話的記錄，
這用於確保前面的會話數據不能夠再次被用戶的瀏覽器訪問
例如，django.contrib.auth.logout() 函數中就會調用它。
# 設置會話Session和Cookie的超時時間
request.session.set_expiry(value)
* 若是value是個整數，session會在些秒數後失效。
* 若是value是個datatime或timedelta，session就會在這個時間後失效。
* 若是value是0,用戶關閉瀏覽器session就會失效。
* 若是value是None,session會依賴全局session失效策略。
Session詳細流程解析
Session版登錄驗證示例
from functools import wraps
def check_login(func):
@wraps(func)
def inner(request, *args, **kwargs):
next_url = request.get_full_path()
if request.session.get("user"):
return func(request, *args, **kwargs)
else:
return redirect("/login/?next={}".format(next_url))
return inner
def login(request):
if request.method == "POST":
user = request.POST.get("user")
pwd = request.POST.get("pwd")
if user == "alex" and pwd == "alex1234":
# 設置session
request.session["user"] = user
# 獲取跳到登錄頁面以前的URL
next_url = request.GET.get("next")
# 若是有，就跳轉回登錄以前的URL
if next_url:
return redirect(next_url)
# 不然默認跳轉到index頁面
else:
return redirect("/index/")
return render(request, "login.html")
@check_login
def logout(request):
# 刪除全部當前請求相關的session
request.session.delete()
return redirect("/login/")
@check_login
def index(request):
current_user = request.session.get("user", None)
return render(request, "index.html", {"user": current_user})
問題：同一個瀏覽器上，若是一個用戶已經登錄了，你若是在經過這個瀏覽器以另一個用戶來登錄，那麼究竟是第一個用戶的頁面仍是第二個用戶的頁面，有同窗是否是懵逼了，你想一想，一個瀏覽器和一個網站能保持兩個用戶的對話嗎？你登錄一下博客園試試，第一個用戶登錄的時候，沒有帶着sessionid，第二個用戶登錄的時候，帶着第一個用戶的sessionid，這個值在第二個用戶登錄以後，session就被覆蓋了，瀏覽器上的sessionid就是我第二個用戶的了，那麼你用第一個用戶再點擊其餘內容，你會發現，看到的都是第二個用戶的信息（注意：公衆都能訪問的a標籤不算）。還有，你想一想是否是你登錄一次就在django-session表裏面給你添加一條session記錄嗎？爲何呢？由於你想，若是是每一個用戶每次登錄都添加一條sesson的記錄，那麼這個用戶一年要登錄多少次啊，那你須要記錄多少次啊，你想一想，因此，你每次登錄的時候，都會將你以前登錄的那個session記錄給你更新掉，也就是說你登錄的時候，若是你帶着一個session_id，那麼不是新添加一條記錄，用的仍是django-session表裏面的前面那一次登錄的session_key隨機字符串，可是session_data和expire_date都變了，也就是說那條記錄的鑰匙仍是它，可是數據變了，有同窗又要問了，那我過了很久纔過來再登錄的，那個session_id都沒有了啊怎麼辦，你放心，你瀏覽器上的session_id沒有了的話，你django-session表裏的關於你這個用戶的session記錄確定被刪掉了。再想，登錄以後，你把登錄以後的網址拿到另一個瀏覽器上去訪問，能訪問嗎？固然不能啦，另一個瀏覽器上有你這個瀏覽器上的cookie嗎，沒有cookie能有session嗎？若是你再另一個瀏覽器上又輸入了用戶名和密碼登錄了，會發生什麼事情，django-session表裏面會多一條記錄，記着，一個網站對一個瀏覽器，是一個sessionid的，換一個瀏覽器客戶端，確定會生成另一個sessionid，django-session表裏面的session_key確定不一樣，可是session_data字段的數據確定是同樣的，固然了，這個還要看人家的加密規則。
Django中的Session配置
Django中默認支持Session，其內部提供了5種類型的Session供開發者使用。
1. 數據庫Session SESSION_ENGINE = 'django.contrib.sessions.backends.db' # 引擎（默認） 2. 緩存Session SESSION_ENGINE = 'django.contrib.sessions.backends.cache' # 引擎 SESSION_CACHE_ALIAS = 'default' # 使用的緩存別名（默認內存緩存，也能夠是memcache），此處別名依賴緩存的設置 3. 文件Session SESSION_ENGINE = 'django.contrib.sessions.backends.file' # 引擎 SESSION_FILE_PATH = None # 緩存文件路徑，若是爲None，則使用tempfile模塊獲取一個臨時地址tempfile.gettempdir() 4. 緩存+數據庫 SESSION_ENGINE = 'django.contrib.sessions.backends.cached_db' # 引擎 5. 加密Cookie Session SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies' # 引擎 其餘公用設置項： SESSION_COOKIE_NAME ＝ "sessionid" # Session的cookie保存在瀏覽器上時的key，即：sessionid＝隨機字符串（默認） SESSION_COOKIE_PATH ＝ "/" # Session的cookie保存的路徑（默認） SESSION_COOKIE_DOMAIN = None # Session的cookie保存的域名（默認） SESSION_COOKIE_SECURE = False # 是否Https傳輸cookie（默認） SESSION_COOKIE_HTTPONLY = True # 是否Session的cookie只支持http傳輸（默認） SESSION_COOKIE_AGE = 1209600 # Session的cookie失效日期（2周）（默認） SESSION_EXPIRE_AT_BROWSER_CLOSE = False # 是否關閉瀏覽器使得Session過時（默認） SESSION_SAVE_EVERY_REQUEST = False # 是否每次請求都保存Session，默認修改以後才保存（默認）
CBV中加裝飾器相關
CBV實現的登陸視圖
class LoginView(View):
def get(self, request):
"""
處理GET請求
"""
return render(request, 'login.html')
def post(self, request):
"""
處理POST請求
"""
user = request.POST.get('user')
pwd = request.POST.get('pwd')
if user == 'alex' and pwd == "alex1234":
next_url = request.GET.get("next")
# 生成隨機字符串
# 寫瀏覽器cookie -> session_id: 隨機字符串
# 寫到服務端session：
# {
# "隨機字符串": {'user':'alex'}
# }
request.session['user'] = user
if next_url:
return redirect(next_url)
else:
return redirect('/index/')
return render(request, 'login.html')
要在CBV視圖中使用咱們上面的check_login裝飾器，有如下三種方式：
from django.utils.decorators import method_decorator
1. 加在CBV視圖的get或post方法上
from django.utils.decorators import method_decorator
class HomeView(View):
def dispatch(self, request, *args, **kwargs):
return super(HomeView, self).dispatch(request, *args, **kwargs)
def get(self, request):
return render(request, "home.html")
@method_decorator(check_login)
def post(self, request):
print("Home View POST method...")
return redirect("/index/")
2. 加在dispatch方法上
from django.utils.decorators import method_decorator
class HomeView(View):
@method_decorator(check_login)
def dispatch(self, request, *args, **kwargs):
return super(HomeView, self).dispatch(request, *args, **kwargs)
def get(self, request):
return render(request, "home.html")
def post(self, request):
print("Home View POST method...")
return redirect("/index/")
由於CBV中首先執行的就是dispatch方法，因此這麼寫至關於給get和post方法都加上了登陸校驗。
3. 直接加在視圖類上，但method_decorator必須傳 name 關鍵字參數
若是get方法和post方法都須要登陸校驗的話就寫兩個裝飾器。
from django.utils.decorators import method_decorator
@method_decorator(check_login, name="get")
@method_decorator(check_login, name="post")
class HomeView(View):
def dispatch(self, request, *args, **kwargs):
return super(HomeView, self).dispatch(request, *args, **kwargs)
def get(self, request):
return render(request, "home.html")
def post(self, request):
print("Home View POST method...")
return redirect("/index/")
補充
CSRF Token相關裝飾器在CBV只能加到dispatch方法上，或者加在視圖類上而後name參數指定爲dispatch方法。
備註：
csrf_protect，爲當前函數強制設置防跨站請求僞造功能，即使settings中沒有設置全局中間件。
csrf_exempt，取消當前函數防跨站請求僞造功能，即使settings中設置了全局中間件。
from django.views.decorators.csrf import csrf_exempt, csrf_protect
from django.utils.decorators import method_decorator
class HomeView(View):
@method_decorator(csrf_exempt)
def dispatch(self, request, *args, **kwargs):
return super(HomeView, self).dispatch(request, *args, **kwargs)
def get(self, request):
return render(request, "home.html")
def post(self, request):
print("Home View POST method...")
return redirect("/index/")
或者
from django.views.decorators.csrf import csrf_exempt, csrf_protect
from django.utils.decorators import method_decorator
@method_decorator(csrf_exempt, name='dispatch')
class HomeView(View):
def dispatch(self, request, *args, **kwargs):
return super(HomeView, self).dispatch(request, *args, **kwargs)
def get(self, request):
return render(request, "home.html")
def post(self, request):
print("Home View POST method...")
return redirect("/index/")