Django 文件協作翻譯小組人手緊缺，有興趣的朋友可以加入我們，完全公益性質。

交流群：467338606

網站：http://python.usyiyi.cn/django/index.html

中介軟體

這篇文件介紹了Django自帶的所有中介軟體元件。 要檢視關於如何使用它們以及如何編寫自己的中介軟體，請見中介軟體使用指導。

可用的中介軟體

快取中介軟體

class UpdateCacheMiddleware[source]

class FetchFromCacheMiddleware[source]

開啟全站範圍的快取。 如果開啟了這些快取，任何一個由Django提供的頁面將會被快取，快取時長是由你在CACHE_MIDDLEWARE_SECONDS配置中定義的。詳見快取文件。

“常用”的中介軟體

class CommonMiddleware[source]

給完美主義者增加一些便利條件：

• 禁止訪問DISALLOWED_USER_AGENTS中設定的使用者代理，這項配置應該是一個已編譯的正規表示式物件的列表。
• 基於APPEND_SLASH和PREPEND_WWW的設定來重寫URL。

如果APPEND_SLASH設為True並且一開始的的URL沒有以斜線結尾，並且在URLconf中也沒找到對應定義，這時形成一個一個斜線結尾新的URL。如果這個新的URL存在於URLconf，這時Django會重定向請求到這個新URL上，否則，一開始的URL按正常情況處理。

比如，foo.com/bar將會被重定向到foo.com/bar/，如果你沒有為foo.com/bar定義有效的正則，但是為foo.com/bar/定義了有效的正則。

如果PREPEND_WWW設為True，前面缺少 “www.”的url將會被重定向到相同但是以一個”www.”開頭的url。

兩種選項都是為了規範化url。其中的哲學就是，任何一個url應該在一個地方僅存在一個。技術上來講，url foo.com/bar 區別於foo.com/bar/ – 搜尋引擎索引會把這裡分開處理 – 因此，最佳實踐就是規範化url。

• 基於 USE_ETAGS 設定來處理ETag。如果設定USE_ETAGS為True，Django會通過MD5-hashing處理頁面的內容來為每一個頁面請求計算Etag，並且如果合適的話，它將會傳送攜帶Not Modified的響應。

CommonMiddleware.response_redirect_class

Django 1.8中新增

預設為HttpResponsePermanentRedirect。它繼承了CommonMiddleware，並覆寫了屬性來自定義中介軟體發出的重定向。

class BrokenLinkEmailsMiddleware[source]

• 向MANAGERS傳送死鏈提醒郵件（詳見錯誤報告）。

GZip中介軟體

class GZipMiddleware[source]

警告

安全研究員最近發現，當壓縮技術（包括GZipMiddleware）用於一個網站的時候，網站會受到一些可能的攻擊。此外，這些方法可以用於破壞Django的CSRF保護。在你的站點使用GZipMiddleware之前，你應該先仔細考慮一下你的站點是否容易受到這些攻擊。 如果你不確定是否會受到這些影響，應該避免使用 GZipMiddleware。詳見the BREACH paper (PDF)和breachattack.com。

為支援GZip壓縮的瀏覽器（一些現代的瀏覽器）壓縮內容。

建議把這個中介軟體放到中介軟體配置列表的第一個，這樣壓縮響應內容的處理會到最後才 發生。

如果滿足下面條件的話，內容不會被壓縮：

• 訊息體的長度小於200個位元組。
• 響應已經設定了Content-Encoding協議頭。
• 請求（瀏覽器）沒有傳送包含gzip的Accept-Encoding協議頭。

你可以通過這個gzip_page()裝飾器使用獨立的GZip壓縮。

帶條件判斷的GET中介軟體

class ConditionalGetMiddleware[source]

處理帶有條件判斷狀態GET操作。 如果一個請求包含 ETag 或者Last-Modified協議頭，並且請求包含If-None-Match或If-Modified-Since，這時響應會被 替換為HttpResponseNotModified。

另外，它會設定Date和Content-Length響應頭。

本地中介軟體

class LocaleMiddleware[source]

基於請求中的資料開啟語言選擇。 它可以為每個使用者進行定製。 詳見國際化文件。

LocaleMiddleware.response_redirect_class

預設為HttpResponseRedirect。繼承自LocaleMiddleware並覆寫了屬性來自定義中介軟體發出的重定向。

訊息中介軟體

class MessageMiddleware[source]

開啟基於cookie或會話的訊息支援。詳見訊息文件。

安全中介軟體

警告

