中間件

中間件介紹

什么是中間件？

官方的說法：中間件是一個用來處理Django的請求和響應(yīng)的框架級別的鉤子。它是一個輕量、低級別的插件系統(tǒng)，用于在全局范圍內(nèi)改變Django的輸入和輸出。每個中間件組件都負責(zé)做一些特定的功能。

但是由于其影響的是全局，所以需要謹慎使用，使用不當(dāng)會影響性能。

我們一直都在使用中間件，只是沒有注意到而已，打開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配置項是一個列表，列表中是一個個字符串，這些字符串其實是一個個類，也就是一個個中間件。

我們之前已經(jīng)接觸過一個csrf相關(guān)的中間件了？我們一開始讓大家把他注釋掉，再提交post請求的時候，就不會被forbidden了，后來學(xué)會使用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，則繼續(xù)按照django定義的規(guī)則向后繼續(xù)執(zhí)行，如果是HttpResponse對象，則直接將該對象返回給用戶。

自定義一個中間件示例（自定義之后要在MIDDLEWARE中注冊才有用）

from django.utils.deprecation import MiddlewareMixinclass MD1(MiddlewareMixin):def process_request(self, request):print("MD1里面的 process_request")def process_response(self, request, response):print("MD1里面的 process_response")return response

　　上面中間件的作用分別為在請求之前和請求之后在控制臺打印一句話

process_request

process_request有一個參數(shù)，就是request，這個request和視圖函數(shù)中的request是一樣的。

它的返回值可以是None也可以是HttpResponse對象。返回值是None的話，按正常流程繼續(xù)走，交給下一個中間件處理，如果是HttpResponse對象，Django將不執(zhí)行視圖函數(shù)，而將相應(yīng)對象返回給瀏覽器。

我們來看看多個中間件時，Django是如何執(zhí)行其中的process_request方法的。

from django.utils.deprecation import MiddlewareMixinclass MD1(MiddlewareMixin):def process_request(self, request):print("MD1里面的 process_request")class MD2(MiddlewareMixin):def process_request(self, request):print("MD2里面的 process_request")pass

　　在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','middlewares.MD1', # 自定義中間件MD1'middlewares.MD2' # 自定義中間件MD2 ]

　　此時，我們訪問一個視圖，會發(fā)現(xiàn)終端中打印如下內(nèi)容：

MD1里面的 process_request MD2里面的 process_request app01 中的 index視圖

　　把MD1和MD2的位置調(diào)換一下，再訪問一個視圖，會發(fā)現(xiàn)終端中打印的內(nèi)容如下：

MD2里面的 process_request MD1里面的 process_request app01 中的 index視圖

　　看結(jié)果我們知道：視圖函數(shù)還是最后執(zhí)行的，MD2比MD1先執(zhí)行自己的process_request方法。

在打印一下兩個自定義中間件中process_request方法中的request參數(shù)，會發(fā)現(xiàn)它們是同一個對象。

由此總結(jié)一下：

中間件的process_request方法是在執(zhí)行視圖函數(shù)之前執(zhí)行的。

當(dāng)配置多個中間件時，會按照MIDDLEWARE中的注冊順序，也就是列表的索引值，從前到后依次執(zhí)行的。

不同中間件之間傳遞的request都是同一個對象

process_response

執(zhí)行順序：
按照注冊順序的倒序（在settings.py里面設(shè)置中 從下到上的順序）
何時執(zhí)行：
請求有響應(yīng)的時候
返回值：
必須返回一個response對象

from django.utils.deprecation import MiddlewareMixinclass MD1(MiddlewareMixin):def process_request(self, request):print("MD1里面的 process_request")def process_response(self, request, response):print("MD1里面的 process_response")return responseclass MD2(MiddlewareMixin):def process_request(self, request):print("MD2里面的 process_request")passdef process_response(self, request, response):print("MD2里面的 process_response")return response

　　終端的輸出：

MD2里面的 process_request MD1里面的 process_request app01 中的 index視圖 MD1里面的 process_response MD2里面的 process_response

process_view

