Среднее ПО

В данном документе описаны все компоненты среднего ПО, которые поставляются с Django. Дополнительную информацию о том, как использовать эти компоненты и как создать собственное среднее ПО, можно найти в руководстве по использованию среднего ПО.

Доступное среднее ПО

Среднее ПО кэширования

class UpdateCacheMiddleware [source]

class FetchFromCacheMiddleware [source]

Включает кэширование для всего сайта. Если эти компоненты включены, каждая страница, работающая на Django, будет кэшироваться на срок, определенный настройкой CACHE_MIDDLEWARE_SECONDS. См. документацию по кэшированию.

“Общее” среднее ПО

class CommonMiddleware [source]

Добавляет несколько удобств для педантов:

• Запрещает доступ к пользовательским агентам, указанным в настройке 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, если это необходимо.
• Устанавливает заголовок Content-Length для ответов, не являющихся потоковыми.

CommonMiddleware.response_redirect_class

По умолчанию, HttpResponsePermanentRedirect. Подклассы CommonMiddleware и переопределение атрибута позволяют настраивать перенаправления, выполняемые средним ПО.

class BrokenLinkEmailsMiddleware [source]

• Отправляет уведомления об ошибочных ссылках по электронной почте получателям MANAGERS (см. Отчёт об ошибках).

Среднее ПО GZip

class GZipMiddleware [source]

Сжимает содержимое для браузеров, поддерживающих сжатие GZip (все современные браузеры).

Это среднее ПО должно быть размещено перед другими средними ПО, которым необходимо читать или писать тело ответа, чтобы сжатие происходило позже.

Сжатие НЕ будет применяться, если выполняются следующие условия:

• Тело содержимого меньше 200 байт.
• Ответ уже установил заголовок Content-Encoding.
• Запрос (браузер) не отправил заголовок Accept-Encoding с содержимым gzip.

Если у ответа есть заголовок ETag , ETag делается слабым, чтобы соответствовать RFC 7232#section-2.1.

Вы можете применять GZip-сжатие к отдельным представлениям, используя декоратор gzip_page().

Среднее ПО условного получения

class ConditionalGetMiddleware [source]

Обрабатывает условные запросы GET. Если у ответа нет заголовка ETag , среднее ПО добавляет его, если необходимо. Если у ответа есть заголовок ETag или Last-Modified , а у запроса есть заголовки If-None-Match или If-Modified-Since, ответ заменяется на HttpResponseNotModified.

Среднее ПО локализации

class LocaleMiddleware [source]

Включает выбор языка на основе данных из запроса. Настраивает контент для каждого пользователя. См. документацию по международной локализации.

LocaleMiddleware.response_redirect_class

По умолчанию HttpResponseRedirect. Подклассы LocaleMiddleware и переопределение атрибута позволяют настраивать перенаправления, выполняемые средним ПО.

Среднее ПО сообщений

class MessageMiddleware [source]

Включает поддержку сообщений на основе cookie и сессии. См. документацию по сообщениям.

Среднее ПО безопасности

class SecurityMiddleware [source]

Модуль django.middleware.security.SecurityMiddleware предоставляет несколько улучшений безопасности для цикла запроса/ответа. Каждый из них можно независимо включить или выключить с помощью настроек.

• 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

Строгий протокол безопасности HTTPS

Для сайтов, к которым следует обращаться только по протоколу HTTPS, можно настроить современные браузеры на отказ от подключения к вашему домену через небезопасное соединение (в течение заданного периода времени), установив заголовок “Strict-Transport-Security”. Это уменьшает вашу уязвимость к некоторым атакам типа «человек посередине» (MITM) с подменой SSL.

SecurityMiddleware установит этот заголовок для всех ответов HTTPS, если вы установите значение настройки SECURE_HSTS_SECONDS на ненулевое целое число.

При включении HSTS рекомендуется сначала использовать небольшое значение для тестирования, например, SECURE_HSTS_SECONDS = 3600 для одного часа. Каждый раз, когда веб-браузер видит заголовок HSTS с вашего сайта, он откажется от связи с вашим доменом по небезопасному протоколу (HTTP) на заданный период времени. После подтверждения, что все ресурсы на вашем сайте обслуживаются безопасно (т.е. HSTS не сломал ничего), рекомендуется увеличить это значение, чтобы защитить нечастых посетителей (31536000 секунд, т.е. 1 год, является распространенным значением).

Кроме того, если вы установите значение настройки SECURE_HSTS_INCLUDE_SUBDOMAINS на True, SecurityMiddleware добавит директиву includeSubDomains к заголовку Strict-Transport-Security. Это рекомендуется (при условии, что все поддомены обслуживаются исключительно по HTTPS), в противном случае ваш сайт может оставаться уязвимым через небезопасное соединение с поддоменом.

Если вы хотите добавить свой сайт в список предварительной загрузки браузеров, установите значение настройки SECURE_HSTS_PRELOAD на True. Это добавит директиву preload к заголовку Strict-Transport-Security.

X-Content-Type-Options: nosniff

Некоторые браузеры пытаются угадать типы содержимого извлекаемых ресурсов, переопределяя заголовок Content-Type. Хотя это может помочь отобразить сайты с неправильно настроенными серверами, это также может представлять собой угрозу безопасности.

Если ваш сайт обслуживает загруженные пользователем файлы, злоумышленник может загрузить специально созданный файл, который браузер интерпретирует как HTML или JavaScript, когда ожидалось что-то безобидное.

