Django中间件有很多，入session、csrf、contexttype等，能力强的朋友还可以自己写中间件。

在使用python中的框架，基本上都会遇到中间件，同学们应该都没有听说或者使用过中间件吧，其实中间件呢，就是我们在我们执行到结果的一系列过程，通常我们使用中间件，用处不少，有事对于登录上或者是后台流量统计上，还有就是爬虫上进行保护，好啦，大致方面已经给大家讲述了，那就来看下具体实现的吧~

中间件中一共有四个方法：

• process_request

• process_view

• process_exception

• process_response

中间键流程：

中间件的创建：

以SQL为例BDE（Borland Databas Engine）， 是中最古老的技术，从 2.0加入BDE 技术以后，一直是处理数据库的事实上的标准。BDE 是一个基于驱动程序的体系结构，每一种数据格式或数据源都有一种驱动程序来驱动相近的数据源。

Django的中间件可以分为请求和响应。

请求是在请求之前而处理。那处理都是做些什么事情呢？

举个例子： 我们要求所有的访问都必须是登录用户，如果我们一个一个请求都加上登录判断显然是不合理的。所以这个时候我们就可以把中间件派上用场了。在一个中间件上统一的处理，只要没有登录（我们可以在登录之后返回一个token给前面，以后每次请求都带着这个正确的token，我们基于这个token验证用户是否登录），那我们就直接返回403，这里是一个很典型的应用，当然也会有一些其他的应用，这里就不做一一列举了。

响应是在返回时处理。处理其实和请求时是类似的。只不过请求是在请求前，响应是在响应之后，比如我们有个需求是在每个请求之后返回系统的当前时间。那就可以在这个中间件中增加一个统一处理。

基本上是这个样子吧，如果想继续深入了解，可以去阅读源码。

在使用python中的框架，基本上都会遇到中间件，同学们应该都没有听说或者使用过中间件吧，其实中间件呢，就是我们在我们执行到结果的一系列过程，通常我们使用中间件，用处不少，有事对于登录上或者是后台流量统计上，还有就是爬虫上进行保护，好啦，大致方面已经给大家讲述了，那就来看下具体实现的吧~

中间件中一共有四个方法：

• process_request

• process_view

• process_exception

• process_response

中间件是Django请求/响应处理的钩子框架。这是一个轻量级的低级“插件”系统，用于在全球范围内改变Django的输入或输出。

每个中间件组件都负责完成一些特定的功能。例如，Django包含一个中间件组件 AuthenticationMiddleware，它使用会话将用户与请求相关联。

本文档介绍了中间件如何工作，如何激活中间件以及如何编写自己的中间件。Django附带一些内置的中间件，您可以立即使用它们。它们被记录在内置的中间件参考中。

激活中间件¶

要激活中间件组件，请将其添加到MIDDLEWARE_CLASSESDjango设置中的 列表中。

在中MIDDLEWARE_CLASSES，每个中间件组件都由一个字符串表示：中间件类名的完整Python路径。例如，以下是由以下项创建的默认值：django-admin startproject