process_view(self, request, view_func, view_args, view_kwargs)

該方法有四個參數(shù):

request是HttpRequest對象。

view_func是Django即將使用的視圖函數(shù)。 （它是實際的函數(shù)對象，而不是函數(shù)的名稱作為字符串。）

view_args是將傳遞給視圖的位置參數(shù)的列表.

view_kwargs是將傳遞給視圖的關(guān)鍵字參數(shù)的字典。 view_args和view_kwargs都不包含第一個視圖參數(shù)（request）。

Django會在調(diào)用視圖函數(shù)之前調(diào)用process_view方法。

它應(yīng)該返回None或一個HttpResponse對象。 如果返回None，Django將繼續(xù)處理這個請求，執(zhí)行任何其他中間件的process_view方法，然后在執(zhí)行相應(yīng)的視圖。 如果它返回一個HttpResponse對象，Django不會調(diào)用適當(dāng)?shù)囊晥D函數(shù)。 它將執(zhí)行中間件的process_response方法并將應(yīng)用到該HttpResponse并返回結(jié)果。

?給MD1和MD2添加process_view方法:

from django.utils.deprecation import MiddlewareMixinclass MD1(MiddlewareMixin):def process_request(self, request):print("MD1里面的 process_request")def process_response(self, request, response):print("MD1里面的 process_response")return responsedef process_view(self, request, view_func, view_args, view_kwargs):print("-" * 80)print("MD1 中的process_view")print(view_func, view_func.__name__)class MD2(MiddlewareMixin):def process_request(self, request):print("MD2里面的 process_request")passdef process_response(self, request, response):print("MD2里面的 process_response")return responsedef process_view(self, request, view_func, view_args, view_kwargs):print("-" * 80)print("MD2 中的process_view")print(view_func, view_func.__name__)

　　訪問index視圖函數(shù)，看一下輸出結(jié)果：

MD2里面的 process_request MD1里面的 process_request -------------------------------------------------------------------------------- MD2 中的process_view <function index at 0x000001DE68317488> index -------------------------------------------------------------------------------- MD1 中的process_view <function index at 0x000001DE68317488> index app01 中的 index視圖 MD1里面的 process_response MD2里面的 process_response

　　process_view方法是在process_request之后，視圖函數(shù)之前執(zhí)行的，執(zhí)行順序按照MIDDLEWARE中的注冊順序從前到后順序執(zhí)行的

process_exception

process_exception(self, request, exception)

該方法兩個參數(shù):

一個HttpRequest對象

一個exception是視圖函數(shù)異常產(chǎn)生的Exception對象。

這個方法只有在視圖函數(shù)中出現(xiàn)異常了才執(zhí)行，它返回的值可以是一個None也可以是一個HttpResponse對象。如果是HttpResponse對象，Django將調(diào)用模板和中間件中的process_response方法，并返回給瀏覽器，否則將默認處理異常。如果返回一個None，則交給下一個中間件的process_exception方法來處理異常。它的執(zhí)行順序也是按照中間件注冊順序的倒序執(zhí)行。

執(zhí)行順序：
按照注冊順序的倒序（在settings.py里面設(shè)置中 從下到上的順序）
何時執(zhí)行：
視圖函數(shù)中拋出異常的時候才執(zhí)行
返回值：
返回None,繼續(xù)執(zhí)行后續(xù)中間件的process_exception
返回response

process_template_response（用的比較少）

process_template_response(self, request, response)
執(zhí)行順序：
按照注冊順序的倒序（在settings.py里面設(shè)置中 從下到上的順序）
何時執(zhí)行：
視圖函數(shù)執(zhí)行完，在執(zhí)行視圖函數(shù)返回的響應(yīng)對象的render方法之前
返回值：
返回None,繼續(xù)執(zhí)行后續(xù)中間件的process_exception
返回response

中間件的執(zhí)行流程

上一部分，我們了解了中間件中的5個方法，它們的參數(shù)、返回值以及什么時候執(zhí)行，現(xiàn)在總結(jié)一下中間件的執(zhí)行流程。

