ПОСРЕДНИК

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

Доступные промежуточные программные модули

Промежуточное программное обеспечение кэша

class UpdateCacheMiddleware

class FetchFromCacheMiddleware

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

Промежуточное программное обеспечение «Общие»

class CommonMiddleware

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

Запрещает доступ к пользовательским агентам в настройке 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.

При необходимости отдельные представления могут быть исключены из поведения APPEND_SLASH с помощью декоратора no_append_slash():
```
from django.views.decorators.common import no_append_slash

@no_append_slash
def sensitive_fbv(request, *args, **kwargs):
    """View to be excluded from APPEND_SLASH."""
    return HttpResponse()
```
Изменено в Django 3.2:
Добавлена поддержка декоратора no_append_slash().
Устанавливает заголовок Content-Length для ответов, которые не являются потоковыми.

CommonMiddleware.response_redirect_class

По умолчанию HttpResponsePermanentRedirect. Подклассифицируйте CommonMiddleware и переопределите атрибут для настройки перенаправлений, выполняемых промежуточным программным обеспечением.

class BrokenLinkEmailsMiddleware

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

Промежуточное программное обеспечение GZip

class GZipMiddleware

Предупреждение

Недавно исследователи в области информационной безопасности обнаружили, что при использовании методов сжатия (включая GZipMiddleware) на веб-сайте сайт может быть подвержен ряду возможных атак. Перед использованием GZipMiddleware на вашем сайте следует очень тщательно взвесить, подвержены ли вы этим атакам. Если вы даже немного сомневаетесь в том, подвержены ли вы, следует избегать использования GZipMiddleware. Более подробную информацию см. в статье статье BREACH (PDF) и на breachattack.com.

Промежуточное программное обеспечение django.middleware.gzip.GZipMiddleware сжимает контент для браузеров, поддерживающих сжатие GZip (все современные браузеры).

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

Он не будет сжимать контент, если выполняется одно из следующих условий:

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

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

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

Промежуточное программное обеспечение условного получения

class ConditionalGetMiddleware

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

Промежуточное программное обеспечение локализации

class LocaleMiddleware

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

LocaleMiddleware.response_redirect_class

По умолчанию HttpResponseRedirect. Подклассифицируйте LocaleMiddleware и переопределите атрибут для настройки перенаправлений, выполняемых промежуточным программным обеспечением.

Промежуточное программное обеспечение сообщений

class MessageMiddleware

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

Промежуточное программное обеспечение безопасности

Предупреждение

Если ваша среда развертывания позволяет, обычно лучше, чтобы ваш веб-сервер в front-end выполнял функции, предоставляемые модулем SecurityMiddleware. Таким образом, если есть запросы, которые не обслуживаются Django (такие как статическая среда или файлы, загруженные пользователем), они будут иметь те же защиты, что и запросы в вашем приложении Django.

class SecurityMiddleware

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

HTTP Strict Transport Security

Для сайтов, которые должны быть доступны только по протоколу HTTPS, вы можете указать современным браузерам отказываться от подключения к вашему доменному имени через небезопасное соединение (на определенный период времени), установив заголовок “Strict-Transport-Security”. Это уменьшит уязвимость к некоторым атакам «man-in-the-middle» (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), в противном случае ваш сайт может оставаться уязвимым через небезопасное подключение к поддомену.

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

Предупреждение

Политика HSTS применяется ко всему вашему домену, а не только к URL-адресу ответа, на котором вы установили заголовок. Поэтому вы должны использовать её только если весь ваш домен обслуживается только через HTTPS.

Браузеры, корректно обрабатывающие заголовок HSTS, откажутся от разрешения пользователям игнорировать предупреждения и подключаться к сайту с истекшим, самоподписанным или иным образом недействительным сертификатом SSL. Если вы используете HSTS, убедитесь, что ваши сертификаты в хорошем состоянии и остаются таковыми!

Примечание

Если ваш сайт развернут за балансировщиком нагрузки или прокси-сервером, и заголовок Strict-Transport-Security не добавляется к вашим ответам, возможно, Django не понимает, что находится в защищённом соединении; вам может потребоваться установить значение SECURE_PROXY_SSL_HEADER.

