Среднесвязь

В данном документе описаны все компоненты среднесвязи, поставляемые с 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()
  

• Устанавливает заголовок 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 [source]

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

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

class SecurityMiddleware

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

• SECURE_CONTENT_TYPE_NOSNIFF
• SECURE_CROSS_ORIGIN_OPENER_POLICY
• SECURE_HSTS_INCLUDE_SUBDOMAINS
• SECURE_HSTS_PRELOAD
• SECURE_HSTS_SECONDS
• SECURE_REDIRECT_EXEMPT
• SECURE_REFERRER_POLICY
• SECURE_SSL_HOST
• SECURE_SSL_REDIRECT

HTTP Strict Transport Security

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

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

SecurityMiddleware может установить заголовок 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 в качестве переадресации.

Политика открытия разнородного происхождения

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

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

same-origin

Изолирует контекст просмотра исключительно для документов с однородным происхождением. Документы разнородного происхождения не загружаются в том же контексте просмотра. Это наиболее надёжный вариант по умолчанию.

same-origin-allow-popups

Изолирует контекст просмотра для документов с однородным происхождением или тех, которые не устанавливают 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 предоставляется непосредственно вашим веб-сервером front-end (nginx, Apache и т.д.), то вам следует установить этот заголовок там. С другой стороны, если вы используете Django для чего-то вроде требования авторизации для загрузки файлов, и вы не можете установить заголовок с помощью вашего веб-сервера, эта настройка будет полезна.

Переадресация 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 [source]

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

Средства промежуточного слоя аутентификации

class AuthenticationMiddleware

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

class RemoteUserMiddleware

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

class PersistentRemoteUserMiddleware

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

Средства промежуточного слоя защиты CSRF

class CsrfViewMiddleware

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

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

class XFrameOptionsMiddleware [source]

Простая защита от clickjacking с помощью заголовка 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

    Должен находиться в конце, так как он представляет собой средство промежуточного слоя последней инстанции.