ПОСРЕДНИЧНЫЙ СЛОЙ

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

• Устанавливает заголовок 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().

Посреднический слой условного GET

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]

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

• 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

HTTP Strict Transport Security

Для сайтов, которые должны быть доступны только через 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), в противном случае ваш сайт может оставаться уязвимым через небезопасное соединение с поддоменом.

Если вы хотите добавить свой сайт в список предварительной загрузки браузеров browser preload list, установите значение параметра 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 и проверки запросов на соответствие правильному значению. См. документацию по защите от поддельных межсайтовых запросов.

X-Frame-Options средства промежуточного программного обеспечения

class XFrameOptionsMiddleware [source]

Простая защита от кликджекинга через заголовок 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

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