MIDDLEWARE_CLASSES  =  [ 
    'django.middleware.security.SecurityMiddleware' ，
    '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_CLASSES如果您愿意，可以是空的 - 但强烈建议您至少使用 CommonMiddleware。

MIDDLEWARE_CLASSES由于中间件可以依赖于其他中间件，因此这个顺序很重要。例如， AuthenticationMiddleware将认证用户存储在会话中; 因此，它必须在之后运行 SessionMiddleware。有关Django中间件类的排序的一些常见提示，请参阅 中间件排序。

挂钩和应用程序¶

在请求阶段，在调用视图之前，Django按照自定义的顺序MIDDLEWARE_CLASSES自上而下地应用中间件。两个钩子可用：

• process_request()

• process_view()

在响应阶段，在调用视图之后，中间件从下往上以相反的顺序应用。三个挂钩可供选择：

• process_exception() （只有当视图引发异常时）

• process_template_response() （仅适用于模板响应）

• process_response()

中间件顾名思义，是介于request与response处理之间的一道处理过程，相对比较轻量级，并且在全局上改变django的输入与输出。因为改变的是全局，所以需要谨慎实用，用不好会影响到性能

认证支持中间件

中间件类: django.contrib.auth.middleware.AuthenticationMiddleware . django.contrib.auth.middleware.AuthenticationMiddleware .

这个中间件激活认证支持功能. 它在每个传入的 HttpRequest 对象中添加代表当前登录用户的 request.user 属性。 It adds the request.user attribute, representing the currently logged-in user, to every incoming HttpRequest object.

通用中间件

Middleware class: django.middleware.common.CommonMiddleware .

这个中间件为完美主义者提供了一些便利:

    禁止 ``DISALLOWED_USER_AGENTS`` 列表中所设置的user agent访问 ：一旦提供，这一列表应当由已编译的正则表达式对象组成，这些对象用于匹配传入的request请求头中的user-agent域。 下面这个例子来自某个配置文件片段：

•     请注意 import re ,因为 DISALLOWED_USER_AGENTS 要求其值为已编译的正则表达式(也就是 re.compile() 的返回值)。

•     依据 ``APPEND_SLASH`` 和 ``PREPEND_WWW`` 的设置执行URL重写 ：如果 APPEND_SLASH 为 True , 那些尾部没有斜杠的URL将被重定向到添加了斜杠的相应URL，除非path的最末组成部分包含点号。 因此， foo.com/bar 会被重定向到 foo.com/bar/ , 但是 foo.com/bar/file.txt 将以不变形式通过。

•     如果 PREPEND_WWW 为 True , 那些缺少先导www.的URLs将会被重定向到含有先导www.的相应URL上。 will be redirected to the same URL with a leading www..

•     这两个选项都是为了规范化URL。 其后的哲学是每个URL都应且只应当存在于一处。 技术上来说，URL example.com/bar 与 example.com/bar/ 及 www.example.com/bar/ 都互不相同。

•     依据 ``USE_ETAGS`` 的设置处理Etag : ETags 是HTTP级别上按条件缓存页面的优化机制。 如果 USE_ETAGS 为 True ，Django针对每个请求以MD5算法处理页面内容，从而得到Etag, 在此基础上，Django将在适当情形下处理并返回 Not Modified 回应(译注：

•     请注意，还有一个条件化的 GET 中间件, 处理Etags并干得更多，下面马上就会提及。

压缩中间件

中间件类 django.middleware.gzip.GZipMiddleware .

这个中间件自动为能处理gzip压缩(包括所有的现代浏览器)的浏览器自动压缩返回]内容。 这将极大地减少Web服务器所耗用的带宽。 代价是压缩页面需要一些额外的处理时间。

相对于带宽，人们一般更青睐于速度，但是如果你的情形正好相反，尽可启用这个中间件。
条件化的GET中间件

Middleware class: django.middleware.http.ConditionalGetMiddleware .

这个中间件对条件化 GET 操作提供支持。 如果response头中包括 Last-Modified 或 ETag 域，并且request头中包含 If-None-Match 或 If-Modified-Since 域，且两者一致，则该response将被response 304(Not modified)取代。 对 ETag 的支持依赖于 USE_ETAGS 配置及事先在response头中设置 ETag 域。稍前所讨论的通用中间件可用于设置response中的 ETag 域。 As discussed above, the ETag header is set by the Common middleware.

此外，它也将删除处理 HEAD request时所生成的response中的任何内容，并在所有request的response头中设置 Date 和 Content-Length 域。
反向代理支持 (X-Forwarded-For中间件)

Middleware class: django.middleware.http.SetRemoteAddrFromForwardedFor .

这是我们在 什么是中间件 这一节中所举的例子。 在 request.META['HTTP_X_FORWARDED_FOR'] 存在的前提下，它根据其值来设置 request.META['REMOTE_ADDR'] 。在站点位于某个反向代理之后的、每个request的 REMOTE_ADDR 都被指向 127.0.0.1 的情形下，这一功能将非常有用。 It sets request.META['REMOTE_ADDR'] based on request.META['HTTP_X_FORWARDED_FOR'] , if the latter is set. This is useful if you're sitting behind a reverse proxy that causes each request's REMOTE_ADDR to be set to 127.0.0.1 .

红色警告！

这个middleware并 不 验证 HTTP_X_FORWARDED_FOR 的合法性。

如果站点并不位于自动设置 HTTP_X_FORWARDED_FOR 的反向代理之后，请不要使用这个中间件。 否则，因为任何人都能够伪造 HTTP_X_FORWARDED_FOR 值，而 REMOTE_ADDR 又是依据 HTTP_X_FORWARDED_FOR 来设置，这就意味着任何人都能够伪造IP地址。

只有当能够绝对信任 HTTP_X_FORWARDED_FOR 值得时候才能够使用这个中间件。
会话支持中间件

Middleware class: django.contrib.sessions.middleware.SessionMiddleware .

这个中间件激活会话支持功能.

Middleware classes: django.middleware.cache.UpdateCacheMiddleware and django.middleware.cache.FetchFromCacheMiddleware .

这些中间件互相配合以缓存每个基于Django的页面。
事务处理中间件

Middleware class: django.middleware.transaction.TransactionMiddleware .

这个中间件将数据库的 COMMIT 或 ROLLBACK 绑定到request/response处理阶段。 如果view函数成功执行，则发出 COMMIT 指令。 如果view函数抛出异常，则发出 ROLLBACK 指令。

这个中间件在栈中的顺序非常重要。 其外层的中间件模块运行在Django缺省的 保存-提交 行为模式下。 而其内层中间件(在栈中的其后位置出现)将置于与view函数一致的事务机制的控制下。

很多啊，比如session、csrf、contexttype，你还可以自己写中间件。