cookie、session和中間件
- 2019 年 12 月 16 日
- 筆記
cookie和session
cookie與session原理
cookie是保存在瀏覽器上的鍵值對,session是保存在服務端的鍵值對,cookie和session存在的目的是保存用戶的登錄狀態,那麼為什麼有cookie和session呢?這時因為HTTP協議的無狀態、無連接的特點,也就是瀏覽器訪問過伺服器後如果斷開連接,伺服器不會記錄瀏覽器的訪問狀態,這時候就需要利用cookie和session保存用戶的登錄狀態。
cookie
cookie是保存在客戶端瀏覽器上的鍵值對,不過它是由服務端在用戶登錄的時候設置的。如果在瀏覽器端如果禁止cookie我們將無法登錄需要用戶登錄的網站這是服務端識別到瀏覽器禁用了cookie而做的優化。
Google瀏覽器查看cookie

右鍵檢查
Django操作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獲取(不是絕對,底層抓包可以獲取到也可以被覆蓋)
刪除cookie
def logout(request): rep = redirect("/login/") rep.delete_cookie("user") # 刪除用戶瀏覽器上之前設置的usercookie值 return rep
cookie登錄認證
from functools import wraps def check_login(func): '''登錄認證裝飾器''' @wraps(func) def inner(request, *args, **kwargs): next_url = request.get_full_path()#獲取用戶當前頁面的url if request.get_signed_cookie("login", salt="SSS", default=None) == "yes": # 已經登錄的用戶... return func(request, *args, **kwargs) else: # 沒有登錄的用戶,跳轉剛到登錄頁面 return redirect("/login/?next={}".format(next_url))#將當前的url保存到登錄頁面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 == "xxx": next_url = request.GET.get("next")#從登錄頁面url的後綴獲取用戶之前登錄的頁面的url if next_url and next_url != "/logout/": response = redirect(next_url)#登錄成功之後重定向到登錄頁面之前的頁面 else: response = redirect("/home/")#如果url後綴沒有資訊,就重定向到home頁面 response.set_signed_cookie("login", "yes", salt="SSS") return response return render(request, "login.html")
瀏覽器端的cookie

這裡需要說明的是Django在後端沒有專門用於存儲cookie的表,但是同一用戶在不同的瀏覽器登錄產生的cookie仍是不一樣的,只是cookie加密的時候需要使用用戶資訊,(如果只用字元串進行加密密鑰會比較短),如果使用用戶資訊(set_signed_cookie)會得到第一條加密資訊。
Django操作session
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['k1'] = 123 request.session.setdefault('k1',123) # 存在則不設置 del request.session['k1'] # 所有 鍵、值、鍵值對 request.session.keys() request.session.values() request.session.items() request.session.iterkeys() request.session.itervalues() request.session.iteritems() # 會話session的key request.session.session_key # 將所有Session失效日期小於當前日期的數據刪除 request.session.clear_expired() # 檢查會話session的key在資料庫中是否存在 request.session.exists("session_key") # 刪除當前會話的所有Session數據 request.session.delete() # 刪除當前的會話數據並刪除會話的Cookie。 request.session.flush() 這用於確保前面的會話數據不可以再次被用戶的瀏覽器訪問 例如,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進行設置,設置完成後需要執行數據遷移命令,將設置保存到資料庫的django_session中,這是Django默認的session值存儲表。Django在設置session時是針對瀏覽器的,如果同一台電腦的同一瀏覽器,多用戶登錄時在資料庫中只會產生一條記錄,但是不影響各個用戶對session值的取用。
request.session['k1'] = 'v1' 這句話Django內部幫你做的事情:
1.內部自動調用演算法生成一個隨機字元串(這個字元串是唯一的,如果同一用戶在不同的電腦上登錄得到的字元串是不一樣的,但是都是基於『k1』產生的。
2.在Django_session添加數據,(數據也是經過加密處理之後的)
保存到django_session表中的數據是
隨機字元串 加密之後的數據 失效時間

3.將產生的隨機字元串返回給瀏覽器,讓瀏覽器保存
sessionid:隨機字元串

通過上面兩張圖可以看出,瀏覽器端存的字元串就是資料庫中的session_key,而產生session的語句是request.session['k1'] = 'v1' ,取出使用request.session.get("v1"),而資料庫中的name是隨機產生的字元串,可以看出字元串是通過k1隨機生成的,k1和字元串是有某種轉換關係的。
獲取session
request.session.get('k1')
Django會自動去請求頭裡獲取cookie(sessionid),拿著sessionid所對應的隨機字元串去django_sessoion表中一一比對,如果比對上了,會將隨機字元串對應的數據獲取出來 自動放入request.session中供程式設計師調用,如果沒有就是一個空字典。
刪除session
request.session.delete() 客戶端和服務端全部刪除session,會根據瀏覽器的不同刪對應的數據
設置失效時間
request.session.set_expiry(value)
- 如果value是個整數,session會在些秒數後失效。
- 如果value是個datatime或timedelta,session就會在這個時間後失效。
- 如果value是0,用戶關閉瀏覽器session就會失效。
- 如果value是None,session會依賴全局session失效策略。
cookie與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 == "ylpb" and pwd == "xxx": # 設置session request.session["user"] = user # 獲取跳到登陸頁面之前的URL next_url = request.GET.get("next") # 如果有,就跳轉回登陸之前的URL if next_url: return redirect(next_url) # 否則默認跳轉到home頁面 else: return redirect("/home/") return render(request, "login.html") @check_login def logout(request): # 刪除所有當前請求相關的session request.session.delete() return redirect("/login/") @check_login def home(request): current_user = request.session.get("user", None) return render(request, "home.html", {"user": current_user})
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,默認修改之後才保存(默認)
django中間件
介紹
官方的說法:中間件是一個用來處理Django的請求和響應的框架級別的鉤子。它是一個輕量、低級別的插件系統,用於在全局範圍內改變Django的輸入和輸出。每個中間件組件都負責做一些特定的功能。
但是由於其影響的是全局,所以需要謹慎使用,使用不當會影響性能。
說的直白一點中間件是幫助我們在視圖函數執行之前和執行之後都可以做一些額外的操作,它本質上就是一個自定義類,類中定義了幾個方法,Django框架會在請求的特定的時間去執行這些方法。
由於中間件是全局的,當我們需要做一些全局性的功能時應該首先選擇中間件,如:全局的用戶登錄校驗、全局的用戶訪問頻率的校驗、全局的用戶許可權校驗(用中間件是相當簡單的),這裡需要說一點django的中間件是所有框架裡面做的最完善的,並且支援用戶自定義中間件。
我們一直都在使用中間件,只是沒有注意到而已,打開Django項目的Settings.py文件,看到下圖的MIDDLEWARE配置項。
MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ]
MIDDLEWARE配置項是一個列表(列表是有序的,記住這一點,後面你就知道為什麼要強調有序二字),列表中是一個個字元串,這些字元串其實是一個個類,也就是一個個中間件。這一個個字元串前面是文件夾和py文件,後面是一個個類如圖:

