Spec-Zone.ru › Django 6.0

Промежуточное ПО

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

Доступное промежуточное ПО

Промежуточное ПО для кэширования

class UpdateCacheMiddleware [исходный код]
class FetchFromCacheMiddleware [исходный код]

Включает кэширование всего сайта. Если это промежуточное ПО включено, каждая страница на Django будет кэшироваться в течение времени, заданного параметром CACHE_MIDDLEWARE_SECONDS. См. документацию по кэшированию.

«Общее» промежуточное ПО

class CommonMiddleware [исходный код]
response_redirect_class

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

Добавляет несколько удобных функций для перфекционистов:

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

  • Выполняет перезапись URL на основе параметров APPEND_SLASH и PREPEND_WWW.

    Если параметр APPEND_SLASH имеет значение True, исходный URL не заканчивается косой чертой и отсутствует в URLconf, в конце URL добавляется косая черта. Если новый URL найден в URLconf, Django перенаправляет запрос на него. В противном случае исходный URL обрабатывается как обычно.

    Например, foo.com/bar будет перенаправлен на foo.com/bar/, если для foo.com/bar нет допустимого шаблона URL, но есть допустимый шаблон для 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 для ответов, не передаваемых потоково.
class BrokenLinkEmailsMiddleware [исходный код]
  • Отправляет уведомления о неработающих ссылках по электронной почте адресатам из параметра MANAGERS (см. Как управлять отправкой сообщений об ошибках).

Промежуточное ПО GZip

class GZipMiddleware [исходный код]
max_random_bytes

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

Примечание

Исследователи безопасности выяснили, что использование на веб-сайте методов сжатия (включая GZipMiddleware) может сделать сайт уязвимым для ряда атак.

Для снижения риска атак Django применяет метод под названием Heal The Breach (HTB). Он добавляет к каждому ответу до 100 случайных байтов (см. max_random_bytes), чтобы снизить эффективность атак.

Подробнее см. в статье о BREACH (PDF), на сайте breachattack.com и в статье о Heal The Breach (HTB).

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

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

Содержимое НЕ будет сжато в следующих случаях:

  • Длина тела содержимого меньше 200 байт.
  • В ответе уже установлен заголовок Content-Encoding.
  • Запрос (браузер) не содержит заголовок Accept-Encoding со значением gzip.

Если в ответе есть заголовок ETag, ETag становится слабым в соответствии с разделом 8.8.1 RFC 9110.

Сжатие GZip можно применить к отдельным представлениям с помощью декоратора gzip_page().

Промежуточное ПО для условных GET-запросов

class ConditionalGetMiddleware [исходный код]

Обрабатывает условные GET-запросы. Если в ответе нет заголовка ETag, промежуточное ПО добавляет его при необходимости. Если в ответе есть заголовок ETag или Last-Modified, а запрос содержит If-None-Match или If-Modified-Since, ответ заменяется на HttpResponseNotModified.

Условные GET-запросы можно обрабатывать в отдельных представлениях с помощью декоратора conditional_page().

Промежуточное ПО для локализации

class LocaleMiddleware [исходный код]
response_redirect_class

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

Включает выбор языка на основе данных запроса. Настраивает содержимое для каждого пользователя. См. документацию по интернационализации.

Промежуточное ПО для сообщений

class MessageMiddleware [исходный код]

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

Промежуточное ПО для безопасности

Предупреждение

Если условия развертывания позволяют, обычно лучше поручить внешнему веб-серверу выполнять функции, предоставляемые SecurityMiddleware. В этом случае запросы, которые обрабатываются не Django (например, запросы к статическим файлам или файлам, загруженным пользователями), будут защищены так же, как запросы к приложению Django.

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

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

Предупреждение

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

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

Примечание

Если ваше приложение работает за балансировщиком нагрузки или обратным прокси-сервером, а заголовок Strict-Transport-Security не добавляется к ответам, возможно, Django не распознает, что соединение защищено; может потребоваться установить параметр SECURE_PROXY_SSL_HEADER.