如果你的部署環境允許的話，讓你的前端web伺服器展示SecurityMiddleware提供的功能是個好主意。這樣一來，如果有任何請求沒有被Django處理（比如靜態媒體或使用者上傳的檔案），他們會擁有和向Django應用的請求相同的保護。

class SecurityMiddleware[source]

Django 1.8中新增

django.middleware.security.SecurityMiddleware為請求/響應迴圈提供了幾種安全改進。每一種可以通過一個選項獨立開啟或關閉。

• SECURE_BROWSER_XSS_FILTER
• SECURE_CONTENT_TYPE_NOSNIFF
• SECURE_HSTS_INCLUDE_SUBDOMAINS
• SECURE_HSTS_SECONDS
• SECURE_REDIRECT_EXEMPT
• SECURE_SSL_HOST
• SECURE_SSL_REDIRECT

HTTP Strict Transport Security (HSTS)

對於那些應該只能通過HTTPS訪問的站點，你可以通過設定HSTS協議頭，通知現代的瀏覽器，拒絕用不安全的連線來連線你的域名。這會降低你受到SSL-stripping的中間人（MITM）攻擊的風險。

如果你將SECURE_HSTS_SECONDS設定為一個非零值，SecurityMiddleware會在所有的HTTPS響應中設定這個協議頭。

開啟HSTS的時候，首先使用一個小的值來測試它是個好主意，例如，讓SECURE_HSTS_SECONDS = 3600為一個小時。每當瀏覽器在你的站點看到HSTS協議頭，都會在提供的時間段內絕對使用不安全（HTTP）的方式連線到你的域名。一旦你確認你站點上的所有東西都以安全的方式提供（例如，HSTS並不會干擾任何事情），建議你增加這個值，這樣不常訪問你站點的遊客也會被保護（比如，一般設定為31536000秒，一年）。

另外，如果你將 SECURE_HSTS_INCLUDE_SUBDOMAINS設定為True,，SecurityMiddleware會將includeSubDomains標籤新增到Strict-Transport-Security協議頭中。強烈推薦這樣做（假設所有子域完全使用HTTPS），否則你的站點仍舊有可能由於子域的不安全連線而受到攻擊。

警告

HSTS策略在你的整個域中都被應用，不僅僅是你所設定協議頭的響應中的url。所以，如果你的整個域都設定為HTTPS only，你應該只使用HSTS策略。

適當遵循HSTS協議頭的瀏覽器，會通過顯示警告的方式，拒絕讓使用者連線到證照過期的、自行簽署的、或者其他SSL證照無效的站點。如果你使用了HSTS，確保你的證照處於一直有效的狀態！

注意

如果你的站點部署在負載均衡器或者反向代理之後，並且Strict-Transport-Security協議頭沒有新增到你的響應中，原因是Django有可能意識不到這是一個安全連線。你可能需要設定SECURE_PROXY_SSL_HEADER。

X-Content-Type-Options: nosniff

一些瀏覽器會嘗試猜測他們所得內容的型別，而不是讀取Content-Type協議頭。雖然這樣有助於配置不當的伺服器正常顯示內容，但也會導致安全問題。

如果你的站點允許使用者上傳檔案，一些惡意的使用者可能會上傳一個精心構造的檔案，當你覺得它無害的時候，檔案會被瀏覽器解釋成HTML或者Javascript。

欲知更多有關這個協議頭和瀏覽器如何處理它的內容，你可以在IE安全部落格中讀到它。

要防止瀏覽器猜測內容型別，並且強制它一直使用 Content-Type協議頭中提供的型別，你可以傳遞X-Content-Type-Options: nosniff協議頭。SecurityMiddleware將會對所有響應這樣做，如果SECURE_CONTENT_TYPE_NOSNIFF 設定為True。

注意在大多數Django不涉及處理上傳檔案的部署環境中，這個設定不會有任何幫助。例如，如果你的MEDIA_URL被前端web伺服器直接處理（例如nginx和Apache），你可能想要在那裡設定這個協議頭。而在另一方面，如果你使用Django執行為了下載檔案而請求授權之類的事情，並且你不能使用你的web伺服器設定協議頭，這個設定會很有用。

X-XSS-Protection: 1; mode=block

一些瀏覽器能夠遮蔽掉出現XSS攻擊的內容。通過尋找頁面中GET或者POST引數中的JavaScript內容來實現。如果JavaScript在伺服器的響應中被重放，頁面就會停止渲染，並展示一個錯誤頁來取代。

X-XSS-Protection協議頭用來控制XSS過濾器的操作。

