Django 处理http请求之中间件

Win7

Django 1.11

自定义中间件

中间件“工厂”是一个携带一个可调用get_response参数并返回一个中间件的的可调用对象。中间件则是一个携带request参数并返回一个response的可调用对象，正如view视图函数。

中间件可以写成类似如下的函数(假设以下代码位于 my_middleware.py文件中,项目结构如下):

def simple_middleware(get_response):

print('进入中间件')

def middleware(request):

# 针对每个request，这里的代码，会在view、后续中间件被调用之前执行（Code to be executed for each request before the view (and later middleware) are called.）

response = get_response(request)

# 针对每个request，这里的代码，会在view、后续中间件被调用之后执行（Code to be executed for each request/response after the view is called）

return response

return middleware

或者如下，写成一个类，该类的实例为一个可调用对象

class SimpleMiddleware:

def __init__(self, get_response):

self.get_response = get_response

# 只配置并初始化一次（one-time configuration and initialization.）

def __call__(self, request):

# 针对每个request，这里的代码，会在view、后续中间件被调用之前执行（Code to be executed for each request before the view (and later middleware) are called.）

response = self.get_response(request)

# 针对每个request，这里的代码，会在view、后续中间件被调用之前执行（Code to be executed for each request before the view (and later middleware) are called.）

return response

django提供的get_response可能是实际view视图(如果当前中间是list中配置的最后一个中间件)、下一个中间件，当前中间件不需要知道它是啥。

中间件可以放在python path中的任何地方

__init__(get_response)

中间件工厂必须接受一个get_response参数，可以为中间件初始化一些全局状态，但是要注意:

• Django只允许用get_response初始化中间件，所以__init__()定义不能包含其它任何参数的。
• 和__call__()方法不一样，针对每个request，__call__()都会被调用一次，而__init__()仅在web 服务器启动时被调用一次（注意：实践表明 setting.py中 DEBUG = True时，启动服务时，__init__（）可能被调用两次）

标记不被使用的中间件

在对应中间件的 __init__() 方法中抛出 MiddlewareNotUsed，Django将会在处理中间件时移除对应的中间件，并在DEBUG设置为True的情况下，往django.request logger中写入一条调试消息。

激活中间件

添加目标中间件到settings.py中的MIDDLEWARE list中以激活中间件，注意新增中间件后需要重启服务器。

MIDDLEWARE中，每个中间件以一个字符串表示：指向中间件工厂类、函数的全python路径。如下：

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',
'website.middleware.my_middleware.simple_middleware',
'website.middleware.my_middleware.SimpleMiddleware',
]

MIDDLEWARE可以配置为空，但是强烈建议至少包含CommonMiddleware

中间件在MIDDLEWARE中的顺序很关键，因为一个中间件可能会依赖另一个中间件。例如 AuthenticationMiddleware在会话中存储已授权用户信息，所以，它必须在SessionMiddleware之后运行，所以，自定义中间件建议都放到最后面。See Middleware ordering for some common hints about ordering of Django middleware classes。

中间件顺序和分层

request阶段，view调用之前，Django会按顺序-中间件在MIDDLEWARE中的定义，从上往下(索引从小到大)，把中间件作用于request（During the request phase, before calling the view, Django applies middleware in the order it’s defined in MIDDLEWARE, top-down）

可以把它看成一个洋葱：每个中间件类都是一层包裹了view视图(洋葱的核心)的皮，如果请求通过了洋葱所有皮(每层都会调用get_response以便把request传递给下一层)，到达核心view，那么将按相反的顺序，把response一层一层的往外传。

如果其中一层短路了，没有调用get_response的情况下，返回了response，该层所包裹的所有层（包括view视图）将看不到当前request和response。response只会经过request已经通过的层。

其它中间件钩子

除了上述描述的基础的request/response中间件模式，还可以添加以下三种特定的方法给基于类的中间件：

process_view()

process_view(request, view_func, view_args, view_kwargs)

request 为一个 HttpRequest 对象。

view_func为Django即将调用的python函数 (实际函数对象，而非表示函数名称的字符串)

view_args 传递给view函数的位置参数list列表

view_kwargs 传递给view函数的字典参数，不管是view_args 还是 view_kwargs都不包含第一个参数（request).

process_view() 在Django调用view之前，__call__（）被调用之后被调用，如下：

__call__() ->process_view() -> view function -> __call__()

函数应该返回None或者一个HttpResponse对象。如果返回None，Django将继续处理request，执行其它中间件的process_view()，最后执行对应的view。如果返回一个HttpResponse对象，Django将不会调用对应的view及后续的process_exception(), process_template_response()等，直接调用对应的response中间件作用于该response对象并返回结果.

注意：

应该避免在view视图运行之前，在中间件内部访问 request.POST，因为这将阻止该中间件之后的任何视图 modify the upload handlers for the request（Accessing request.POST inside middleware before the view runs or in process_view() will prevent any view running after the middleware from being able to modify the upload handlers for the request, and should normally be avoided）

