Этот раздел описывает промежуточные слои, которые предоставляет Django. Как использовать и создавать свои промежуточные слои, смотрите соответствующий раздел.
Активирует кэширование для всего сайта. При этом все страницы, которые генерируются Django, будут закэшированы на время, указанное в настройке CACHE_MIDDLEWARE_SECONDS. Смотрите раздел о кэшировании.
Добавляет несколько полезностей для перфекционистов:
Ограничивает доступ для клиентов, которые указанны в настройке DISALLOWED_USER_AGENTS. Настройка должна содержать список скомпилированных регулярных выражений.
Меняет URL в соответствии с настройками APPEND_SLASH и PREPEND_WWW.
Если APPEND_SLASH равна True и вызванный URL не оканчивается на слеш, и он не найден в URLconf, создается новый URL путем добавления слеша в конец. Если новый URL найден в URLconf, Django отправляет перенаправление на этот URL. Иначе начальный URL обрабатывается как обычно.
Например, foo.com/bar будет перенаправлен на foo.com/bar/, если нет URL-шаблона для foo.com/bar, но есть для foo.com/bar/.
Если PREPEND_WWW равна True, URL-ы без “www.” будут перенаправлены на URL с добавлением “www.”
Обе эти настройки предназначены для нормализации URL-ов. Философия такая - URL должен быть уникальным и единым. Технически URL foo.com/bar отличается от foo.com/bar/ - поисковик проиндексирует их как отдельные URL-ы - по этому хорошей практикой является нормализация URL-ов.
Обрабатываете ETag с учетом настройки USE_ETAGS. Если USE_ETAGS равна True, Django вычислит ETag для каждого запроса, используя MD5-хеш содержимого страницы, и отправит ответ Not Modified при возможности.
Отсылает уведомления о сломанных ссылках на MANAGERS (смотрите Отчёты об ошибках).
Предупреждение
Исследователи безопасности определили, что при применении сжатия на сайте (включая GZipMiddleware), ваш сайт становится уязвим к некоторым типам атак. Они могут использоваться для обхода CSRF защиты. Перед использованием GZipMiddleware обдумайте на сколько это критично для вас. Если у вас есть малейшие сомнений, не используйте GZipMiddleware. Подробности смотрите в исследовании BREACH (PDF) и breachattack.com.
Сжимает ответ для браузеров, которые поддерживают GZip (все современные браузеры).
Этот промежуточный слой должен находится перед любым другим промежуточный слоем, который читает или пишет содержимое ответа, чтобы сжатие происходило в самом конце.
Содержимое ответа НЕ будет сжато при следующих условиях:
Содержимое ответа меньше 200 байтов.
Ответ уже содержит заголовок Content-Encoding.
Браузер не отослал в запросе заголовок Accept-Encoding, который содержит gzip.
Запрос от Internet Explorer и заголовок Content-Type содержит javascript, или начинается не с text/. Это связано с багом в IE, который приводит к неправильной обработке сжатого ответа для некоторых типов ответа.
Вы можете добавить GZip сжатие для определенных представлений, используя декоратор gzip_page().
Обрабатывает условные GET операции. Если ответ содержит заголовки ETag или Last-Modified, и запрос содержит If-None-Match или If-Modified-Since, ответ заменяется на HttpResponseNotModified.
Также устанавливает для ответа заголовки Date и Content-Length.
Выполняет выбор текущего языка на основе данных из запроса. Меняет содержимое для каждого пользователя отдельно. Смотрите раздел об интернационализации.
По умолчанию HttpResponseRedirect. Можете создать класс наследник LocaleMiddleware и переопределить класс ответа, который используется для перенаправления.
Добавляет поддержку сообщений на основе кук или сессии. Смотрите раздел о сообщениях.
Включает поддержку сессии. Смотрите раздел о сессии.
Добавляет атрибут site, который указывает текущий сайт для каждого объекта HttpRequest. Смотрите раздел о поддержке нескольких сайтов.
Добавляет атрибут user, который указывает текущего авторизованного пользователя, для каждого объекта HttpRequest. Смотрите раздел об авторизации.
Промежуточный слой для внешней авторизации. Смотрите Аутентификация при помощи REMOTE_USER.
Позволяет удалить сессию пользователя при смене пароля. Смотрите Session invalidation on password change. Добавлять после django.contrib.auth.middleware.AuthenticationMiddleware в MIDDLEWARE_CLASSES.
Включает CSRF защиту, добавляя скрытое поле в POST формы и проверяя значение при запросе. Смотрите раздел о Cross Site Request Forgery защите.
TransactionMiddleware устарел. В разделе о транзакциях можно найти инструкцию по обновлению.
Оборачивает каждый запрос в транзакцию базы данных. Если запрос обработан без исключений, изменения будут закоммичены в базу данных. Если произошла ошибка, все изменения будут отменены.
Очень важен порядок выполнения этого промежуточного слоя: промежуточные слои, которые идут перед этим, будут использовать стандартное поведение Django “commit-on-save”. Промежуточный слои после этого будут включены в транзакцию, как и представления.
Смотрите раздел о транзакциях.
Добавляет простую защиту от “clickjacking”, используя заголовок X-Frame-Options.
Несколько советов о порядке промежуточных слоёв Django:
Добавлять перед промежуточными слоями, которые могут изменить заголовок Vary (SessionMiddleware, GZipMiddleware, LocaleMiddleware).
Добавлять перед промежуточными слоями, которые могут изменять или читать тело ответа.
После UpdateCacheMiddleware: изменяет заголовок Vary.
Перед CommonMiddleware: использует установленный заголовок Etag при USE_ETAGS = True.
После UpdateCacheMiddleware: изменяет заголовок Vary.
После SessionMiddleware (использует сессию) и CacheMiddleware (изменяет заголовок Vary).
Перед любым промежуточным слоем, который может изменять ответ (вычисляет ETags).
После GZipMiddleware, чтобы заголовок ETag не вычислялся для сжатого ответа.
Ближе к верху: выполняет перенаправление при APPEND_SLASH или PREPEND_WWW равном True.
Перед любым промежуточным слоем, который предполагает, что CSRF защита уже выполнена.
После SessionMiddleware: использует сессию.
После SessionMiddleware: может использовать сессию для хранения данных.
После любого промежуточного слоя, который может изменить заголовок Vary: его значение используется для генерации ключа в кеше.
Должен быть в низу.
Должен быть в низу.
Mar 30, 2016