Spec-Zone.ru › Django 1.10

Среднесвязь

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

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

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

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

Среднесвязь обработки исключений

class ExceptionMiddleware
Новое в Django 1.10.

Перехватывает исключения, возникающие во время цикла запроса/ответа, и возвращает соответствующий ответ.

  • Http404 обрабатывается с помощью handler404 (или более дружественной страницей отладки, если DEBUG=True).
  • PermissionDenied обрабатывается с помощью handler403.
  • MultiPartParserError обрабатывается с помощью handler400.
  • SuspiciousOperation обрабатывается с помощью handler400 (или более дружественной страницей отладки, если DEBUG=True).
  • Любое другое исключение обрабатывается с помощью handler500 (или более дружественной страницей отладки, если DEBUG=True).

Django использует эту среднесвязь независимо от того, включена ли она в MIDDLEWARE, однако вы можете создать подкласс, если ваша собственная среднесвязь должна преобразовывать какие-либо из этих исключений в соответствующие ответы. Например, LocaleMiddleware делает это.

Среднесвязь GZip

class GZipMiddleware [source]

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

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

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

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

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

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

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

Изменено в Django 1.10:

В более ранних версиях механизм защиты CSRF Django был уязвим к атакам BREACH при использовании сжатия. Это больше не так, но вы по-прежнему должны позаботиться о том, чтобы не подвергать свои собственные секреты риску таким образом.

Среднесвязь условного получения

class ConditionalGetMiddleware [source]

Обрабатывает операции условного получения. Если ответ содержит заголовок 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 и сессий. См. документацию по сообщениям.

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

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

Если ваша среда развертывания позволяет, рекомендуется, чтобы ваш веб-сервер front-end выполнял функции, предоставляемые модулем 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 обслуживается непосредственно вашим front-end веб-сервером (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, в front-end балансировщике нагрузки или прокси-сервере обратного проксирования, таком как 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
Новое в Django 1.9.

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

Средство обработки защиты от 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.10/ref/middleware/

Spec-Zone.ru

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