Среднее ПО

В этом документе описываются все компоненты среднего ПО, поставляемые с 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-адресов.

• Устанавливает заголовок Content-Length для ответов, которые не являются потоковыми.

CommonMiddleware.response_redirect_class

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

class BrokenLinkEmailsMiddleware

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

Среднее ПО GZip

class GZipMiddleware

Средство 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

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

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

class SecurityMiddleware

Средство 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_REFERRER_POLICY
• SECURE_SSL_HOST
• SECURE_SSL_REDIRECT

Строгий протокол HTTPS

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

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.

Политика переадресации

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

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

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

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

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

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

no-referrer

Указывает браузеру не отправлять переадресатор для ссылок, нажатых на этом сайте.

no-referrer-when-downgrade

Указывает браузеру отправлять полный URL в качестве переадресатора, но только если не происходит снижение протокола.

origin

Указывает браузеру отправлять только происхождение, а не полный URL, в качестве переадресатора.

origin-when-cross-origin

Указывает браузеру отправлять полный URL в качестве переадресатора для ссылок из одного домена и только происхождение для ссылок из другого домена.

same-origin

Указывает браузеру отправлять полный URL, но только для ссылок из одного домена. Переадресатор не будет отправлен для ссылок из другого домена.

strict-origin

Указывает браузеру отправлять только происхождение, а не полный URL, и не отправлять переадресатор при снижении протокола.

strict-origin-when-cross-origin

Указывает браузеру отправлять полный URL, если ссылка однодоменная и не происходит снижение протокола; отправлять только происхождение, если ссылка междоменная и не происходит снижение протокола; и не отправлять переадресатор, если происходит снижение протокола.

unsafe-url

Указывает браузеру всегда отправлять полный URL в качестве переадресатора.

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

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

Средства промежуточного ПО сайтов

class CurrentSiteMiddleware

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

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

class AuthenticationMiddleware

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

class RemoteUserMiddleware

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

class PersistentRemoteUserMiddleware

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

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

class CsrfViewMiddleware

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

X-Frame-Options средства

class XFrameOptionsMiddleware

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

Порядок следования средств

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

1. SecurityMiddleware

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

2. UpdateCacheMiddleware

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

3. GZipMiddleware

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

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

4. SessionMiddleware

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

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

5. ConditionalGetMiddleware

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

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

6. LocaleMiddleware

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

7. CommonMiddleware

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

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

   После SessionMiddleware при использовании CSRF_USE_SESSIONS.

8. CsrfViewMiddleware

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

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

   После SessionMiddleware при использовании CSRF_USE_SESSIONS.

9. AuthenticationMiddleware

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

10. MessageMiddleware

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

11. FetchFromCacheMiddleware

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

12. FlatpageFallbackMiddleware

    Следует размещать в нижней части, так как это средство последней инстанции.

13. RedirectFallbackMiddleware

    Следует размещать в нижней части, так как это средство последней инстанции.