本文講述的內(nèi)容基于 Django 1.11

摘要

Django 中的中間件（middleware），是一個(gè)鑲嵌到Django的request/response處理機(jī)制中的一個(gè)hooks框架，是一個(gè)修改django全局輸入輸出的一個(gè)底層插件系統(tǒng)。讓我們可以自定義想要的一些功能來(lái)處理用戶的請(qǐng)求。

在Django中，中間件其實(shí)就是一個(gè)類(lèi)，在類(lèi)中包含一組特定的功能，在請(qǐng)求到來(lái)或者結(jié)束時(shí)，Django會(huì)根據(jù)我們定義的中間件規(guī)則執(zhí)行中間件中對(duì)應(yīng)的方法，一個(gè) Django 項(xiàng)目默認(rèn)激活的中間件在我們項(xiàng)目中的配置中可以看到是這個(gè)樣子的：

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',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

MIDDLEWARE這里列表中的每一個(gè)元素，其實(shí)就是一個(gè)個(gè)單獨(dú)的中間件，舉例來(lái)說(shuō)：django.middleware.csrf.CsrfViewMiddleware這個(gè)中間件，作用就是在我們的 form 表單提交請(qǐng)求的時(shí)候，提交的時(shí)候必須要帶上csrf_token，否則就不會(huì)正確提交。

中間件使用也需要講究順序，下一層依賴上一層的封裝，例如，我們的AuthenticationMiddleware是一個(gè)認(rèn)證中間件，在session 中保存認(rèn)證用戶的信息，但是他必須依賴于SessionMiddleware才可以被正確使用，所以他也必須在SessionMiddleware之后。但是具體的順序問(wèn)題可以參考這里

中間件結(jié)構(gòu)

中間件類(lèi)中需要包含以下處理方法：

1. process_request(self, request)
2. process_view(self, request, callback, callback_args, callback_kwargs)
3. process_template_response(self, request, response)
4. process_exception(self, request, exception)
5. process_response(self, request, response)

執(zhí)行過(guò)程

以我們的項(xiàng)目中默認(rèn)中間件為例子，具體的流程如下所示：

中間件執(zhí)行前提

中間件要按照一定的順序一層一層的執(zhí)行下去，需要按照標(biāo)準(zhǔn)返回特定的內(nèi)容：

• 如果為 None，則按照順序繼續(xù)向下執(zhí)行
• 如果為 HttpResonse 對(duì)象，則直接將這個(gè)對(duì)象返回給用戶

此處有一個(gè)版本前后的區(qū)別，請(qǐng)大家注意區(qū)分：

在 Django1.10之后， 當(dāng)某個(gè)中間件，例如CsrfViewMiddleware請(qǐng)求process_request沒(méi)有返回 None 后，這個(gè)請(qǐng)求會(huì)交給CsrfViewMiddleware的process_response來(lái)返回，即返回給相同一層的中間件來(lái)返回:

在 Django1.10之前的版本，會(huì)返回到最底層的中間件來(lái)返回:

中間件方法：

1、process_request(self, request)

其中request參數(shù)就是我們的HttpRequest對(duì)象，process_request 會(huì)在每個(gè)request在被決定使用哪個(gè)view之前調(diào)用，它會(huì)返回None或HttpResponse對(duì)象

2、process_view(self, request, callback, callback_args, callback_kwargs)

其中request參數(shù)就是的HttpRequest對(duì)象，callback 就是請(qǐng)求被決定使用的 view 函數(shù)，書(shū)具體的函數(shù)名，不是字符串類(lèi)型。callback_args和callback_kwargs是 view 函數(shù)需要接受的參數(shù)，它會(huì)返回None或HttpResponse對(duì)象

3、process_template_response(self, request, response)

其中request 是 HttpRequest 對(duì)象， response 是一個(gè)由Django view或者中間件返回的TemplateResponse 對(duì)象,process_template_response()在 view 使用 render 渲染一個(gè)模版對(duì)象完成之后被調(diào)用，它必須返回一個(gè)render 方法執(zhí)行后的response對(duì)象。

4、process_exception(self, request, exception)

其中request參數(shù)就是的HttpRequest對(duì)象，exception是view函數(shù)中raise的Exception對(duì)象，當(dāng) view 函數(shù) raise 一個(gè) exception 的時(shí)候調(diào)用process_exception，它會(huì)返回None或HttpResponse對(duì)象

5、process_response(self, request, response)

其中request是 HttpRequest 對(duì)象，response 是一個(gè)django view或者中間件返回的 HttpResponse 或者StreamingHttpResponse對(duì)象，process_response會(huì)在所有響應(yīng)到達(dá)瀏覽器之前被調(diào)用

中間件的詳細(xì)執(zhí)行流程

由于process_template_response在特定的 rander 渲染中才會(huì)被調(diào)用，所以過(guò)程中不添加該方法

自建中間件與執(zhí)行過(guò)程測(cè)試

為了更加清晰的展示中間件的執(zhí)行過(guò)程與如何自定義一個(gè)中間件，我們模擬一個(gè)簡(jiǎn)單的用戶請(qǐng)求和中間件執(zhí)行過(guò)程：

自定義中間件

from django.utils.deprecation import MiddlewareMixin
class MyMiddleware_1(MiddlewareMixin):
 def process_request(self, request):
  print("自定義 process_request 1")
  return None

 def process_response(self, request, response):
  print("自定義 process_response 1")
  return response

 def process_view(self, request, callback, callback_args, callback_kwargs):
  print("自定義 process_view 1")
  return None

 def process_exception(self, request, exception):
  print("自定義 process_exception 1")


class MyMiddleware_2(MiddlewareMixin):

 def process_request(self, request):
  print("自定義 process_request 2")
  return None

 def process_response(self, request, response):
  print("自定義 process_response 2")
  return response

 def process_view(self, request, callback, callback_args, callback_kwargs):
  print("自定義 process_view 2")
  return None

 def process_exception(self, request, exception):
  print("自定義 process_exception 2")

引入

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.middle_by_me.MyMiddleware_1', # 第一個(gè)自定義 middleware
 'app01.middle_by_me.MyMiddleware_2' # 第二個(gè)自定義 middleware
]

輸出結(jié)果

自定義中間件應(yīng)用場(chǎng)景

應(yīng)用場(chǎng)景這個(gè)問(wèn)題其實(shí)不是很好去固定，因?yàn)榇蠹以趯?shí)際使用過(guò)程中的需求都不盡相同，所以我簡(jiǎn)單的舉個(gè)我可以想到的例子吧。

在不修改業(yè)務(wù)邏輯源代碼的情況下，我可以使用中間件來(lái)對(duì)用戶的訪問(wèn)進(jìn)行一定的篩選過(guò)濾，或者訪問(wèn)控制。還有能想到的更加牛逼的操作是當(dāng)源站的 CDN，請(qǐng)求穿透源站，middleware 判斷請(qǐng)求的內(nèi)容是否在緩存中，如果在緩存直接返回，而可以不經(jīng)過(guò)業(yè)務(wù)后端邏輯，是不是很騷~

是不是很像一個(gè)所有視圖函數(shù)的裝飾器~~

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論