Среднесвязь
В этом документе описываются все компоненты среднесвязи, которые поставляются с 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
Перехватывает исключения, возникающие во время цикла запроса/ответа, и возвращает соответствующий ответ.
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().
В более ранних версиях механизм защиты 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_FILTERSECURE_CONTENT_TYPE_NOSNIFFSECURE_HSTS_INCLUDE_SUBDOMAINSSECURE_HSTS_SECONDSSECURE_REDIRECT_EXEMPTSECURE_SSL_HOSTSECURE_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
Средство обработки для использования аутентификации, предоставляемой веб-сервером, только на странице входа. Подробности использования см. в разделе Использование REMOTE_USER только на страницах входа.
Средство обработки защиты от CSRF
-
class CsrfViewMiddleware[source]
Добавляет защиту от межсайтовых поддельных запросов (CSRF), добавляя скрытые поля формы POST и проверяя запросы на правильное значение. См. документацию по защите от межсайтовых поддельных запросов.
X-Frame-Options средство обработки
-
class XFrameOptionsMiddleware[source]
Простая защита от clickjacking с помощью заголовка X-Frame-Options.
Порядок обработки
Ниже приведены некоторые рекомендации по порядку расположения различных классов обработки Django:
-
Его следует поместить в начало списка, если вы собираетесь включить перенаправление SSL, так как это предотвращает прохождение через множество других ненужных средств обработки.
-
Перед теми, которые изменяют заголовок
Vary(SessionMiddleware,GZipMiddleware,LocaleMiddleware). -
Перед любым средством обработки, которое может изменить или использовать тело ответа.
После
UpdateCacheMiddleware: Изменяет заголовокVary. -
Перед
CommonMiddleware: использует свой заголовокETag, когдаUSE_ETAGS=True. -
После
UpdateCacheMiddleware: Изменяет заголовокVary. -
Один из самых верхних, после
SessionMiddleware(использует данные сессии) иUpdateCacheMiddleware(изменяет заголовокVary). -
Перед любым средством обработки, которое может изменить ответ (вычисляет
ETags).После
GZipMiddleware, чтобы не вычислять заголовокETagдля сжатых данных.Вблизи верха: перенаправляет, когда
APPEND_SLASHилиPREPEND_WWWустановлены вTrue. -
Перед любым средством обработки представлений, которое предполагает, что атаки CSRF обрабатываются.
-
После
SessionMiddleware: использует хранилище сессий. -
После
SessionMiddleware: может использовать хранилище на основе сессии. -
После любого средства обработки, которое изменяет заголовок
Vary: этот заголовок используется для выбора значения для ключа хеша кэша. -
Должен быть в конце, так как это средство обработки последнего средства.
-
Должен быть в конце, так как это средство обработки последнего средства.
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.10/ref/middleware/