請求到達中間件之后，先按照正序執(zhí)行每個注冊中間件的process_reques方法，process_request方法返回的值是None，就依次執(zhí)行，如果返回的值是HttpResponse對象，不再執(zhí)行后面的process_request方法，而是執(zhí)行當(dāng)前對應(yīng)中間件的process_response方法，將HttpResponse對象返回給瀏覽器。也就是說：如果MIDDLEWARE中注冊了6個中間件，執(zhí)行過程中，第3個中間件返回了一個HttpResponse對象，那么第4,5,6中間件的process_request和process_response方法都不執(zhí)行，順序執(zhí)行3,2,1中間件的process_response方法。

?

process_request方法都執(zhí)行完后，匹配路由，找到要執(zhí)行的視圖函數(shù)，先不執(zhí)行視圖函數(shù)，先執(zhí)行中間件中的process_view方法，process_view方法返回None，繼續(xù)按順序執(zhí)行，所有process_view方法執(zhí)行完后執(zhí)行視圖函數(shù)。加入中間件3 的process_view方法返回了HttpResponse對象，則4,5,6的process_view以及視圖函數(shù)都不執(zhí)行，直接從最后一個中間件，也就是中間件6的process_response方法開始倒序執(zhí)行。

process_template_response和process_exception兩個方法的觸發(fā)是有條件的，執(zhí)行順序也是倒序。總結(jié)所有的執(zhí)行流程如下：

?

?

中間件版登錄驗證?

中間件版的登錄驗證需要依靠session，所以數(shù)據(jù)庫中要有django_session表。

urls.py

from django.conf.urls import url from app01 import viewsurlpatterns = [url(r'^index/$', views.index),url(r'^login/$', views.login, name='login'), ]

views.py

from django.shortcuts import render, HttpResponse, redirectdef index(request):return HttpResponse('this is index')def home(request):return HttpResponse('this is home')def login(request):if request.method == "POST":user = request.POST.get("user")pwd = request.POST.get("pwd")if user == "Q1mi" and pwd == "123456":# 設(shè)置sessionrequest.session["user"] = user# 獲取跳到登陸頁面之前的URLnext_url = request.GET.get("next")# 如果有，就跳轉(zhuǎn)回登陸之前的URLif next_url:return redirect(next_url)# 否則默認跳轉(zhuǎn)到index頁面else:return redirect("/index/")return render(request, "login.html")

login.html

<!DOCTYPE html> <html lang="en"> <head><meta charset="UTF-8"><meta http-equiv="x-ua-compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1"><title>登錄頁面</title> </head> <body> <form action="{% url 'login' %}"><p><label for="user">用戶名：</label><input type="text" name="user" id="user"></p><p><label for="pwd">密 碼：</label><input type="text" name="pwd" id="pwd"></p><input type="submit" value="登錄"> </form> </body> </html>

middlewares.py

class AuthMD(MiddlewareMixin):white_list = ['/login/', ] # 白名單balck_list = ['/black/', ] # 黑名單def process_request(self, request):from django.shortcuts import redirect, HttpResponsenext_url = request.path_infoprint(request.path_info, request.get_full_path())if next_url in self.white_list or request.session.get("user"):returnelif next_url in self.balck_list:return HttpResponse('This is an illegal URL')else:return redirect("/login/?next={}".format(next_url))

在settings.py中注冊

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','middlewares.AuthMD', ]

AuthMD中間件注冊后，所有的請求都要走AuthMD的process_request方法。

訪問的URL在白名單內(nèi)或者session中有user用戶名，則不做阻攔走正常流程；

如果URL在黑名單中，則返回This is an illegal URL的字符串；

正常的URL但是需要登錄后訪問，讓瀏覽器跳轉(zhuǎn)到登錄頁面。

注：AuthMD中間件中需要session，所以AuthMD注冊的位置要在session中間的下方。

Django請求流程圖

Django 的 CSRF 保護機制

