Среднесвязь

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

max_random_bytes

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

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

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

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

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

Если ответ имеет заголовок ETag , ETag делается слабым для соответствия RFC 9110#section-8.8.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_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-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), в противном случае ваш сайт может оставаться уязвимым через небезопасное соединение с поддоменом.

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

Политика Referrer

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

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

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

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

no-referrer-when-downgrade

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

origin

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

origin-when-cross-origin

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

same-origin

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

strict-origin

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

strict-origin-when-cross-origin

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

unsafe-url

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

Политика открытия с разных источников

Некоторые браузеры имеют возможность изолировать окна верхнего уровня от других документов, помещая их в отдельную группу контекстов просмотра на основе значения заголовка 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

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

Средства мидлвеара аутентификации

class AuthenticationMiddleware

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

class RemoteUserMiddleware

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

class PersistentRemoteUserMiddleware

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

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

class CsrfViewMiddleware

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

Средства мидлвеара X-Frame-Options

class XFrameOptionsMiddleware

Простая защита от 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

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