一.中间件概念
中间件顾名思义，是介于request与response处理之间的一道处理过程，相对比较轻量级，并且在全局上改变django的输入与输出。因为改变的是全局，所以需要谨慎实用，用不好会影响到性能。我们从浏览器发出一个请求 Request，得到一个响应后的内容 HttpResponse ，这个请求传递到 Django的过程如下：
也就是说，每一个请求都是先通过中间件中的 process_request 函数，这个函数返回 None 或者 HttpResponse 对象，如果返回前者，继续处理其它中间件，如果返回一个 HttpResponse，就处理中止，返回到网页上。中间件不用继承自任何类（可以继承 object ），下面一个中间件大概的样子：
class CommonMiddleware(object):
def process_request(self, request):
return None
def process_response(self, request, response):
return response
除了上面两个经常使用的函数外，还有 process_view, process_exception 和 process_template_response 函数。因此中间件中经常使用的函数就是如上的五种。而且中间件随着Django的版本不同也会不同，这点我们将在下面具体讨论。
二.实际应用需求：
比如我们要做一个 拦截器，发现有恶意访问网站的人，就拦截他！假如我们通过一种技术，比如统计一分钟访问页面的次数，太多就把他的 IP 加入到黑名单 BLOCKED_IPS（这部分没有提供代码，主要讲中间件部分）：
这里的代码的功能就是 获取当前访问者的 IP (request.META[‘REMOTE_ADDR‘])，如果这个 IP 在黑名单中就拦截，如果不在就返回 None (函数中没有返回值其实就是默认为 None)，把这个中间件的 Python 路径写到settings.py中即可生效，这里只是举一个简单的例子，后面会详细举例：
class BlockedIpMiddleware(object):
def process_request(self, request):
# 这里使用反射的方式拿到settings.py文件中的BLOCKED_IPS，其是一个列表，如果获取不到
# 那就返回一个空列表
"""
因此最终实现的效果就是：BLOCKED_IPS = [‘192.168.4.128‘, ‘192.168.4.129‘, ‘192.168.4.130‘]
if ‘192.168.4.129‘ in [‘192.168.4.128‘, ‘192.168.4.129‘, ‘192.168.4.130‘]:
return http.HttpResponseForbidden(‘<h1>Forbidden</h1>‘)
如果获取不到BLOCKED_IPS，那就返回一个空列表：
if ‘192.168.4.129‘ in []:
这就不满足条件，所以不执行
"""
if request.META[‘REMOTE_ADDR‘] in getattr(settings, "BLOCKED_IPS", []):
return http.HttpResponseForbidden(‘<h1>Forbidden</h1>‘)
1.1 Django 1.9 和以前的版本的中间件如下：
MIDDLEWARE_CLASSES = ( # 重点关注这里的名称
‘django.contrib.sessions.middleware.SessionMiddleware‘,
‘django.middleware.common.CommonMiddleware‘,
‘django.middleware.csrf.CsrfViewMiddleware‘,
‘django.contrib.auth.middleware.AuthenticationMiddleware‘,
‘django.contrib.auth.middleware.SessionAuthenticationMiddleware‘,
‘django.contrib.messages.middleware.MessageMiddleware‘,
‘django.middleware.clickjacking.XFrameOptionsMiddleware‘,
‘django.middleware.security.SecurityMiddleware‘,
‘MiddlewareProject.Middleware.my_middleware_dd.BlockedIpMiddleware‘ # 自定义的中间件
)
1.2 Django 1.10 版本 更名为 MIDDLEWARE（单复同形），写法也有变化，部署的时候要重新修改名字
如果用 Django 1.10版本开发，部署时用 Django 1.9版本或更低版本，要特别小心此处。
MIDDLEWARE = (
‘django.contrib.sessions.middleware.SessionMiddleware‘,
‘django.middleware.common.CommonMiddleware‘,
‘django.middleware.csrf.CsrfViewMiddleware‘,
‘django.contrib.auth.middleware.AuthenticationMiddleware‘,
‘django.contrib.auth.middleware.SessionAuthenticationMiddleware‘,
‘django.contrib.messages.middleware.MessageMiddleware‘,
‘django.middleware.clickjacking.XFrameOptionsMiddleware‘,
‘django.middleware.security.SecurityMiddleware‘,
‘MiddlewareProject.Middleware.my_middleware_dd.BlockedIpMiddleware‘
)
Django 会从 MIDDLEWARE_CLASSES 或 MIDDLEWARE 中按照从上到下的顺序一个个执行中间件中的 process_request 函数，而其中 process_response 函数则是最前面的最后执行，关于具体的执行顺序笔者将在后面做一个详细的总结。
二，再比如，我们在网站放到服务器上正式运行后，DEBUG改为了 False，这样更安全，但是有时候发生错误我们不能看到错误详情，调试不方便，有没有办法处理好这两个事情呢？普通访问者看到的是友好的报错信息；管理员看到的是错误详情，以便于修复 BUG；当然可以有，利用中间件就可以做到！代码如下：
import sys
from django.views.debug import technical_500_response
from django.conf import settings
class UserBasedExceptionMiddleware(object):
def process_exception(self, request, exception):
if request.user.is_superuser or request.META.get(‘REMOTE_ADDR‘) in settings.INTERNAL_IPS:
return technical_500_response(request, *sys.exc_info())
把这个中间件像上面一样，加到你的 settings.py 中的 MIDDLEWARE_CLASSES 中，可以放到最后，这样可以看到其它中间件的 process_request的错误。
当访问者为管理员时，就给出错误详情，比如访问本站的不存在的页面：http://www.ziqiangxuetang.com/admin/
作为一个普通的访问者，我们看到的是一个比较友好的普通的提示信息：
三.补充：Django 1.10 接口发生变化，变得更加简洁
class SimpleMiddleware(object):
def __init__(self, get_response):
self.get_response = get_response
# One-time configuration and initialization.
def __call__(self, request):
# Code to be executed for each request before
# the view (and later middleware) are called.
# 调用 view 之前的代码
response = self.get_response(request)
# Code to be executed for each request/response after
# the view is called.
# 调用 view 之后的代码
return response
Django 1.10.x 也可以用函数来实现中间件，详见官方文档：https://docs.djangoproject.com/en/1.10/topics/http/middleware/#writing-your-own-middleware
四.写出一个兼容Django各版本的中间件
try:
from django.utils.deprecation import MiddlewareMixin # Django 1.10.x
except ImportError:
MiddlewareMixin = object # Django 1.4.x - Django 1.9.x
class SimpleMiddleware(MiddlewareMixin):
def process_request(self, request):
pass
def process_response(request, response):
pass
新版本中 django.utils.deprecation.MiddlewareMixin 的 源代码 如下：
class MiddlewareMixin(object):
def __init__(self, get_response=None):
self.get_response = get_response
super(MiddlewareMixin, self).__init__()
def __call__(self, request):
response = None
if hasattr(self, ‘process_request‘):
response = self.process_request(request)
if not response:
response = self.get_response(request)
if hasattr(self, ‘process_response‘):
response = self.process_response(request, response)
return response
__call__ 方法会先调用 self.process_request(request)，接着执行 self.get_response(request) 然后调用 self.process_response(request, response).旧版本(Django 1.4.x-Django 1.9.x) 的话，和原来一样。
六.实例验证
在讲解中间件时，一个Django项目的起始执行如下：先走WSGI，然后再走中间件，注意一点，自带的中间件的顺序是不能倒置的，因为有可能下一个中间件要依赖于上一个中间件的数据，如果随意颠倒顺序，会报错，我们通常将自定义的中间件放到最下面，本次我们使用的是Django 1.8版本：
MIDDLEWARE_CLASSES = (
‘django.contrib.sessions.middleware.SessionMiddleware‘,
‘django.middleware.common.CommonMiddleware‘,
‘django.middleware.csrf.CsrfViewMiddleware‘,
‘django.contrib.auth.middleware.AuthenticationMiddleware‘,
‘django.contrib.auth.middleware.SessionAuthenticationMiddleware‘,
‘django.contrib.messages.middleware.MessageMiddleware‘,
‘django.middleware.clickjacking.XFrameOptionsMiddleware‘,
‘django.middleware.security.SecurityMiddleware‘, # 自定义中间件
‘MiddlewareDemo.Middleware.my_middleware_dd.MiddleWare1‘,
‘MiddlewareDemo.Middleware.my_middleware_dd.MiddleWare2‘
)
"""
注意在上面，如果自定义的中间件my_middleware.py放在项目根目录下，那么在settings中设置的路径直接就是my_middleware.MiddleWare1
Django能识别的只是根目录，我们通常会自定义一个目录，专门用来存放自定义的中间件
"""
接下来，我们一起看看中间件的执行流程，来看一张简单的图：
通过上图，我们可以总结出如下的流程：
request请求经过WSGI后，先进入中间件，依然开始先走process_request函数，然后走路由关系映射后，这里注意 并没有直接进入视图函数，而是从头开始执行process_view()函数；然后再去执行与urls.py匹配的视图函数； 如果视图函数没有报错，那就直接挨个反过来从最后一个中间件开始，依次将返回的实例对象(也就是我们在视图函数中 写的 return HttpResponse()等等)传递给每个中间件的process_response函数；最后再交给客户端浏览器； 如果执行视图函数出错，那就反过来从最后一个中间件开始，将错误信息传递给每个中间件的process_exception()函数，走完所有后，然后最终再走procss_response后，最终再交给客户端浏览器 注意：视图函数的错误是由process_exception()函数处理的，从最后一个中间件开始，依次逐级提交捕捉到的异常 然后最终交给procss_response()函数，将最终的错误信息交给客户端浏览器。
process_view的作用和特殊作用在哪？
走process_request的时候不知道走url中的哪个视图函数，当我们再回来走process_view的时候，由于此时已经走了 urls.py文件，所以它已经知道该执行哪个视图函数了我们发现process_view的源码中它的参数多了个callback这个参数的值就是具体的我们要执行视图函数；因此我们可以总结其实在process_view中可以执行下我们的视图函数。
def process_view(self, request, callback, callback_args, callback_kwargs):这里的callback就是视图函数的名称，因此如果有特殊需求，既不想进入views.py文件中执行视图函数，但是又想在中间件层面执行下视图函数，可以在process_view中，直接调用视图函数的名称即可执行：index()
我们首先来看下面的实际例子：
自定义的中间件如下：
# _*_ coding:utf-8 _*_
try:
from django.utils.deprecation import MiddlewareMixin # Django 1.10.x
except ImportError:
MiddlewareMixin = object
"""
process_request是不需要加return的，我们观察，如果假如return
会发生什么
"""
class MiddleWare1(object):
def process_request(self, request):
print("MQ1 request=======>")
def process_response(self, request, response):
print("MQ1 response=======>")
"""
这里一定要返回response，作为中间件的返回
如果不加浏览器会报错：
MiddleWare1.process_response didn‘t return an HttpResponse object.
It returned None instead.
也就是说process_response一定要返回一个response
这里的response其实质就是我们在视图函数中返回给浏览器的返回值：
return HttpResponse("OK")
也就是说，视图函数将HttpResponse("OK")作为一个参数传递给中间件的
process_response()函数，然后由中间件一层层地往上面传递给其他中间件
最终显示给客户端浏览器；所以是先打印view is running，然后再打印
MQ1 response
"""
return response
视图函数如下：
from django.shortcuts import render, HttpResponse
# Create your views here.
def index(request):
print("view index is running")
return HttpResponse("index..")
最终打印结果：
MQ1 request=======> view index is running MQ1 response=======>
终端的打印结果：
结果印证了我们上面的执行流程，先走process_request()函数，然后再走视图函数，最后再走process_response()函数
所以是先打印view is running，然后再打印MQ1 response。
接着wo‘men
原文地址：https://www.cnblogs.com/pyspark/p/8352756.html