Среднее ПО

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

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

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

Среднее ПО GZip

class GZipMiddleware [source]

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 [source]

Обрабатывает операции условного получения. Если в ответе нет заголовка 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]

Среднее ПО 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

Строгий контроль HTTPS-соединений

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

Политика пересылки Referrer

Браузеры используют заголовок 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

Указывает браузеру не отправлять 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 обрабатывается непосредственно вашим веб-сервером (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 [source]

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

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

class CurrentSiteMiddleware [source]

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

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

class AuthenticationMiddleware [source]

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

class LoginRequiredMiddleware [source]

Перенаправляет все незалогиненные запросы на страницу входа, за исключением представлений, исключённых с помощью login_not_required(). Страница входа по умолчанию settings.LOGIN_URL, но может быть настраиваемой.

Включите этот модуль промежуточного ПО, добавив его в настройку MIDDLEWARE **после** AuthenticationMiddleware:

MIDDLEWARE = [
    "...",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.auth.middleware.LoginRequiredMiddleware",
    "...",
]

Сделайте представление общедоступным, разрешая незалогиненные запросы, с помощью login_not_required(). Например:

from django.contrib.auth.decorators import login_not_required


@login_not_required
def contact_us(request): ...

Настройте URL-адрес входа или имя поля для аутентифицированных представлений с помощью декоратора login_required(), чтобы установить login_url или redirect_field_name соответственно. Например:

from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator
from django.views.generic import View


@login_required(login_url="/books/login/", redirect_field_name="redirect_to")
def book_dashboard(request): ...


@method_decorator(
    login_required(login_url="/books/login/", redirect_field_name="redirect_to"),
    name="dispatch",
)
class BookMetrics(View):
    pass

Методы и атрибуты

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

redirect_field_name

По умолчанию "next".

get_login_url()

Возвращает URL, на который будут перенаправлены незалогиненные запросы. Если определено, возвращает login_url установленное на декораторе login_required(). По умолчанию settings.LOGIN_URL.

get_redirect_field_name()

Возвращает имя параметра запроса, содержащего URL, на который пользователь должен быть перенаправлен после успешного входа в систему. Если определено, возвращает redirect_field_name установленное на декораторе login_required(). По умолчанию redirect_field_name. Если возвращается None, параметр запроса не будет добавлен.

class RemoteUserMiddleware [source]

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

class PersistentRemoteUserMiddleware [source]

Средство промежуточного ПО для использования аутентификации, предоставленной веб-сервером, когда оно включено только на странице входа. См. Использование 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. LoginRequiredMiddleware

    Новое в Django 5.1.

    После AuthenticationMiddleware: использует объект пользователя.

11. MessageMiddleware

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

12. FetchFromCacheMiddleware

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

13. FlatpageFallbackMiddleware

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

14. RedirectFallbackMiddleware

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