Django视图层——内建的中间件类

Posted 2020-12-25 aric-zhu

参考文献：

https://docs.djangoproject.com/zh-hans/2.0/ref/middleware/

 

 

可用的中间件

缓存类中间件（cache middleware）

class UpdateCacheMiddleware

class FetchFromCacheMiddleware

启用站点范围的缓存。 如果启用了这些，只要CACHE_MIDDLEWARE_SECONDS设置定义，每个Django支持的页面都将被缓存。 请参阅缓存文档

 

通用类中间件（common middleware）

class CommonMiddleware

添加了一些方便的操作：

• 禁止在DISALLOWED_USER_AGENTS设置中访问用户代理，该设置应该是已编译的正则表达式对象的列表。
• 根据APPEND_SLASH和PREPEND_WWW设置执行URL重写。

　　　　如果APPEND_SLASH为True并且初始URL未以斜杠结尾，并且在URLconf中找不到，则通过在末尾附加斜杠来形成新URL。 如果在URLconf中找到此新URL，则Django会将请求重定向到此新URL。 否则，照常处理初始URL

　　　　例如，如果您没有foo.com/bar的有效URL模式但foo.com/bar/的格式有效，则foo.com/bar将被重定向到foo.com/bar/。

 

　　　　如果PREPEND_WWW为True，则缺少前导“www”的网址。 将被重定向到具有前导“www”的相同URL。

　　　　这两个选项都用于规范化URL。 理念是每个URL应该只存在于一个地方。 从技术上讲，URL foo.com/bar与foo.com/bar/不同 - 搜索引擎索引器会将它们视为单独的URL - 因此最佳做法是规范化URL。

• 根据USE_ETAGS设置处理ETag。 如果USE_ETAGS设置为True，Django将通过对页面内容进行MD5散列计算每个请求的ETag，并且如果合适，它将负责发送Not Modified响应。
• 为非流式响应设置Content-Length标头。

 

 

GZip中间件

class GZipMiddleware

警告：

安全研究人员最近透露，当在网站上使用压缩技术（包括GZipMiddleware）时，该网站可能会受到一些可能的攻击。在您的网站上使用GZipMiddleware之前，您应该非常仔细地考虑您是否受到这些攻击。

如果您对是否受到影响有任何疑问，则应避免使用GZipMiddleware。

 

应将此中间件放在需要读取或写入响应主体的任何其他中间件之前，以便之后进行压缩。

以下条件如果为真，那么它将不会执行压缩：

• 内容主体长度小于200个字节。
• 响应已设置Content-Encoding标头。
• 请求（浏览器）尚未发送包含gzip的Accept-Encoding标头。

如果响应具有ETag标头，则ETag变弱以符合RFC 7232＃section-2.1。

您可以使用gzip_page（）装饰器将GZip压缩应用于各个视图。

 

Conditional GET中间件

class ConditionalGetMiddleware

处理条件GET操作。 如果响应没有ETag标头，则中间件会在需要时添加一个。 如果响应具有ETag或Last-Modified标头，并且请求具有If-None-Match或If-Modified-Since，则响应将被HttpResponseNotModified替换。

 

Locale中间件

class LocaleMiddleware

根据请求中的数据启用语言选择。 它为每个用户定制内容。

LocaleMiddleware.response_redirect_class

默认会到HttpResponseRedirect。子类LocaleMiddleware并覆盖该属性以自定义中间件发出的重定向

 

Message中间件

class MessageMiddleware

允许基于cookie和session的消息的支持。

 

Security中间件

class SecurityMiddleware

注意：如果您的部署情况允许，通常最好让您的前端Web服务器执行SecurityMiddleware提供的功能。 这样，如果存在Django不提供的请求（例如静态媒体或用户上传的文件），它们将具有与对Django应用程序的请求相同的保护。

这个django.middleware.security.SecurityMiddleware中间件对request/response提供了一些安全增强措施。每一个都可以单独打开或关闭，通过下面的设置。

