Среднесвязь

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

Среднесвязь 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 и сеансов. См. документацию по сообщениям.

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

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

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.

Политика Referrer

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

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

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

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

• Один и тот же origin или разный origin: ссылка из 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.

Django может установить заголовок 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 для ссылок одного origin и только origin для ссылок другого origin.

same-origin

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

strict-origin

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

strict-origin-when-cross-origin

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

unsafe-url

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

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

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