Чтобы предотвратить угадывание браузером типа содержимого и принудительно использовать тип, указанный в заголовке Content-Type , вы можете передать заголовок X-Content-Type-Options: nosniff. SecurityMiddleware сделает это для всех ответов, если значение настройки SECURE_CONTENT_TYPE_NOSNIFF равно True.

Обратите внимание, что в большинстве случаев развертывания, где Django не участвует в обслуживании загруженных пользователем файлов, эта настройка не поможет. Например, если ваш MEDIA_URL обслуживается непосредственно вашим веб-сервером (nginx, Apache и т.д.), то вы должны установить этот заголовок там. С другой стороны, если вы используете Django для таких задач, как проверка авторизации при загрузке файлов, и вы не можете установить заголовок с помощью веб-сервера, эта настройка будет полезна.

X-XSS-Protection: 1; mode=block

Некоторые браузеры могут блокировать содержимое, которое выглядит как атака XSS. Они работают, обнаруживая JavaScript-содержимое в параметрах GET или POST страницы. Если JavaScript воспроизводится в ответе сервера, отображение страницы блокируется, и вместо неё отображается страница ошибки.

Заголовок X-XSS-Protection используется для управления работой фильтра XSS.

Чтобы включить фильтр XSS в браузере и всегда блокировать предполагаемые атаки XSS, вы можете передать заголовок X-XSS-Protection: 1; mode=block. SecurityMiddleware сделает это для всех ответов, если значение настройки SECURE_BROWSER_XSS_FILTER равно True.

Переадресация SSL

Если ваш сайт предлагает подключения HTTP и HTTPS, по умолчанию большинство пользователей будут использовать небезопасное соединение. Для максимальной безопасности вы должны перенаправлять все HTTP-соединения на HTTPS.

Если вы установите значение настройки SECURE_SSL_REDIRECT на True, SecurityMiddleware будет постоянно (HTTP 301) перенаправлять все HTTP-соединения на HTTPS.

Если у настройки SECURE_SSL_HOST есть значение, все перенаправления будут отправляться на этот хост вместо исходно запрошенного хоста.

Если на вашем сайте есть несколько страниц, которые должны быть доступны по протоколу HTTP, а не перенаправляться на HTTPS, вы можете указать регулярные выражения для соответствия этим URL-адресам в настройке SECURE_REDIRECT_EXEMPT.

Средства обработки сессий

class SessionMiddleware [source]

Включает поддержку сессий. Смотрите документацию по сессиям.

Средства обработки сайтов

class CurrentSiteMiddleware [source]

Добавляет атрибут site, представляющий текущий сайт, к каждому поступающему объекту HttpRequest. См. документацию по сайтам.

Средства обработки аутентификации

class AuthenticationMiddleware

Добавляет атрибут user, представляющий текущего пользователя, к каждому поступающему объекту HttpRequest. Смотрите аутентификацию в веб-запросах.

class RemoteUserMiddleware

Средства обработки для использования аутентификации веб-сервера. Подробности использования см. в аутентификации с помощью REMOTE_USER.

class PersistentRemoteUserMiddleware

Средства обработки для использования аутентификации веб-сервера, но только на странице входа. Подробности использования см. в использовании REMOTE_USER только на страницах входа.

Защита от CSRF-атак

class CsrfViewMiddleware [source]

Обеспечивает защиту от атак методом подделки межсайтовых запросов (CSRF) путём добавления скрытых полей в формы POST и проверки запросов на соответствие значениям. См. документацию по защите от атак CSRF.

X-Frame-Options

class XFrameOptionsMiddleware [source]

Простая защита от кликджекинга с помощью заголовка X-Frame-Options.

Порядок middleware

Ниже приведены рекомендации по порядку следования различных классов Django middleware:

1. SecurityMiddleware

   Этот middleware следует разместить в начале списка, если вы используете перенаправление на HTTPS, так как это позволит избежать лишней обработки других middleware.

2. UpdateCacheMiddleware

   До middleware, которые изменяют заголовок Vary (SessionMiddleware, GZipMiddleware, LocaleMiddleware).

3. GZipMiddleware

   Перед любым middleware, который может изменить или использовать тело ответа.

   После UpdateCacheMiddleware: Модифицирует заголовок Vary.

4. ConditionalGetMiddleware

   Перед CommonMiddleware: использует заголовок ETag при USE_ETAGS = True.

5. SessionMiddleware

   После UpdateCacheMiddleware: Модифицирует заголовок Vary.

6. LocaleMiddleware

   Один из верхних middleware, после SessionMiddleware (использует данные сессии) и UpdateCacheMiddleware (модифицирует заголовок Vary).

7. CommonMiddleware

   Перед любым middleware, который может изменить ответ (вычисляет ETags).

   После GZipMiddleware для избежания вычисления заголовка ETag для сжатых данных.

   Ближе к началу: перенаправляет, если APPEND_SLASH или PREPEND_WWW установлены в значение True.

8. CsrfViewMiddleware

   Перед любым view middleware, предполагающим обработку атак CSRF.

   Должен следовать за SessionMiddleware при использовании CSRF_USE_SESSIONS.

9. AuthenticationMiddleware

   После SessionMiddleware: использует хранилище сессий.

10. MessageMiddleware

    После SessionMiddleware: может использовать хранилище сессий.

11. FetchFromCacheMiddleware

    После любого middleware, изменяющего заголовок Vary: этот заголовок используется для выбора значения ключа кэша.

12. FlatpageFallbackMiddleware

    Должен стоять близко к концу, так как это middleware последней инстанции.

13. RedirectFallbackMiddleware

    Должен стоять близко к концу, так как это middleware последней инстанции.