我們之前已經接觸過一個csrf相關的中間件了?我們一開始讓大家把他注釋掉,再提交post請求的時候,就不會被forbidden了,後來學會使用csrf_token之後就不再注釋這個中間件了。
那接下來就學習中間件中的方法以及這些方法什麼時候被執行。
自定義中間件
自定義中間件的方法
中間件可以定義五個方法,分別是:(主要的是process_request和process_response)
- process_request(self,request)
- process_view(self, request, view_func, view_args, view_kwargs)
- process_template_response(self,request,response)
- process_exception(self, request, exception)
- process_response(self, request, response)
以上方法的返回值可以是None或一個HttpResponse對象,如果是None,則繼續按照django定義的規則向後繼續執行,如果是HttpResponse對象,則直接將該對象返回給用戶。
自定義中間件示例


process_request和process_response
process_request有一個參數,就是request,這個request和視圖函數中的request是一樣的(在交給Django後面的路由之前,對這個request對象可以進行一系列的操作)。
由於request對象是一樣的,所以我們可以對request對象進行一系列的操作,包括request.變數名=變數值,這樣的操作,我們可以在後續的視圖函數中通過相同的方式即可獲取到我們在中間件中設置的值。
它的返回值可以是None也可以是HttpResponse對象。返回值是None的話,按正常流程繼續走,交給下一個中間件處理,如果是HttpResponse對象,Django將不執行視圖函數,而將相應對象返回給瀏覽器。
我們來看看多個中間件時,Django是如何執行其中的process_request方法的。
from django.utils.deprecation import MiddlewareMixin from django.shortcuts import HttpResponse class TestMiddleware(MiddlewareMixin): def process_request(self, request): print('test中間件') return HttpResponse('test') def process_response(self,request, response): print('process_response') return response class TestMiddleware2(MiddlewareMixin): def process_request(self, request): print('test中間件2') return HttpResponse('test2') def process_response(self,request, response): print('process_response2') return response
在settings.py的MIDDLEWARE配置項中註冊上述兩個自定義中間件:
MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', #'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'app01.TestMiddleware.TestMiddleware', 'app01.TestMiddleware.TestMiddleware2' ]
此時,我們訪問一個視圖,會發現終端中列印如下內容:
test中間件 process_response
當我們註銷第一個自定義中間件的return HttpResponse('test')後得到
test中間件 test中間件2 process_response2 process_response
我們可以得到如下結論
process_request
1.請求來的時候會按照settings配置文件中從上往下的順序,依次執行每一個中間件內部定義的process_request方法,如果中間件內部沒有該方法直接跳過執行下一個中間件。 2.該方法一旦返回了HttpResponse對象,那麼請求會立刻停止往後走 原路立即返回。
3.當process_request方法直接返回HttpResponse對象之後會直接從當前中間件裡面的process_respone往回走,沒有執行的中間件都不會再執行。
process_response
1.響應走的時候會按照settings配置文件中從下往上的順序 依次執行每一個中間件內部定義的process_response方法 2.該方法必須有兩個形參,並且必須返回response形參,不返回直接報錯 3.該方法返回什麼(HttpResponsed對象) 前端就能獲得什麼
中間件的其他方法
process_view(self,request,view_name,*args,**kwargs) 1.路由匹配成功之後執行視圖函數之前觸發。 2.如果該方法返回了HttpResponse對象 那麼會從下往上依次經過每一個中間件裡面的process_response方法。 process_template_response 1.當返回的對象中含有render屬性指向的是一個render方法的時候才會觸發 ,從下往上的順序執行。
def mdzz(request): print('我是視圖函數') def render(): return HttpResponse('xxx') obj = HttpResponse('yyy') obj.render = render return obj
process_exception
當視圖函數中出現錯誤會自動觸發順序是從下往上。
上面這五個方法會在特定的階段自動觸發。