Spec-Zone.ru › Django 1.9

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

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

  • Обрабатывает ETags на основе настройки USE_ETAGS. Если USE_ETAGS установлено в True, Django вычислит ETag для каждого запроса, хешировав содержимое страницы с помощью MD5, и позаботится об отправке ответов Not Modified, если это необходимо.
CommonMiddleware.response_redirect_class

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

class BrokenLinkEmailsMiddleware [source]
  • Отправляет электронные письма об ошибочных ссылках адресатам MANAGERS (см. Отчёт об ошибках).

Промежуточное ПО сжатия GZip

class GZipMiddleware [source]

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

Недавно исследователи в области безопасности выявили, что при использовании методов сжатия (включая GZipMiddleware) на веб-сайте сайт становится уязвим для различных атак. Эти методы могут быть использованы для компрометации, среди прочего, защиты CSRF Django. Перед использованием GZipMiddleware на вашем сайте, очень внимательно оцените, подвержены ли вы этим атакам. Если у вас есть любые сомнения в том, что вы подвержены этим атакам, следует избегать использования GZipMiddleware. Более подробную информацию см. в документе BREACH (PDF) и breachattack.com.

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

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

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

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

Вы можете применить сжатие GZip к отдельным представлениям, используя декоратор gzip_page().

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

class ConditionalGetMiddleware [source]

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

Также устанавливаются заголовки ответа Date и Content-Length.

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

class LocaleMiddleware [source]

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

LocaleMiddleware.response_redirect_class

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

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

class MessageMiddleware [source]

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

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

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

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

class SecurityMiddleware [source]

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

  • SECURE_BROWSER_XSS_FILTER
  • SECURE_CONTENT_TYPE_NOSNIFF
  • SECURE_HSTS_INCLUDE_SUBDOMAINS
  • SECURE_HSTS_SECONDS
  • SECURE_REDIRECT_EXEMPT
  • 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), в противном случае ваш сайт может остаться уязвимым по небезопасному соединению с поддоменом.

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

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

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

Примечание

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

X-Content-Type-Options: nosniff

Некоторые браузеры пытаются угадать типы содержимого загружаемых ресурсов, перезаписывая заголовок Content-Type. Хотя это может помочь в отображении сайтов с неправильно настроенными серверами, это также может представлять собой риск для безопасности.

Если ваш сайт предоставляет файлы, загруженные пользователем, злоумышленник может загрузить специально подготовленный файл, который браузер интерпретирует как HTML или JavaScript, в то время как вы ожидаете, что это будет что-то безобидное.

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

Чтобы предотвратить угадывание браузером типа содержимого и принудительно использовать тип, указанный в заголовке 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.

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

Фильтр XSS браузера является полезной мерой защиты, но на него нельзя полагаться исключительно. Он не может обнаружить все атаки XSS, и не все браузеры поддерживают этот заголовок. Убедитесь, что вы всё ещё валидируете и очищаете весь ввод, чтобы предотвратить атаки XSS.

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

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

Средства обработки сайтов

class CurrentSiteMiddleware [source]

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

Средства обработки аутентификации

class AuthenticationMiddleware

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

class RemoteUserMiddleware

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

class PersistentRemoteUserMiddleware

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

class SessionAuthenticationMiddleware

Разрешает аннулирование сеансов пользователя при изменении пароля. Подробнее см. в Аннулирование сеансов при изменении пароля. Эти средства обработки должны следовать за django.contrib.auth.middleware.AuthenticationMiddleware в настройках MIDDLEWARE_CLASSES.

Средства обработки защиты CSRF

class CsrfViewMiddleware [source]

Добавляет защиту от межсайтовых поддельных запросов (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. ConditionalGetMiddleware

    Перед CommonMiddleware: использует свой заголовок Etag, когда USE_ETAGS = True.

  5. SessionMiddleware

    После UpdateCacheMiddleware: Изменяет заголовок Vary.

  6. LocaleMiddleware

    Один из самых верхних, после SessionMiddleware (использует данные сессии) и UpdateCacheMiddleware (изменяет заголовок Vary).

  7. CommonMiddleware

    Перед любыми миддлверами, которые могут изменить ответ (он рассчитывает ETags).

    После GZipMiddleware, чтобы не рассчитывать заголовок ETag для сжатых данных.

    В начале списка: перенаправляет, если APPEND_SLASH или PREPEND_WWW установлены в True.

  8. CsrfViewMiddleware

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

  9. AuthenticationMiddleware

    После SessionMiddleware: использует хранилище сессий.

  10. MessageMiddleware

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

  11. FetchFromCacheMiddleware

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

  12. FlatpageFallbackMiddleware

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

  13. RedirectFallbackMiddleware

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

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

Spec-Zone.ru

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