【2022-09-09】Django框架(九)
Django框架(九)
cookie與session簡介
網址的發展史：
1、起初網站都沒有儲存使用者功能的需求，所有使用者訪問返回的結果都是一樣的。
比如：新聞網頁，部落格網頁，小說... (這些網頁是不需要登入後才能訪問的，每個人訪問的結果都一樣)
2、後來出現了一些需要儲存使用者資訊的網站
比如：支付寶，淘寶，京東.... (使用者登入後只要不長時間不訪問就不會退出登入)
舉例
以登入功能為例： # 如果不儲存使用者的登入狀態，也就是意味著使用者每次訪問都需要重複的輸入，使用者名稱和密碼，甚至於如果使用者從該地址點選某連線，跳轉到另一個子網頁，也需要重複的輸入使用者名稱和密碼，如果頁面卡了，重新整理頁面也可能需要重新登入，輸入使用者名稱和密碼。(這樣的頁面使用者還會用嗎？) 那麼這時開發者們就想到了一個解決方案: # 當用戶第一次登入成功之後，將使用者的使用者名稱密碼返回給使用者瀏覽器，讓使用者瀏覽器儲存在本地，之後使用者再次訪問網站的時候瀏覽器自動將儲存在瀏覽器上的使用者名稱和密碼傳送給服務端，服務端獲取之後自動驗證 # 但是早期這種方式具有非常大的安全隱患(因為這中方式是銘文儲存的，完全可以被別人找到看到) 優化： # 當用戶登陸成功之後，服務端隨機產生一個隨機字串(在服務端儲存資料，用k：v鍵值對的形式)，交由客戶端瀏覽器儲存。之後訪問服務端的時候，都帶著該隨機字串，服務端去資料庫中比對是否有對應的隨機字串從而獲取到對應的使用者資訊。 # 但是如果有人截獲到了某使用者的該隨機字串，那麼就可以冒充他，其實也是有安全隱患的 # 在web領域是沒有絕對的安全也沒有絕對的不安全的。
什麼是cookie？
cookie實際上是一小段的文字資訊。客戶端請求伺服器，如果伺服器需要記錄該使用者的狀態，就使用response向客戶端瀏覽器頒發一個cookie。客戶端瀏覽器會把cookie儲存起來。當瀏覽器再次請求該網站時，瀏覽器就會把請求地址和cookie一同給伺服器。伺服器檢查該cookie，從而判斷使用者的狀態。伺服器還可以根據需要修改cookie的內容。 # 表現形式： k：v鍵值對(可以存多個)
什麼是session？
session是另一種記錄客戶狀態的機制。不同的是cookie儲存在客戶端瀏覽器中，而session儲存在伺服器上。客戶端瀏覽器訪問伺服器的時候，伺服器把客戶端資訊以某種形式記錄在伺服器上，這就是session。客戶端瀏覽器再次訪問時只需要從該session中查詢該客戶的狀態就可以了。 如果說cookie機制是通過檢查客戶身上的“通訊證”，那麼session機制就是通過檢查伺服器上的“客戶明細表”來確認客戶身份。 # 表現形式 資料時儲存在服務端的並且他的表現形式一般也是k：v鍵值對(可以有多個) 1.cookie就是儲存在客戶端瀏覽器上的資訊 2.session就是儲存在服務端上的資訊 3.session是基於cookie工作的。(大部分的儲存使用者狀態的操作都需要使用到cookie)
瞭解了cookie與session的工作原理，接下來我們來看他們具體是怎麼使用的。
cookie操作
# 雖然cookie是服務端告訴客戶端瀏覽器需要儲存內容 # 但是如果客戶端瀏覽器可以選擇拒絕，如果客戶端瀏覽器禁止了cookie，那麼客戶端瀏覽器就無法儲存服務端傳送過來的內容，那麼只要是需要記錄使用者狀態的網站登入功能都無法使用了。 # 如果在瀏覽器上 >> 隱私設定和安全性 >> Cookie及其他網站資料 >> 阻止了cookie # 那麼此時所有需要記錄使用者狀態的網站的登入功能都無法使用，因為網站無法儲存服務端發來的使用者名稱密碼，永遠無法校驗使用者名稱和密碼，這樣就無法登入進去
刪除當前頁面的cookie
# 我們可以在頁面上手動刪除我們的cookie，這樣瀏覽器就沒有記錄我們的登入資訊，服務端無法驗證，這樣就需要我們重新登入。
實操
# 我們之前操作檢視函式的返回值 return HttpResponse() return render() return redirect() # 那麼如果想要操作cookie就需要我們這樣編寫： obj1 = HttpResponse() # 操作cookie return obj1 obj2 = render() # 操作cookie return obj2 obj3 = redirect() # 操作cookie return obj3 # 如果你想要操作cookie，你就不得不利用obj物件
# cookie關鍵字：
設定cookie：obj.set_cookie(key,value) # 需要使用到上述提到的物件
加鹽處理：obj.set_signed_cookie(key,value,salt='鹽')
獲取cookie：request.COOKIES.get('key')
加鹽資料獲取：request.get_signed_cookie(key,salt='鹽')
示例
# 我們來看一個真正的登入功能
def login(request):
if request.method == 'POST': # 查詢post請求資料
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'gary' and password == '123':
return redirect('/home/') # 如果使用者輸入的匹配就跳轉到home頁面
return render(request,'login.html')
def home(request):
return HttpResponse('我是home頁面,只有登陸的使用者再能進來')
# 但是上述存在一個問題：我們需求是必須輸入正確的使用者名稱密碼才可以進入home頁面，但是我們直接訪問/home/路由也可以直接進入home頁面對吧。那麼這就就需要用到cookie
優化
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'gary' and password == '123':
**************************應用cookie區域*************************************
obj = redirect('/home/') # 使用者名稱密碼正確跳轉到home主頁
# 讓瀏覽器記錄cookie資料
obj.set_cookie('username','gary222') # 這裡就可以隨便放一個鍵值對，可以直接放一個使用者的使用者名稱名也可以,目的是為了讓客戶端瀏覽器儲存
# 瀏覽器不單單的幫你存這個鍵值對
# 每次訪問的時候還會帶著他過來進行驗證
return obj
*****************************************************************************
return render(request,'login.html')
def home(request):
# 獲取cookie資訊 判斷是否有cookie
if request.COOKIES.get('username') == 'gary222': # 只有攜帶cookie才可以進入home頁面
return HttpResponse('我是home頁面,只有登陸的使用者再能進來')
# 如果沒有登入則跳轉到登陸頁面
return redirect('/login/')
# 這樣我們想要直接訪問home頁面就不允許了，必須登入之後才能訪問，並且登入之後會記錄登入狀態，下次再次直接訪問home頁面也是可以訪問的。
不足之處
# 不足之處1： # 現在我們只有一個home頁面，那麼如果有很多頁面呢，是不是在檢視函式很多的時候都要做一次判斷，判斷是否存在cookie，判斷是否已經登陸，那麼此時我們應該在每個也面前加一個校驗使用者是否已經登陸的裝飾器。 # 不足之處2： # 比如： 使用者訪問index頁面，然後跳轉到login登入頁面進行登入，但是當用戶登入後，此時跳轉的還是home頁面，這樣是不合理的。需要的是使用者訪問什麼頁面，登陸後跳轉的就是使用者想要的頁面，而不是主頁面。
實現不足之處1：
# 增加驗證是否登入的裝飾器：
def login_auth(func): # 此時func就是home函式
def inner(request,*args,**kwargs):
if request.COOKIES.get('username'): # 判斷cookie是否有值
res = func(request,*args,**kwargs) # 有值則執行對應函式
return res
else: # 沒有cookie值則跳轉登入頁面
return redirect('/login/')
return inner
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'gary' and password == '123':
obj = redirect('/home/')
# 讓瀏覽器記錄cookie資料
obj.set_cookie('username','gary222') # 這裡就可以隨便放一個鍵值對了，可以直接放一個使用者的使用者名稱名也可以
# 瀏覽器不單單的幫你存這個鍵值對
# 每次訪問的時候還會帶著他過來
return obj
return render(request,'login.html')
@login_auth # 新增語法糖
def home(request):
return HttpResponse('我是home頁面,只有登陸的使用者再能進來')
@login_auth
def index(request):
return HttpResponse('我是index頁面')
@login_auth
def shop(request):
return HttpResponse('我是shop頁面')
# 此時就解決了多個頁面程式碼冗餘的問題。
實現不足之處2：
""" 使用者如果在沒有登陸的情況下想訪問一個需要登陸的頁面 那麼先跳轉到登陸頁面 當用戶輸入正確的使用者名稱和密碼之後 應該跳轉到使用者之前想要訪問的頁面去 而不是直接寫死 """ # 訪問登陸頁面就兩種情況： 要麼是直接訪問登陸頁面的，要麼是通過裝飾器跳轉到登入頁面的 補充：獲取當前使用者請求的url # print(request.path_info) # 該方法不獲取路由後面的引數 # print(request.get_full_path()) # 能夠獲取到使用者上一次想要訪問的url(上一次訪問的就是跳轉到login頁面之前想要訪問的頁面)(同樣可獲取到引數)
def login_auth(func):
def inner(request,*args,**kwargs):
target_url = request.get_full_path() # 獲取使用者想要訪問的url
if request.COOKIES.get('username'):
res = func(request,*args,**kwargs)
return res
else:
return redirect('/login/?next=%s'%target_url)
# 這樣跳轉到登入頁面後，url後面會攜帶(?next='上一次使用者訪問的url頁面')的引數
return inner
# 那麼此時就可以通過request.GET的方法拿到後面的引數，然後指定下一次跳轉的頁面
def login(request):
if request.method == 'POST':
username = request.POST.get('username')
password = request.POST.get('password')
if username == 'gary' and password == '123':
*****************************************************************
target_url = request.GET.get('next') # 這個結果可能是none(可能使用者直接訪問login)
if target_url: # 如果引數有指
obj = redirect(target_url) # 則跳轉到指定路由的頁面
else:
obj = redirect('/home/') # 如果使用者直接訪問的是登入頁面則返回指定的home頁面
*****************************************************************
obj.set_cookie('username','gary222')
return obj
return render(request,'login.html')
引數補充
1、# 可以設定超時時間：cookie可以存在多長時間，過了時間就自動清除cookie，不儲存登入狀態則下次需要重新登入。
引數：
max_age=時間限制(以秒為單位)
expires=時間限制(以秒位單位)
兩者區別：
在設定cookie的時候可以新增一個超時時間
obj.set_cookie('username', 'jason666',max_age=3,expires=3)
max_age
expires
兩者都是設定超時時間的 並且都是以秒為單位
需要注意的是 針對IE瀏覽器需要使用expires
2、主動刪除cookie(類似於退出登入/登出功能)
@login_auth # 注意退出登入也是登入後才能操作的所以需要新增裝飾器
def logout(request):
obj = redirect('/login/')
obj.delete_cookie('username')
return obj
session操作
# 設定session
request.session['key'] = value
# 獲取session
request.session.get('key')
# session資料是儲存在服務端的，給客戶端返回的是一個隨機字串的形式。
# 不是(key:value)的形式
# 而(sessionid:隨機字串)的形式
設定session
urls.py
# 設定session
url(r'set_session',views.set_session)
views.py
def set_session(request):
request.session['hobby'] = 'girl' # 設定session給前端返回一個隨機字串
return HttpResponse('hello 小姐姐！')
# 訪問：
# 上述情況是因為什麼呢？
# 這是因為，上述提到session的資料是儲存在服務端的，那儲存到那裡了呢？
所以需要給session一個儲存資料的地方，在預設情況下操作session的時候需要django預設的一張django_session表。
我們是否還記得，在做資料庫遷移命令的時候，會自動創建出很多我們不認識的表，那麼這裡就有我們需要的django_session表。
# 資料庫遷移命令：
makemigrations
migrate
再次訪問
# 過期時間： django預設的session過期時間是14天，但是也可以認為的修改它。
獲取session
def get_session(request):
print(request.session.get('hobby'))
return HttpResponse('下次再見！')
# 設定session內部發生了那些事：
1.django內部會自動幫你生成一個隨機字串
2.django內部自動將隨機字串和對應的資料村粗帶django_session表中
3.將產生的隨機字串返回給客戶端瀏覽器儲存
# 獲取session內部發生的那些事：
1.自動從瀏覽器請求中獲取sessionid對應的隨機字串
2.拿著該隨機字串去django_session表中查詢對應的資料
3.如果比對上了，則將對應的資料(session_data)取出並以字典的形式封裝到request.session中
如果比對不上，則request.session.get()返回None
研究:如果設定多個session
def set_session(request):
request.session['hobby'] = 'girl'
request.session['hobby1'] = 'girl1'
request.session['hobby2'] = 'girl2'
request.session['hobby3'] = 'girl3'
return HttpResponse('hello 小姐姐！')
# 可同時設定多個session，但是隻佔用一條記錄
# 並且取得時候都可以取到。
def get_session(request):
print(request.session.get('hobby'))
print(request.session.get('hobby1'))
print(request.session.get('hobby2'))
print(request.session.get('hobby3'))
return HttpResponse('下次再見！')
總結
django_session表中資料條數是取決於瀏覽器的 同一個計算機上(同一個ip地址)同一個瀏覽器只會有一條資料有效(當session過期的時候，可能會出現多條資料對應一個瀏覽器，但是該現象不會持續很久，內部會自動識別過期得資料並清除，也可以手動清除或通過程式碼清除。) # 這麼做的目的： 主要是為了節省服務端資料庫資源
設定過期時間
# 格式：request.session.set_expiry()
括號內可以放四種類型的引數
1.整數 多少秒
2.日期物件 到指定日期就失效
3.0 一旦當前瀏覽器視窗關閉立刻失效
4.不寫 失效時間就取決於django內部全域性session預設的失效時間
清除session
# 清除session request.session.delete() # 只刪服務端的 客戶端的不刪 request.session.flush() # 瀏覽器和服務端都清空(推薦使用)
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得門戶：
1.請求來的時候需要先經過中介軟體才能到達真正的django後端
(瀏覽器給後端傳送請求必須經過中介軟體)
2.響應走的時候最後也需要經過中介軟體才能傳送出去
(後端給瀏覽器返回資料的時候也需要經過中介軟體)
# Django自帶7箇中間件
Django中介軟體程式碼
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',
]
# 我們來看這7箇中間件：他們其實並不是一個字串，他們其實是一個模組的路徑
'django.contrib.sessions.middleware.SessionMiddleware'
相當於：
from django.contrib.sessions.middleware import SessionMiddleware
我們來看一下這幾個中介軟體有什麼規律：
Django支援程式設計師自定義中介軟體而且暴露給程式設計師五個可以自定義得方法：
1.常用：
process_request
process_response
2.瞭解：
process_view
process_template_response
process_exception
如何自定義中介軟體
第一步：在專案名或者應用名下建立一個任意名稱的資料夾
第二步：在該資料夾內建立一個任意名稱的py檔案
第三步：在該py檔案內需要書寫類(這個類必須繼承MiddlewareMixin)
然後在這個類裡面就可以自定義五個方法了
(這五個方法並不是全部都需要書寫，用幾個寫幾個)
第四步：需要將類的路徑以字串的形式註冊到配置檔案中才能生效
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',
'你自己寫的中介軟體的路徑1',
'你自己寫的中介軟體的路徑2',
'你自己寫的中介軟體的路徑3',
]
我們根據上面的步驟來自定義中介軟體來研究這5個方法
process_request
自定義的mymidd.py
# 需要匯入模組來繼承該模組
from django.utils.deprecation import MiddlewareMixin
class MyMiddleware1(MiddlewareMixin):
def process_request(self,request):
print('我是第一個自定義中介軟體裡得process_request方法')
class MyMiddleware2(MiddlewareMixin):
def process_request(self,request):
print('我是第二個自定義中介軟體裡得process_request方法')
setting.py
# 註冊自己的中介軟體(在應用下建立的，路徑會有提示，但是如果在專案下建立的就沒有提示了)
MIDDLEWARE = [
'app01.mymiddleware.mymidd.MyMiddleware1',
'app01.mymiddleware.mymidd.MyMiddleware2'
]
views.py
def index(request):
print('我是檢視函式index')
return HttpResponse('index')
我們在把中介軟體註冊位置換一下看看列印是什麼結果：
MIDDLEWARE = [
'app01.mymiddleware.mymidd.MyMiddleware2',
'app01.mymiddleware.mymidd.MyMiddleware1'
]
# 我們給自定義的中介軟體返回一個HttpResponse物件：
class MyMiddleware1(MiddlewareMixin):
def process_request(self,request):
print('我是第1個自定義中介軟體裡得process_request方法')
return HttpResponse('我是第1個自定義中介軟體裡得process_request方法的返回值')
總結process_request:
1.請求來的時候需要經過每一箇中間件裡面的process_request方法 結果的順序是按照配置檔案中註冊的中介軟體從上往下的順序依次執行 2.如果中介軟體裡面沒有定義該方法，那麼直接跳過執行下一個中介軟體 3.如果該方法返回了HttpResponse物件，那麼請求將不再繼續往後執行 而是直接原路返回(校驗失敗不允許訪問...) # process_request方法就是用來做全域性相關的所有限制功能
process_response
class MyMiddleware1(MiddlewareMixin):
def process_request(self,request):
print('我是第1個自定義中介軟體裡得process_request方法')
def process_response(self,request,response):
print('我是第1個自定義中介軟體裡得process_response方法')
return response
class MyMiddleware2(MiddlewareMixin):
def process_request(self,request):
print('我是第2個自定義中介軟體裡得process_request方法')
def process_response(self,request,response):
print('我是第2個自定義中介軟體裡得process_response方法')
return response
1.響應走的時候需要結果每一箇中間件裡面的process_response方法
該方法有兩個額外的引數request,response
2.該方法必須返回一個HttpResponse物件
1.預設返回的就是形參response
2.你也可以自己返回自己的
3.順序是按照配置檔案中註冊了的中介軟體從下往上依次經過
如果你沒有定義的話 直接跳過執行下一個
研究如果response返回自己的HttpResponse回事怎樣的結果：
class MyMiddleware1(MiddlewareMixin):
def process_request(self,request):
print('我是第1個自定義中介軟體裡得process_request方法')
def process_response(self,request,response):
print('我是第1個自定義中介軟體裡得process_response方法')
return HttpResponse('我是中介軟體1')
class MyMiddleware2(MiddlewareMixin):
def process_request(self,request):
print('我是第2個自定義中介軟體裡得process_request方法')
def process_response(self,request,response):
print('我是第2個自定義中介軟體裡得process_response方法')
return response
# 結果：
# 研究如果在第一個process_request方法就已經返回了HttpResponse物件，那麼響應走的時候是經過所有的中介軟體裡面的process_response還是有其他情況
class MyMiddleware1(MiddlewareMixin):
def process_request(self,request):
print('我是第1個自定義中介軟體裡得process_request方法')
return HttpResponse('中介軟體1request') # 返回HttpResponse
def process_response(self,request,response):
print('我是第1個自定義中介軟體裡得process_response方法')
return response
class MyMiddleware2(MiddlewareMixin):
def process_request(self,request):
print('我是第2個自定義中介軟體裡得process_request方法')
def process_response(self,request,response):
print('我是第2個自定義中介軟體裡得process_response方法')
return response
process_view
# 具體使用：
def process_view(self,request,view_name,*args,**kwargs):
print(view_name,args,kwargs)
print('我是第二個自定義中介軟體中的process_view方法')
# 執行順序:
路由匹配成功之後執行檢視函式之前，會自動執行中介軟體裡面的該方法
順序是按照配置檔案中註冊的中介軟體從上往下的順序依次執行
# 所以在檢視函式提交之前需要新增額外的操作可以在這個方法裡做。
process_template_response
返回的HttpResponse物件有render屬性的時候才會觸發 順序是按照配置檔案中註冊了的中介軟體從下往上依次經過
process_exception
當檢視函式中出現異常的情況下觸發 順序是按照配置檔案中註冊了的中介軟體從下往上依次經過
「其他文章」
- 記一次批量更新整型型別的列 → 探究 UPDATE 的使用細節
- 編碼中的Adapter，不僅是一種設計模式，更是一種架構理念與解決方案
- 執行緒池底層原理詳解與原始碼分析
- 30分鐘掌握 Webpack
- 線性迴歸大結局(嶺(Ridge)、 Lasso迴歸原理、公式推導)，你想要的這裡都有
- Django 之路由層
- 【前端必會】webpack loader 到底是什麼
- day42-反射01
- 中心化決議管理——雲端分析
- HashMap底層原理及jdk1.8原始碼解讀
- 詳解JS中 call 方法的實現
- 列印 Logger 日誌時，需不需要再封裝一下工具類？
- 初識設計模式 - 代理模式
- 設計模式---享元模式
- 密碼學奇妙之旅、01 CFB密文反饋模式、AES標準、Golang程式碼
- [ML從入門到入門] 支援向量機：從SVM的推導過程到SMO的收斂性討論
- 從應用訪問Pod元資料-DownwardApi的應用
- Springboot之 Mybatis 多資料來源實現
- Java 泛型程式設計
- CAS核心思想、底層實現