CsrfViewMiddleware类可以被看做一个异常，因为它提供csrf_exempt() 和csrf_protect() 装饰器，可以显示控制在哪里进行CSRF校验。 (The CsrfViewMiddleware class can be considered an exception, as it provides the csrf_exempt() andcsrf_protect() decorators which allow views to explicitly control at what point the CSRF validation should occu

process_exception()

process_exception(request, exception)

request 为一个 HttpRequest 对象。

exception 为view视图函数的一个 Exception 对象。

当view抛出一个异常时，Django才会调用process_exception()。函数应该返回None或者一个HttpResponse对象。如果返回一个HttpResponse对象，将应用template response和response中间件并返回上述描述的HttpResponse对象，结果给浏览器，否则走默认的异常处理（default exception handling ）

相反的，response阶段(包括process_exception)，按逆序运行中间件。如果异常中间件返回了一个response，位于该中间件前面的中间件（MIDDLEWARElist 中对应索引比当前中间件的索引小的中间件）的process_exception都不会被调用。

process_template_response()

process_template_response(request, response)

request 为一个 HttpRequest 对象。

response 为Django view、中间件返回的一个TemplateResponse对象

process_template_response() 在view视图执行完成后才被调用。如果response实例有render（）方法，它将被视为TemplateResponse 。形如：

from django.template.response import TemplateResponse

def test_page(request):

return TemplateResponse(request, 'website/pages/mytest.html',{})

它必须返回实现了render方法的response对象。可以通过改变response.template_name和response.context_data更改给定response，或者返回一个全新的TemplateResponse

无需显示的渲染response--response将在所有template response中间件调用完成后自动被渲染。

response阶段(包括process_template_response())，按逆序运行中间件。

Dealing with streaming responses

不同于HttpResponse，StreamingHttpResponse沒有content属性，因此中间件不能认为所有的响应都有content 属性，如果想要访问content，需要测试流式响应：

if response.streaming:

response.streaming_content = wrap_streaming_content(response.streaming_content)

else:

response.content = alter_content(response.content)

注意：streaming_content被假定为太大而不能存放在内存中，响应中间件可以将它包裹在一个生成器中，但是不能消费它，通常如下所示：

Def wrap_streaming_content(content):

for chunk in content:

yield alter_content(chunk)

Exception handling

略

例子1

# -*- coding: utf-8 -*-
 
__author__ = 'shouke'
 
# from django.http import HttpResponse
 
class SimpleMiddleware1:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.
        print('call __init__ in SimpleMiddleware1')
 
    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.
        print('call __call_ in SimpleMiddleware1 before the view is called')
 
        response = self.get_response(request)
 
       # Code to be executed for each request/response after
        # the view is called.
        print('call __call_ in SimpleMiddleware1 after the view is called')
        return response
 
 
    def process_view(self, request, view_func, view_args, view_kwargs):
        print('call process_view in SimpleMiddleware1')
        # return HttpResponse('shouke')
 
 
    def process_template_response(self, request, response):
        print('call process_template_response in SimpleMiddleware1')
        return response
 
 
    def process_exception(self, request, exception):
        print('call process_exception in SimpleMiddleware1')
 
 
class SimpleMiddleware2:
    def __init__(self, get_response):
       self.get_response = get_response
       # One-time configuration and initialization.
       print('call __init__ in SimpleMiddleware2')
 
    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.
        print('call __call_ in SimpleMiddleware2 before the view is called')
 
        response = self.get_response(request)
 
        # Code to be executed for each request/response after
        # the view is called.
        print('call __call_ in SimpleMiddleware2 after the view is called')
        return response
 
 
    def process_view(self, request, view_func, view_args, view_kwargs):
        print('call process_view in SimpleMiddleware2')
 
 
    def process_template_response(self, request, response):
        print('call process_template_response in SimpleMiddleware2')
        return response
 
 
    def process_exception(self, request, exception):
        print('call process_exception in SimpleMiddleware2')
        # return HttpResponse('shouke')

View函数

def test_page(request):
    print('call view function test_page')
    # 1/0
    return TemplateResponse(request, 'website/pages/mytest.html',{})

中间件配置

MIDDLEWARE = [

……

'website.middleware.my_middleware.SimpleMiddleware1',

'website.middleware.my_middleware.SimpleMiddleware2',]

运行结果

Upgrading pre-Django 1.10-style middleware

From django.utils.deprecation import 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

Django提供了django.utils.deprecation.MiddlewareMixin来简化中间件类的创建，MiddlewareMixin兼容 MIDDLEWARE 和老版本的 MIDDLEWARE_CLASSES。Django包含的所有中间件类都是兼容彼此的配置的。

如果使用 MIDDLEWARE_CLASSES, 将不会调用__call__；直接调用 process_request() 和process_response()

大多数情况下，直接从MiddlewareMixin继承创建中间件就够了。

使用 MIDDLEWARE 和MIDDLEWARE_CLASSES的区别？

略

例子2

# -*- coding: utf-8 -*-
 
__author__ = 'shouke'
 
from django.utils.deprecation import MiddlewareMixin
# from django.http import HttpResponse
 
class SimpleMiddleware1(MiddlewareMixin):
    def process_request(self, request):
        print('call process_request in SimpleMiddleware1')
 
 
    def process_response(self, request, response):
        print('call process_response in SimpleMiddleware1')
        return response
 
 
 
class SimpleMiddleware2(MiddlewareMixin):
    def process_request(self, request):
        print('call process_request in SimpleMiddleware2')
 
    def process_response(self, request, response):
        print('call process_response in SimpleMiddleware2')
        return response

说明：

process_request在调用view函数视图之前执行；

Process_response在调用view函数视图之后执行；

参考链接

https://docs.djangoproject.com/en/2.1/topics/http/middleware/

https://docs.djangoproject.com/en/2.1/_modules/django/middleware/common/#CommonMiddleware