Политика Referrer

Браузеры используют заголовок Referer для отправки информации на сайт о том, как пользователи туда попали. Когда пользователь нажимает ссылку, браузер отправляет полный URL-адрес страницы ссылки в качестве referer. Хотя это может быть полезно для некоторых целей – например, для выяснения того, кто ссылается на ваш сайт – это также может вызвать проблемы с конфиденциальностью, информируя один сайт о том, что пользователь посещал другой сайт.

Некоторые браузеры могут принимать подсказки о том, нужно ли отправлять заголовок HTTP Referer при нажатии пользователем ссылки; эта подсказка предоставляется через заголовок Referrer-Policy. Этот заголовок может предложить браузерам любое из трёх поведений:

Полный URL: отправляет весь URL в заголовке Referer. Например, если пользователь посещает https://example.com/page.html, заголовок Referer будет содержать "https://example.com/page.html".
Только Origin: отправляет только «origin» в referer. Origin состоит из схемы, хоста и (необязательно) номера порта. Например, если пользователь посещает https://example.com/page.html, origin будет https://example.com/.
Без referer: не отправляет заголовок Referer вообще.

Существует два типа условий, которые этот заголовок может сказать браузеру, чтобы обратить на них внимание:

Один и тот же origin против разных origins: ссылка из https://example.com/1.html в https://example.com/2.html является одинаковым origin. Ссылка из https://example.com/page.html в https://not.example.com/page.html является разным origin.
Снижение протокола: снижение происходит, если страница, содержащая ссылку, обслуживается через HTTPS, но страница, на которую ссылаются, не обслуживается через HTTPS.

Предупреждение

Когда ваш сайт обслуживается через HTTPS, система защиты CSRF Django Django’s CSRF protection system требует наличия заголовка Referer, поэтому полное отключение заголовка Referer повлияет на защиту CSRF. Чтобы получить большинство преимуществ от отключения заголовков Referer при одновременном сохранении защиты CSRF, рассмотрите возможность включения только referrers одного origin.

SecurityMiddleware может установить заголовок Referrer-Policy для вас, основываясь на настройке SECURE_REFERRER_POLICY (обратите внимание на написание: браузеры отправляют заголовок Referer при нажатии пользователем ссылки, но заголовок, дающий инструкции браузеру, как поступить, записывается как Referrer-Policy). Допустимые значения для этой настройки:

no-referrer: Указывает браузеру не отправлять referrer для ссылок, нажимаемых на этом сайте.
no-referrer-when-downgrade: Указывает браузеру отправлять полный URL в качестве referrer, но только когда не происходит снижение протокола.
origin: Указывает браузеру отправлять только origin, а не полный URL, в качестве referrer.
origin-when-cross-origin: Указывает браузеру отправлять полный URL в качестве referrer для ссылок одного origin и только origin для ссылок разных origins.
same-origin: Указывает браузеру отправлять полный URL, но только для ссылок одного origin. Никакой referrer не будет отправлен для ссылок разных origins.
strict-origin: Указывает браузеру отправлять только origin, а не полный URL, и не отправлять referrer при снижении протокола.
strict-origin-when-cross-origin: Указывает браузеру отправлять полный URL, когда ссылка является одинаковым origin и не происходит снижение протокола; отправлять только origin, когда ссылка является разным origin и не происходит снижение протокола; и не отправлять referrer при снижении протокола.
unsafe-url: Указывает браузеру всегда отправлять полный URL в качестве referrer.

Неизвестные значения политики

В тех случаях, когда значение политики неизвестно для пользовательского агента, можно указать несколько значений политики, чтобы предоставить резервный вариант. Последнее указанное значение, которое понимается, имеет приоритет. Для поддержки этого можно использовать итерируемый объект или строку, разделенную запятыми, вместе с SECURE_REFERRER_POLICY.

Политика Cross-Origin Opener

Новая в Django 4.0.

