Middleware 中间件

在网上找了许多讲解的，总感觉不如文档中的讲解一目了然。
翻译，修改一下，写下这篇博文。

Middleware

Middleware 可以理解为是一个处理Django框架请求/响应处理的钩子。

且这是一个轻量，低级别的“插件”系统
用于全局范围内改变Django框架的输入或输出

每一个middleware 组成元件都是一些有特殊用途的函数

例如：

中间件：AuthenticationMiddleware
它能通过session 使 用户和请求（request）联系起来

下面这个文档解释了middleware 怎么工作，如何启用，如何实现一个自己的middleware

Django附带一些内置的中间件，你可以直接使用。
它们被记录在内置的中间件参考中。

Changed in Django 1.10:

引入了一种新的中间件，用于新的MIDDLEWARE设置。
如果您使用的是旧的 MIDDLEWARE_CLASSES设置，则需要在使用新设置之前调整旧的自定义中间件。

Writing a your own middleware

middleware factory 可以通过调用 get_response 并返回一个中间件

middleware可以接受一个request并返回一个response，像一个view（视图函数）一样。

A middleware can be written as a function that looks like this:

def simple_middleware(get_response):
    # One-time configuration and initialization(一次性设置和初始化).

    #内置函数
    def middleware(request):
        # Code to be executed for each request before
        # 代码要在每个request之前执行
        # the view (and later middleware) are called.
        # view（视图函数）和在在此之后使用的middleware可以被调用

        response = get_response(request)

        # Code to be executed for each request/response after
        # 每个request或者response之后执行
        # the view is called.
        # view可以被调用

        return response

    return middleware

或者可以写一个具有自我实例调用的类

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.

        response = self.get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response

get_response可以是一个view函数，也可以是 处理链 中另一个middleware
而 middleware 并不会确认它是什么，只会根据它指向下一步要到哪里执行

The above is a slight simplification – the get_response callable for the last middleware in the chain won’t be the actual view but rather a wrapper method from the handler which takes care of applying view middleware, calling the view with appropriate URL arguments, and applying template-response and exception middleware.

以上实例只是一个小小的简化 处理链中最后一个中间件的 get_response，
get_response这个middleware 将不再调用实际的view视图函数，而是用来处理 一些包装view 的方法
这些方法负责应用视图middleware，调用适当的URL参数 ， 调用视图， 模板响应和异常middleware。

Middleware无处不在

init(get_response)

Middleware factories 一定要有一个get_response参数

你也可以为Middleware的初始化设置一些全局属性

同时存在以下警告：

Django 只使用get_response来初始化你的middleware ,所以你不能给 __init__() 设置其他参数.
不同于 __call__() 函数每次request都要调用一次, __init__() 只在web服务启动时调用一次，之后不在调用

Changed in Django 1.10:

在这个版本中，__init__() 直到Web服务器响应其第一个请求才被调用。

在一些更老的版本中,__init__() 不能接受任何参数
为了让您的 middleware 在Django 1.9及更早版本中使用，请将get_response设置为可选参数（get_response = None）。

将中间件标记为未使用

有时在启动时不确定是否应该使用一个中间件。
在这些情况下，您的中间件的init （）方法可能会引发MiddlewareNotUsed。 然后，Django将从middleware进程中移除该middleware，并在DEBUG为True时将调试消息记录到django.request记录器。

激活 middleware

想要激活middleware组件, 需要添加MIDDLEWARE list到django 的 setting.py 配置文件中

在MIDDLEWARE list 中 每个组件都用一个字符串表示 :
到 middleware factory这个类完整的项目路径（字符串） 或者 middleware函数名.
例，这里有一个默认的 django-admin startproject:

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',
]

Django安装不需要任何middleware - 如果你喜欢 ,MIDDLEWARE可以是空的,— 但是 强烈建议使用CommonMiddleware.

MIDDLEWARE 很重要，对命令性 依赖性很强

例如 , AuthenticationMiddleware（认证middleware） 将认证的 用户 储存在session ; 因此, 他必须运行在 SessionMiddleware 后.