Этот раздел описывает промежуточные слои, которые предоставляет Django. Как использовать и создавать свои промежуточные слои, смотрите соответствующий раздел.
Активирует кэширование для всего сайта. При этом все страницы, которые генерируются Django, будут закэшированы на время, указанное в настройке CACHE_MIDDLEWARE_SECONDS. Смотрите раздел о кэшировании.
Добавляет несколько полезностей для перфекционистов:
Ограничивает доступ для клиентов, которые указанны в настройке 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 при возможности.
По умолчанию HttpResponsePermanentRedirect. Можете создать класс наследник CommonMiddleware и переопределить класс ответа, который используется для перенаправления.
Отсылает уведомления о сломанных ссылках на MANAGERS (смотрите Отчёты об ошибках).
Предупреждение
Исследователи безопасности определили, что при применении сжатия на сайте (включая GZipMiddleware), ваш сайт становится уязвим к некоторым типам атак. Они могут использоваться для обхода CSRF защиты. Перед использованием GZipMiddleware обдумайте на сколько это критично для вас. Если у вас есть малейшие сомнений, не используйте GZipMiddleware. Подробности смотрите в исследовании BREACH (PDF) и breachattack.com.
Сжимает ответ для браузеров, которые поддерживают GZip (все современные браузеры).
Этот промежуточный слой должен находится перед любым другим промежуточный слоем, который читает или пишет содержимое ответа, чтобы сжатие происходило в самом конце.
Содержимое ответа НЕ будет сжато при следующих условиях:
Содержимое ответа меньше 200 байтов.
Ответ уже содержит заголовок Content-Encoding.
Браузер не отослал в запросе заголовок Accept-Encoding, который содержит gzip.
Вы можете добавить GZip сжатие для определенных представлений, используя декоратор gzip_page().
Обрабатывает условные GET операции. Если ответ содержит заголовки ETag или Last-Modified, и запрос содержит If-None-Match или If-Modified-Since, ответ заменяется на HttpResponseNotModified.
Также устанавливает для ответа заголовки Date и Content-Length.
Выполняет выбор текущего языка на основе данных из запроса. Меняет содержимое для каждого пользователя отдельно. Смотрите раздел об интернационализации.
По умолчанию HttpResponseRedirect. Можете создать класс наследник LocaleMiddleware и переопределить класс ответа, который используется для перенаправления.
Добавляет поддержку сообщений на основе кук или сессии. Смотрите раздел о сообщениях.
Предупреждение
Лучший вариант – чтобы фронтенд веб-сервер выполнял действия, которые выполняет SecurityMiddleware. В таком случае все запросы, даже те, которые не обрабатываются Django (запросы к статическим и загруженным файлам), будут защищены как и запросы к приложению Django.
django.middleware.security.SecurityMiddleware предоставляет ряд проверок безопасности при обработке запроса/ответа. Каждая из них может быть выключена/включена насройкой.
Для сайтов, которые должны быть доступны только по HTTPS, вы можете указать современным браузерам не подключаться к вашему домену по небезопасному подключению (в течении определенного времени), установив заголовок “Strict-Transport-Security”. Это уменьшает подверженность MITM атакам.
SecurityMiddleware будет устанавливать этот заголовок для всех HTTPS ответов, если вы укажите в настройке SECURE_HSTS_SECONDS не нулевое значение.
При включении HSTS для начала лучше протестировать с небольшим значение, например, SECURE_HSTS_SECONDS = 3600. Каждый раз, когда браузер видит заголовок HSTS в ответе вашего сайта, он отказывается подключаться по небезопасному подключению (используя HTTP) к вашему домену в течении указанного времени. После проверки, что все статические файлы работают через HTTPS (то есть HSTS ничего не ломает), можно увеличить это значение, чтобы нечастые пользователи были защищены (обычно используют 31536000 секунд, то есть 1 год).
Если вы установите True еще и в SECURE_HSTS_INCLUDE_SUBDOMAINS, SecurityMiddleware``добавит тег ``includeSubDomains к заголовку Strict-Transport-Security. Рекомендуем включить эту настройку (убедитесь, что все поддомены работают по HTTPS), иначе ваш сайт может быть уязвим через небезопасное подключение к поддомену.
Предупреждение
HSTS применяется ко всему домену, а не только URL, который вернул ответ с заголовком. Поэтому вам следует использовать его только, если весь домен доступен через HTTPS.
Браузеры, которые поддерживают заголовки HSTS, не позволят пользователям игнорировать предупреждение и подключиться к сайту с устаревшим, самостоятельно подписанным, или неправильным SSL сертификатом. Если вы используете HSTS, убедитесь, что с вашими сертификатами все впорядке!
Примечание
Если ваш сервер находится за балансировщиком нагрузки, или прокси, и заголовок Strict-Transport-Security не добавляется к ответам, это может быть вызвано тем, что Django не определяет, что используется защищенное подключение. Возможно вам следует указать настройку SECURE_PROXY_SSL_HEADER.
Некоторые браузеры пытаются угадать тип содержимого(content type) полученных файлов, подменяя заголовок Content-Type. В то время, как такой подход помогает правильно отображать сайты с неправильно настроенных серверов, он может быть и уязвимостью.
Если ваш сайт позволяет пользователям загружать файлы, взломщик может загрузить специальный файл, который будет интерпретирован браузером как HTML или Javascript.
Подробности об этом заголовке вы можете найти в IE Security Blog.
Чтобы запретить браузеру угадывать тип файла и заставить всегда использовать значение из заголовка Content-Type, вы можете передать заголовок X-Content-Type-Options: nosniff. SecurityMiddleware добавит его ко всем ответам, если настройка SECURE_CONTENT_TYPE_NOSNIFF равна True.
Обратите внимание, что в большинстве случаев, когда Django не раздает файлы с сервера, эта опция вам не поможет. Например, если MEDIA_URL раздается напрямую сервером (nginx, Apache, и прочие), тогда вам следует добавить этот заголовок для него. Если же вы используете Django, чтобы, например, проверить авторизацию перед возвращением файла, эта настройка вам пригодится.
Некоторые браузеры умеют блокировать содержимое, которые может использоваться для 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 атак.
Если ваш сайт доступен по HTTP и HTTPS, большинство пользователей будут заходить по незащищенному подключению по умолчанию. Вам следует перенапралять их с HTTP на HTTPS.
Если установить True в SECURE_SSL_REDIRECT, SecurityMiddleware будет перманентно (HTTP 301) перенаправлять все HTTP запросы на HTTPS.
Примечание
Для повышения производительности лучше делать эти перенаправления не в Django, а на балансере нагрузки или прокси, таком как nginx. SECURE_SSL_REDIRECT следует использовать для разработки, чтобы не усложнять локальное окружение.
Если указать значение в настройке SECURE_SSL_HOST, все перенаправления будут выполняться на указанный хост, а не хост из запроса.
Если на сайте есть страницы, которые должны быть доступны по HTTP без перенаправления на HTTPS, вы можете указать в настройке SECURE_REDIRECT_EXEMPT регулярные выражение, которым удовлетворяют необходимые URL-ы.
Примечание
Если ваш сервер находится за балансировщиком нагрузки или прокси, Django может не определяет, что используется защищенное подключение. Возможно вам следует указать настройку SECURE_PROXY_SSL_HEADER.
Включает поддержку сессии. Смотрите раздел о сессии.
Добавляет атрибут site, который указывает текущий сайт для каждого объекта HttpRequest. Смотрите раздел о поддержке нескольких сайтов.
Добавляет атрибут user, который указывает текущего авторизованного пользователя, для каждого объекта HttpRequest. Смотрите раздел об авторизации.
Промежуточный слой для внешней авторизации. Смотрите Аутентификация при помощи REMOTE_USER.
Промежуточный слой для внешней авторизации, которая используется только для страниц входа для оптимизации работы приложения. Смотрите Использование REMOTE_USER только на странице авторизации.
Позволяет удалить сессию пользователя при смене пароля. Смотрите Сброс сессии при изменении пароля. Добавлять после django.contrib.auth.middleware.AuthenticationMiddleware в MIDDLEWARE_CLASSES.
Включает CSRF защиту, добавляя скрытое поле в POST формы и проверяя значение при запросе. Смотрите раздел о Cross Site Request Forgery защите.
Добавляет простую защиту от “clickjacking”, используя заголовок X-Frame-Options.
Несколько советов о порядке промежуточных слоёв Django:
Должен следовать в начале списка промежуточных слоев, если вы используете SSL перенаправление, чтобы избежать обработки небезопасного запроса другими промежуточными слоями.
Добавлять перед промежуточными слоями, которые могут изменить заголовок Vary (SessionMiddleware, GZipMiddleware, LocaleMiddleware).
Добавлять перед промежуточными слоями, которые могут изменять или читать тело ответа.
После UpdateCacheMiddleware: изменяет заголовок Vary.
Перед CommonMiddleware: использует установленный заголовок Etag при USE_ETAGS = True.
После UpdateCacheMiddleware: изменяет заголовок Vary.
Следует одним из первых, после SessionMiddleware (использует сессию) и CacheMiddleware (изменяет заголовок Vary).
Перед любым промежуточным слоем, который может изменять ответ (вычисляет ETags).
После GZipMiddleware, чтобы заголовок ETag не вычислялся для сжатого ответа.
Ближе к верху: выполняет перенаправление при APPEND_SLASH или PREPEND_WWW равном True.
Перед любым промежуточным слоем, который предполагает, что CSRF защита уже выполнена.
После SessionMiddleware: использует сессию.
После SessionMiddleware: может использовать сессию для хранения данных.
После любого промежуточного слоя, который может изменить заголовок Vary: его значение используется для генерации ключа в кеше.
Должен быть в низу.
Должен быть в низу.
Mar 31, 2016