Некоторые браузеры могут изолировать окна верхнего уровня от других документов, помещая их в отдельную группу контекстов просмотра на основе значения заголовка Cross-Origin Opener Policy (COOP). Если документ, изолированный таким образом, открывает всплывающее окно с разным origin, свойство window.opener всплывающего окна будет null. Изоляция окон с помощью COOP является защитой от атак с разными origins, особенно таких, как Spectre, которые позволяли извлечь данные, загруженные в общую группу контекстов просмотра.

SecurityMiddleware может установить заголовок Cross-Origin-Opener-Policy для вас на основе настройки SECURE_CROSS_ORIGIN_OPENER_POLICY. Допустимые значения для этой настройки:

same-origin: Изолирует контекст просмотра исключительно для документов с одинаковым origin. Документы с разными origins не загружаются в один и тот же контекст просмотра. Это по умолчанию наиболее безопасный вариант.
same-origin-allow-popups: Изолирует контекст просмотра для документов с одинаковым origin или тех, которые либо не устанавливают COOP, либо отказываются от изоляции, устанавливая COOP unsafe-none.
unsafe-none: Разрешает добавить документ в группу контекста просмотра его открывающего, если сам открывающий имеет COOP same-origin или same-origin-allow-popups.

`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 для чего-то вроде требования авторизации для скачивания файлов и не можете установить заголовок с помощью вашего веб-сервера, эта настройка будет полезна.

Перенаправление SSL

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

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

Примечание

По соображениям производительности предпочтительнее выполнять эти перенаправления вне Django, в балансировщике нагрузки или прокси-сервере на уровне front-end, например, nginx. SECURE_SSL_REDIRECT предназначен для ситуаций развертывания, где это невозможно.

END_OF_DOCUMENT_MARKER

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

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

Примечание

Если вы развернуты за балансировщиком нагрузки или обратным прокси-сервером и Django не может определить, когда запрос уже является защищённым, вам может потребоваться установить параметр SECURE_PROXY_SSL_HEADER.

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

class SessionMiddleware

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

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

class CurrentSiteMiddleware

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

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

class AuthenticationMiddleware

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

class RemoteUserMiddleware

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

class PersistentRemoteUserMiddleware

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

Средства обработки защиты CSRF

class CsrfViewMiddleware

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

Средства обработки X-Frame-Options

class XFrameOptionsMiddleware

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

Порядок обработки промежуточного ПО

Вот несколько советов по порядку расположения различных классов промежуточного ПО Django:

SecurityMiddleware

Его следует поместить в начало списка, если вы собираетесь включить перенаправление SSL, так как это предотвратит прохождение через другие ненужные средства обработки.
UpdateCacheMiddleware

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

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

После UpdateCacheMiddleware: Изменяет заголовок Vary.
SessionMiddleware

Перед любым промежуточным ПО, которое может вызвать исключение для активации представления об ошибке (например, PermissionDenied), если вы используете CSRF_USE_SESSIONS.

После UpdateCacheMiddleware: Изменяет заголовок Vary.
ConditionalGetMiddleware

Перед любым промежуточным ПО, которое может изменить ответ (оно устанавливает заголовок ETag).

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

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

Перед любым промежуточным ПО, которое может изменить ответ (оно устанавливает заголовок Content-Length). Средства обработки, которые появляются перед CommonMiddleware и изменяют ответ, должны сбросить Content-Length.

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

После SessionMiddleware если вы используете CSRF_USE_SESSIONS.
CsrfViewMiddleware

Перед любым средством обработки представлений, которое предполагает, что атаки CSRF были отражены.

Перед RemoteUserMiddleware, или любыми другими средствами обработки аутентификации, которые могут выполнить вход в систему и, следовательно, перегенерировать маркер CSRF, перед вызовом цепочки средств обработки.

После SessionMiddleware если вы используете CSRF_USE_SESSIONS.
AuthenticationMiddleware

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

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

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

Должно быть расположено в конце, так как это средство обработки последней инстанции.
RedirectFallbackMiddleware

Должно быть расположено в конце, так как это средство обработки последней инстанции.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/4.0/ref/middleware/