Политика Referer

Браузеры используют заголовок 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, система защиты Django от CSRF требует наличия заголовка Referer, поэтому полное отключение заголовка Referer нарушит защиту от CSRF. Чтобы воспользоваться большинством преимуществ отключения заголовков Referer и при этом сохранить защиту от CSRF, рассмотрите возможность разрешить отправку источника перехода только для ссылок на тот же источник.

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 в качестве источника перехода.

Неизвестные значения политики

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

Политика изоляции окон от источников

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

Примечание

Для повышения производительности перенаправления предпочтительно выполнять вне Django — на внешнем балансировщике нагрузки или обратном прокси-сервере, например nginx. Параметр SECURE_SSL_REDIRECT предназначен для случаев развертывания, когда это невозможно.

Если параметр SECURE_SSL_HOST имеет значение, все перенаправления будут отправляться на этот хост, а не на хост, изначально запрошенный пользователем.

Если на вашем сайте есть несколько страниц, которые должны быть доступны по HTTP и не перенаправляться на HTTPS, можно перечислить регулярные выражения для соответствующих URL в параметре SECURE_REDIRECT_EXEMPT.

Примечание

Если приложение работает за балансировщиком нагрузки или обратным прокси-сервером, а Django не может определить, что запрос уже является безопасным, может потребоваться установить параметр SECURE_PROXY_SSL_HEADER.

Промежуточное ПО для сеансов

class SessionMiddleware [исходный код]

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

Промежуточное ПО для сайтов

class CurrentSiteMiddleware [исходный код]

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

Промежуточное ПО аутентификации

class AuthenticationMiddleware [исходный код]

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

class LoginRequiredMiddleware [исходный код]

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

redirect_field_name

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

get_login_url() [исходный код]

Возвращает URL, на который будут перенаправляться неаутентифицированные запросы. Результатом будет либо login_url, заданный в декораторе login_required() (если он не равен None), либо settings.LOGIN_URL.

get_redirect_field_name() [исходный код]

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

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

Убедитесь, что для представления входа не требуется вход в систему.

Чтобы избежать бесконечных перенаправлений, убедитесь, что для представления входа разрешены неаутентифицированные запросы.

class RemoteUserMiddleware [исходный код]

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

class PersistentRemoteUserMiddleware [исходный код]

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

Промежуточное ПО для защиты от CSRF

class CsrfViewMiddleware [исходный код]

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

Защиту от межсайтовой подделки запросов можно добавить к отдельным представлениям с помощью декоратора csrf_protect().

Промежуточное ПО X-Frame-Options

class XFrameOptionsMiddleware [исходный код]

Простая защита от кликджекинга с помощью заголовка X-Frame-Options.

Промежуточное ПО Content Security Policy

class ContentSecurityPolicyMiddleware [исходный код]
Добавлено в Django 6.0.

Добавляет поддержку Content Security Policy (CSP), которая помогает снизить риски таких атак, как межсайтовый скриптинг (XSS) и внедрение данных, контролируя источники содержимого, загружаемого в браузере. Подробные сведения о настройке политик см. в обзоре документации.

Это промежуточное ПО устанавливает следующие заголовки ответа в зависимости от доступных параметров:

  • Content-Security-Policy на основе SECURE_CSP.
  • Content-Security-Policy-Report-Only на основе SECURE_CSP_REPORT_ONLY.

Порядок расположения промежуточного ПО

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

  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

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

  11. MessageMiddleware

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

  12. FetchFromCacheMiddleware

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

  13. ContentSecurityPolicyMiddleware

    Можно расположить ближе к концу списка, но убедитесь, что любое промежуточное ПО, обращающееся к csp_nonce, расположено после него, чтобы nonce был правильно включён в заголовок ответа.

  14. FlatpageFallbackMiddleware

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

  15. RedirectFallbackMiddleware

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

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/6.0/ref/middleware/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API