要在瀏覽器中啟用XSS過濾器，並且強制它一直遮蔽可疑的XSS攻擊，你可以在協議頭中傳遞X-XSS-Protection: 1; mode=block。 如果SECURE_BROWSER_XSS_FILTER設定為True，SecurityMiddleware會在所有響應中這樣做。

警告

瀏覽器的XSS過濾器是一個十分有效的手段，但是不要過度依賴它。它並不能檢測到所有的XSS攻擊，也不是所有瀏覽器都支援這一協議頭。確保你校驗和過濾了所有的輸入來防止XSS攻擊。

SSL重定向

如果你同時提供HTTP和HTTPS連線，大多數使用者會預設使用不安全的（HTTP）連結。為了更高的安全性，你應該講所有HTTP連線重定向到HTTP連線。

如果你將SECURE_SSL_REDIRECT設定為True，SecurityMiddleware會將HTTP連結永久地（HTTP 301，permanently）重定向到HTTPS連線。

注意

由於效能因素，最好在Django外面執行這些重定向，在nginx這種前端負載均衡器或者反向代理伺服器中執行。SECURE_SSL_REDIRECT專門為這種部署情況而設計，當這不可選擇的時候。

如果SECURE_SSL_HOST設定有一個值，所有重定向都會發到值中的主機，而不是原始的請求主機。

如果你站點上的一些頁面應該以HTTP方式提供，並且不需要重定向到HTTPS，你可以SECURE_REDIRECT_EXEMPT設定中列出匹配那些url的正規表示式。

注意

如果你在負載均衡器或者反向代理伺服器後面部署應用，而且Django不能辨別出什麼時候一個請求是安全的，你可能需要設定SECURE_PROXY_SSL_HEADER。

會話中介軟體

class SessionMiddleware[source]

開啟會話支援。詳見會話文件。

站點中介軟體

class CurrentSiteMiddleware[source]

Django 1.7中新增

向每個接收到的HttpRequest物件新增一個site屬性，表示當前的站點。詳見站點文件。

認證中介軟體

class AuthenticationMiddleware[source]

向每個接收到的HttpRequest物件新增user屬性，表示當前登入的使用者。詳見web請求中的認證。

class RemoteUserMiddleware[source]

使用web伺服器提供認證的中介軟體。詳見使用REMOTE_USER進行認證。

class SessionAuthenticationMiddleware[source]

Django 1.7中新增

當使用者修改密碼的時候使使用者的會話失效。詳見密碼更改時的會話失效。在MIDDLEWARE_CLASSES中，這個中介軟體必須出現在django.contrib.auth.middleware.AuthenticationMiddleware之後。

CSRF保護中介軟體

class CsrfViewMiddleware[source]

新增跨站點請求偽造的保護，通過向POST表單新增一個隱藏的表單欄位，並檢查請求中是否有正確的值。詳見CSRF保護文件。

X-Frame-Options中介軟體

class XFrameOptionsMiddleware[source]

通過X-Frame-Options協議頭進行簡單的點選劫持保護。

中介軟體的排序

下面是一些關於Django中介軟體排序的提示。

UpdateCacheMiddleware

放在修改大量協議頭的中介軟體(SessionMiddleware, GZipMiddleware, LocaleMiddleware)之前。

GZipMiddleware

放在任何可能修改或使用響應訊息體的中介軟體之前。

放在UpdateCacheMiddleware之後：會修改大量的協議頭。

ConditionalGetMiddleware

放在CommonMiddleware之前：當USE_ETAGS = True時會使用它的Etag 協議頭。

SessionMiddleware

放在UpdateCacheMiddleware之後：會修改 大量協議頭。

LocaleMiddleware

放在SessionMiddleware（由於使用會話資料）和 CacheMiddleware（由於要修改大量協議頭）之後的最上面。

CommonMiddleware

放在任何可能修改相應的中介軟體之前（因為它會生成ETags）。

在GZipMiddleware之後，不會在壓縮後的內容上再去生成ETag。

儘可能放在靠上面的位置，因為APPEND_SLASH或者PREPEND_WWW設定為 True時會被重定向。

CsrfViewMiddleware

放在任何假設CSRF攻擊被處理的檢視中介軟體之前。

AuthenticationMiddleware

放在SessionMiddleware之後：因為它使用會話儲存。

MessageMiddleware

放在SessionMiddleware之後：會使用基於會話的儲存。

FetchFromCacheMiddleware

放在任何修改大量協議頭的中介軟體之後：協議頭被用來從快取的雜湊表中獲取值。

FlatpageFallbackMiddleware

應該放在最底下，因為他是中介軟體中的底牌。

RedirectFallbackMiddleware

應該放在最底下，因為他是中介軟體中的底牌。