SECURE_BROWSER_XSS_FILTER
SECURE_CONTENT_TYPE_NOSNIFF
SECURE_HSTS_INCLUDE_SUBDOMAINS
SECURE_HSTS_PRELOAD
SECURE_HSTS_SECONDS
SECURE_REDIRECT_EXEMPT
SECURE_SSL_HOST
SECURE_SSL_REDIRECT

HTTP Strict Transport Security

对于只应通过HTTPS访问的站点，您可以通过设置“Strict-Transport-Security”标头，指示现代浏览器拒绝通过不安全的连接（在给定的时间段内）连接到您的域名。 这可以减少您在某些SSL剥离中间人（MITM）攻击中的风险。

X-Content-Type-Options: nosniff

X-XSS-Pro tection: 1: mode=block

 

SSL Redirect

如果您的站点同时提供HTTP和HTTPS连接，则大多数用户默认情况下最终会使用不安全的连接。 为了获得最佳安全性，您应该将所有HTTP连接重定向到HTTPS。

如果将SECURE_SSL_REDIRECT设置为True，SecurityMiddleware将永久（HTTP 301）将所有HTTP连接重定向到HTTPS。

 

 

Session中间件

class SessionMiddleware

打开session支持。

 

Site中间件

class CurrentSiteMiddleware

将表示当前站点的站点属性添加到每个传入的HttpRequest对象

 

Authentication中间件

class AuthenticationMiddleware

对每一个HttpRequest请求对象添加user属性，代表了当前的登录用户。

class RemoteUserMiddleware

使用Web服务器提供的验证的中间件。

class PersistentRemoteUserMiddleware

仅在登录页面使用Web服务器提供的验证的中间件。

 

CSRF protection中间件

class CsrfViewMiddleware

通过向POST表单添加隐藏的表单字段并检查正确值的请求，添加对跨站点请求伪造的保护

 

X-Frame-Options中间件

class XFrameOptionsMiddleware

通过X-Frame-Options标头进行简单的点击劫持保护。

 

 

中间件的顺序

下面是一些关于应用这些中间件的顺序的建议：

1. SecurityMiddleware

   It should go near the top of the list if you‘re going to turn on the SSL redirect as that avoids running through a bunch of other unnecessary middleware.

2. UpdateCacheMiddleware

   Before those that modify the Vary header (SessionMiddleware, GZipMiddleware, LocaleMiddleware).

3. GZipMiddleware

   Before any middleware that may change or use the response body.

   After UpdateCacheMiddleware: Modifies Vary header.

4. ConditionalGetMiddleware

   Before CommonMiddleware: uses its ETag header when USE_ETAGS = True.

5. SessionMiddleware

   After UpdateCacheMiddleware: Modifies Vary header.

6. LocaleMiddleware

   One of the topmost, after SessionMiddleware (uses session data) and UpdateCacheMiddleware (modifies Vary header).

7. CommonMiddleware

   Before any middleware that may change the response (it sets the ETag and Content-Length headers). A middleware that appears before CommonMiddleware and changes the response must reset the headers.

   After GZipMiddleware so it won‘t calculate an ETag header on gzipped contents.

   Close to the top: it redirects when APPEND_SLASH or PREPEND_WWW are set to True.

8. CsrfViewMiddleware

   Before any view middleware that assumes that CSRF attacks have been dealt with.

   It must come after SessionMiddleware if you‘re using CSRF_USE_SESSIONS.

9. AuthenticationMiddleware

   After SessionMiddleware: uses session storage.

10. MessageMiddleware

    After SessionMiddleware: can use session-based storage.

11. FetchFromCacheMiddleware

    After any middleware that modifies the Vary header: that header is used to pick a value for the cache hash-key.

12. FlatpageFallbackMiddleware

    Should be near the bottom as it‘s a last-resort type of middleware.

13. RedirectFallbackMiddleware

    Should be near the bottom as it‘s a last-resort type of middleware.