• 每次初始化一個項目時都能看到 django.middleware.csrf.CsrfViewMiddleware 這個中間件
  • csrf是基于中間件實現(xiàn)的，那么是放在哪個中間件里的呢？---放在_view中間件里
  • 為什么放在_view里？原因：因為CBV的csrf有個裝飾器，啟用或棄用csrf，但是_request只是獲得視圖函數(shù)，_view才是執(zhí)行視圖函數(shù)，這里才能判斷出哪個啟用csrf，所以是放在_view里的
• 每次在模板里寫 form 時都知道要加一個 {% csrf_token %} tag
• 每次發(fā) ajax POST 請求，都需要加一個 X_CSRFTOKEN 的 header

什么是 CSRF?

CSRF, Cross Site Request Forgery,?跨站點偽造請求。

舉例來講，當(dāng)你看小姐姐照片的同時，登陸了銀行網(wǎng)站，然后你銀行賬戶還沒有退出，這時，你又回去看小姐姐，點擊了小姐姐的圖片，但是，小姐姐的圖片上有個鏈接，正好是一個post請求發(fā)給你登陸的銀行網(wǎng)頁，請求的內(nèi)容就是給小姐姐轉(zhuǎn)賬，平時情況下，你沒登陸，轉(zhuǎn)賬不可能成功（后天驗證不通過），但是，你賬戶是你自己登陸的（有cookie了），鏈接是你自己點的，就這樣，你的錢就到小姐姐那里去了。

正經(jīng)一點的話就是：

別的某個惡意的網(wǎng)站上有一個指向你的網(wǎng)站的鏈接，如果某個用戶已經(jīng)登錄到你的網(wǎng)站上了，那么當(dāng)這個用戶點擊這個惡意網(wǎng)站上的那個鏈接時，就會向你的網(wǎng)站發(fā)來一個請求，你的網(wǎng)站會以為這個請求是用戶自己發(fā)來的，其實呢，這個請求是那個惡意網(wǎng)站偽造的。

要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：

　　1.登錄受信任網(wǎng)站A，并在本地生成Cookie。

　　2.在不登出A的情況下，訪問危險網(wǎng)站B。

Django 提供的 CSRF 防護機制

django 第一次響應(yīng)來自某個客戶端的請求時，會在服務(wù)器端隨機生成一個 token，把這個 token 放在 cookie 里。然后每次 POST 請求都會帶上這個 token，這樣就能避免被 CSRF 攻擊。

簡單的說就是在form表單里加個csrftoken 字段，因為攻擊者不能獲得第三方的Cookie(理論上)，也不知道服務(wù)器上生成的字段值，所以表單中的數(shù)據(jù)也就構(gòu)造失敗了

在返回的 HTTP 響應(yīng)的 cookie 里，django 會為你添加一個 csrftoken 字段，其值為一個自動生成的 token

在所有的 POST 表單時，必須包含一個 csrfmiddlewaretoken 字段 （只需要在模板里加一個 tag， django 就會自動幫你生成，見下面）

在處理 POST 請求之前，django 會驗證這個請求的 cookie 里的 csrftoken 字段的值和提交的表單里的 csrfmiddlewaretoken 字段的值是否一樣。如果一樣，則表明這是一個合法的請求，否則，這個請求可能是來自于別人的 csrf 攻擊，返回 403 Forbidden.

在所有 ajax POST 請求里，添加一個 X-CSRFTOKEN header，其值為 cookie 里的 csrftoken 的值

Django 里如何使用 CSRF 防護

• 首先，最基本的原則是：GET 請求不要用有副作用。也就是說任何處理 GET 請求的代碼對資源的訪問都一定要是“只讀“的。
• 要啟用 django.middleware.csrf.CsrfViewMiddleware 這個中間件
• 再次，在所有的 POST 表單元素時，需要加上一個 {% csrf_token %} tag
• 在渲染模塊時，使用 RequestContext。RequestContext 會處理 csrf_token 這個 tag, ?從而自動為表單添加一個名為 csrfmiddlewaretoken 的 input

轉(zhuǎn)載于:https://www.cnblogs.com/wlx97e6/p/9911127.html

超強干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的Django学习笔记10的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。