Что такое middleware django
Документация Django 1.7
Промежуточный слой – это механизм “хуков” для обработки запросов и ответов в Django. Это простая низкоуровневая система “плагинов”, которая глобально влияет на ввод и вывод в Django.
Этот раздел описывает как работают промежуточные слои, как активировать их, и как создать собственные. Django предоставляет набор встроенных промежуточных слоев, которые можно использовать в проекте. Они описаны в разделе о встроенных промежуточных слоях.
Подключение промежуточных слоёв¶
“Хуки” и порядок обработки¶
На этапе обработки ответа, после вызова представления, промежуточные слои применяются в обратном порядке, снизу вверх. Доступны три “хука”:
Можете смотреть на это, как на луковицу: каждый промежуточный слой оборачивает представление.
Поведение каждого “хука” описано ниже.
Создание собственного промежуточного слоя¶
Создать свой промежуточный слой очень просто. Это просто класс Python, который предоставляет один или несколько методов:
process_request ¶
process_request() вызывается для каждого запроса перед тем, как Django решит какое представление вызывать.
process_view ¶
process_view() вызывается непосредственно перед вызовом представления.
process_template_response ¶
Нет необходимости явно рендерить объекты ответов – они будут автоматически отрендерены после выполнения всех промежуточных слоёв.
process_response ¶
process_response() вызывается для каждого ответа перед тем, как он будет оптравлен браузеру.
Работа с потоковыми ответами¶
Подразумевается, что streaming_content слишком большой, чтобы храниться в памяти. Промежуточный слой может обернуть его в новый генератор, но не загружать его полностью. Генератор-обертка обычно выглядит следующим образом:
process_exception ¶
__init__ ¶
Большинство классов промежуточного слоя не требуют инициализации т.к. по сути являют набором process_* методов. Если вам необходимо какое-то глобальное состояние, вы можете использовать метод __init__ для его инициализации. Однако помните о некоторых моментах:
Django инициализирует промежуточный слой без аргументов, по этому метод __init__ не должен определять обязательные аргументы.
Помечаем промежуточный слой как неиспользуемый¶
Советы¶
Класс промежуточного слоя не должен наследоваться от другого класса.
Если вы создали полезный промежуточный слой, поделитесь ним с сообществом! Напишите нам, и возможно мы добавим его в Django.
Промежуточное ПО ¶
Написание собственного промежуточного программного обеспечения ¶
Промежуточное ПО можно записать как функцию, которая выглядит так:
Или его можно записать как класс, экземпляры которого вызываются, например:
Промежуточное ПО может поддерживать только синхронный Python (по умолчанию), только асинхронный Python или и то, и другое. См. Раздел « Асинхронная поддержка» для получения подробной информации о том, как рекламировать то, что вы поддерживаете, и о том, какой тип запроса вы получаете.
Промежуточное ПО может находиться где угодно на вашем пути Python.
__init__(get_response) ¶
Фабрики промежуточного программного обеспечения должны принимать get_response аргумент. Вы также можете инициализировать какое-то глобальное состояние для промежуточного программного обеспечения. Имейте в виду пару предостережений:
Пометка промежуточного ПО как неиспользуемого ¶
Активация промежуточного программного обеспечения ¶
Чтобы активировать компонент промежуточного программного обеспечения, добавьте его в MIDDLEWARE список в настройках Django.
В MIDDLEWARE каждый компонент промежуточного программного обеспечения представлен строкой: полный путь Python к классу или имени функции фабрики промежуточного программного обеспечения. Например, вот значение по умолчанию, созданное : django-admin startproject
Порядок и наслоение промежуточного программного обеспечения ¶
Другие перехватчики промежуточного программного обеспечения ¶
Помимо базового шаблона промежуточного программного обеспечения запроса / ответа, описанного ранее, вы можете добавить три других специальных метода в промежуточное программное обеспечение на основе классов:
process_view() ¶
process_view() вызывается непосредственно перед тем, как Django вызывает представление.
process_exception() ¶
request это HttpRequest объект. exception это Exception объект, созданный функцией просмотра.
process_template_response() ¶
process_template_response() вызывается сразу после завершения выполнения представления, если у экземпляра ответа есть render() метод, указывающий, что он является TemplateResponse или эквивалентным.
Работа с потоковыми ответами ¶
streaming_content следует считать, что он слишком велик для хранения в памяти. ПО промежуточного слоя ответа может обернуть его в новый генератор, но не должно его потреблять. Обертывание обычно реализуется следующим образом:
Обработка исключений ¶
Django автоматически преобразует исключения, вызванные представлением или промежуточным программным обеспечением, в соответствующий HTTP-ответ с кодом состояния ошибки. Некоторые исключения преобразуются в коды состояния 4xx, в то время как неизвестное исключение преобразуется в код состояния 500.
Это преобразование происходит до и после каждого промежуточного программного обеспечения (вы можете думать о нем как о тонкой пленке между каждым слоем луковицы), так что каждое промежуточное программное обеспечение всегда может рассчитывать на получение какого-либо ответа HTTP от вызова его get_response вызываемого. Промежуточному программному обеспечению не нужно беспокоиться о переносе своего вызова get_response в объект try/except и обработке исключения, которое могло быть вызвано более поздним промежуточным программным обеспечением или представлением. Даже если следующее промежуточное ПО в цепочке вызывает Http404 исключение, например, ваше промежуточное ПО не увидит этого исключения; вместо этого он получит HttpResponse объект с status_code 404.
Вы можете установить, DEBUG_PROPAGATE_EXCEPTIONS чтобы True пропустить это преобразование и распространять исключения вверх.
Асинхронная поддержка ¶
ПО промежуточного слоя может поддерживать любую комбинацию синхронных и асинхронных запросов. Django адаптирует запросы в соответствии с требованиями промежуточного программного обеспечения, если оно не может поддерживать оба, но со снижением производительности.
По умолчанию Django предполагает, что ваше промежуточное ПО способно обрабатывать только синхронные запросы. Чтобы изменить эти предположения, установите следующие атрибуты в функции или классе фабрики промежуточного программного обеспечения:
Вот пример того, как создать функцию промежуточного программного обеспечения, которая поддерживает оба:
Если вы объявляете гибридное промежуточное ПО, которое поддерживает как синхронные, так и асинхронные вызовы, тип получаемого вами вызова может не соответствовать базовому представлению. Django оптимизирует стек вызовов промежуточного программного обеспечения, чтобы иметь как можно меньше переходов синхронизация / асинхронность.
Таким образом, даже если вы обертываете асинхронное представление, вас могут вызвать в режиме синхронизации, если между вами и представлением есть другое синхронное промежуточное ПО.
Обновление промежуточного программного обеспечения в стиле до Django 1.10 ¶
В большинстве случаев наследования от этого миксина будет достаточно, чтобы сделать промежуточное ПО старого стиля совместимым с новой системой с достаточной обратной совместимостью. Новая семантика короткого замыкания будет безвредной или даже полезной для существующего промежуточного программного обеспечения. В некоторых случаях класс промежуточного программного обеспечения может нуждаться в некоторых изменениях, чтобы приспособиться к новой семантике.
Это поведенческие различия между использованием MIDDLEWARE и MIDDLEWARE_CLASSES :
Документация Django 1.9
Промежуточный слой – это механизм “хуков” для обработки запросов и ответов в Django. Это простая низкоуровневая система “плагинов”, которая глобально влияет на ввод и вывод в Django.
Этот раздел описывает как работают промежуточные слои, как активировать их, и как создать собственные. Django предоставляет набор встроенных промежуточных слоев, которые можно использовать в проекте. Они описаны в разделе о встроенных промежуточных слоях.
Подключение промежуточных слоёв¶
Чтобы подключить промежуточный слой, добавьте его в список MIDDLEWARE_CLASSES в настройках Django.
В параметре конфигурации MIDDLEWARE_CLASSES каждый промежуточный слой представлен строкой: полный путь для импорта класса промежуточного слоя. Например, вот значение настройки по умолчанию для проекта, который создается с помощью django-admin startproject :
“Хуки” и порядок обработки¶
На этапе обработки ответа, после вызова представления, промежуточные слои применяются в обратном порядке, снизу вверх. Доступны три “хука”:
process_exception() (только, если представление вызвало исключение)
Можете смотреть на это, как на луковицу: каждый промежуточный слой оборачивает представление.
Поведение каждого “хука” описано ниже.
Создание собственного промежуточного слоя¶
Создать свой промежуточный слой очень просто. Это просто класс Python, который предоставляет один или несколько методов:
process_request ¶
process_request() вызывается для каждого запроса перед тем, как Django решит какое представление вызывать.
process_view ¶
process_view() вызывается непосредственно перед вызовом представления.
process_template_response ¶
Нет необходимости явно рендерить объекты ответов – они будут автоматически отрендерены после выполнения всех промежуточных слоёв.
process_response ¶
process_response() вызывается для каждого ответа перед тем, как он будет оптравлен браузеру.
Работа с потоковыми ответами¶
Подразумевается, что streaming_content слишком большой, чтобы храниться в памяти. Промежуточный слой может обернуть его в новый генератор, но не загружать его полностью. Генератор-обертка обычно выглядит следующим образом:
process_exception ¶
__init__ ¶
Большинство классов промежуточного слоя не требуют инициализации т.к. по сути являют набором process_* методов. Если вам необходимо какое-то глобальное состояние, вы можете использовать метод __init__ для его инициализации. Однако помните о некоторых моментах:
Django инициализирует промежуточный слой без аргументов, поэтому метод __init__ не должен определять обязательные аргументы.
Помечаем промежуточный слой как неиспользуемый¶
Ранее, исключение, MiddlewareNotUsed не попадало в журнал.
Советы¶
Класс промежуточного слоя не должен наследоваться от другого класса.
Если вы создали полезный промежуточный слой, поделитесь ним с сообществом! Напишите нам, и возможно мы добавим его в Django.
Документация Django 1.9
Этот раздел описывает промежуточные слои, которые предоставляет Django. Как использовать и создавать свои промежуточные слои, смотрите соответствующий раздел.
Доступные промежуточные слои¶
Кэширующий промежуточный слой¶
“Common” промежуточный слой¶
Добавляет несколько полезностей для перфекционистов:
Если APPEND_SLASH равна True и вызванный URL не оканчивается на слеш, и он не найден в URLconf, создается новый URL путем добавления слеша в конец. Если новый URL найден в URLconf, Django отправляет перенаправление на этот URL. Иначе начальный URL обрабатывается как обычно.
Обе эти настройки предназначены для нормализации URL-ов. Философия такая – URL должен быть уникальным и единым. Технически URL foo.com/bar отличается от foo.com/bar/ – поисковик проиндексирует их как отдельные URL-ы – поэтому хорошей практикой является нормализация URL-ов.
Отсылает уведомления о сломанных ссылках на MANAGERS (смотрите Отчёты об ошибках).
GZip промежуточный слой¶
Сжимает ответ для браузеров, которые поддерживают GZip (все современные браузеры).
Этот промежуточный слой должен находится перед любым другим промежуточный слоем, который читает или пишет содержимое ответа, чтобы сжатие происходило в самом конце.
Содержимое ответа НЕ будет сжато при следующих условиях:
Содержимое ответа меньше 200 байтов.
Промежуточный слой для обработки условных GET-запросов¶
Промежуточный слой локализации¶
Выполняет выбор текущего языка на основе данных из запроса. Меняет содержимое для каждого пользователя отдельно. Смотрите раздел об интернационализации.
Промежуточный слой сообщений¶
Добавляет поддержку сообщений на основе кук или сессии. Смотрите раздел о сообщениях.
Промежуточный слой безопасности¶
django.middleware.security.SecurityMiddleware предоставляет ряд проверок безопасности при обработке запроса/ответа. Каждая из них может быть выключена/включена насройкой.
HTTP Strict Transport Security¶
Для сайтов, которые должны быть доступны только по HTTPS, вы можете указать современным браузерам не подключаться к вашему домену по небезопасному подключению (в течении определенного времени), установив заголовок “Strict-Transport-Security”. Это уменьшает подверженность MITM атакам.
SecurityMiddleware будет устанавливать этот заголовок для всех HTTPS ответов, если вы укажите в настройке SECURE_HSTS_SECONDS не нулевое значение.
HSTS применяется ко всему домену, а не только URL, который вернул ответ с заголовком. Поэтому вам следует использовать его только, если весь домен доступен через HTTPS.
Браузеры, которые поддерживают заголовки HSTS, не позволят пользователям игнорировать предупреждение и подключиться к сайту с устаревшим, самостоятельно подписанным, или неправильным SSL сертификатом. Если вы используете HSTS, убедитесь, что с вашими сертификатами все впорядке!
X-Content-Type-Options: nosniff ¶
Если ваш сайт позволяет пользователям загружать файлы, взломщик может загрузить специальный файл, который будет интерпретирован браузером как HTML или Javascript.
Подробности об этом заголовке вы можете найти в IE Security Blog.
Обратите внимание, что в большинстве случаев, когда Django не раздает файлы с сервера, эта опция вам не поможет. Например, если MEDIA_URL раздается напрямую сервером (nginx, Apache, и прочие), тогда вам следует добавить этот заголовок для него. Если же вы используете Django, чтобы, например, проверить авторизацию перед возвращением файла, эта настройка вам пригодится.
X-XSS-Protection: 1; mode=block ¶
Некоторые браузеры умеют блокировать содержимое, которые может использоваться для XSS атаки. Они ищут Javascript в GET или POST параметрах на странице. Если Javascript возвращается сервером, страница блокируется и показывается пердупреждение.
Заголовок X-XSS-Protection позволяет управлять XSS фильтром.
Фильтр XSS полезен, но вы не должны полностью полагаться на него. Браузер определяет не все XSS атаки и не все браузеры поддерживают этот фильтр. Вы все еще должны проверять весь ввод пользователя, чтобы избежать XSS атак.
SSL редирект¶
Если ваш сайт доступен по HTTP и HTTPS, большинство пользователей будут заходить по незащищенному подключению по умолчанию. Вам следует перенапралять их с HTTP на HTTPS.
Для повышения производительности лучше делать эти перенаправления не в Django, а на балансере нагрузки или прокси, таком как nginx. SECURE_SSL_REDIRECT следует использовать для разработки, чтобы не усложнять локальное окружение.
Если на сайте есть страницы, которые должны быть доступны по HTTP без перенаправления на HTTPS, вы можете указать в настройке SECURE_REDIRECT_EXEMPT регулярные выражение, которым удовлетворяют необходимые URL-ы.
Промежуточный слой сессии¶
Включает поддержку сессии. Смотрите раздел о сессии.
Промежуточный слой определения текущего сайта¶
Промежуточный слой авторизации¶
Промежуточный слой для внешней авторизации. Смотрите Аутентификация при помощи REMOTE_USER.
Промежуточный слой для CSRF защиты¶
Включает CSRF защиту, добавляя скрытое поле в POST формы и проверяя значение при запросе. Смотрите раздел о Cross Site Request Forgery защите.
Промежуточный слой X-Frame-Options¶
Порядок промежуточных слоёв¶
Несколько советов о порядке промежуточных слоёв Django:
Должен следовать в начале списка промежуточных слоев, если вы используете SSL перенаправление, чтобы избежать обработки небезопасного запроса другими промежуточными слоями.
Добавлять перед промежуточными слоями, которые могут изменять или читать тело ответа.
Следует одним из первых, после SessionMiddleware (использует сессию) и CacheMiddleware (изменяет заголовок Vary ).
Перед любым промежуточным слоем, который может изменять ответ (вычисляет ETags ).
Перед любым промежуточным слоем, который предполагает, что CSRF защита уже выполнена.
После SessionMiddleware : использует сессию.
После SessionMiddleware : может использовать сессию для хранения данных.
После любого промежуточного слоя, который может изменить заголовок Vary : его значение используется для генерации ключа в кеше.
документация Django 3.0
Доступные промежуточные слои¶
Кэширующий промежуточный слой¶
«Common» промежуточный слой¶
Добавляет несколько полезностей для перфекционистов:
Если APPEND_SLASH равна True и вызванный URL не оканчивается на слеш, и он не найден в URLconf, создается новый URL путем добавления слеша в конец. Если новый URL найден в URLconf, Django отправляет перенаправление на этот URL. Иначе начальный URL обрабатывается как обычно.
Обе эти настройки предназначены для нормализации URL-ов. Философия такая – URL должен быть уникальным и единым. Технически URL foo.com/bar отличается от foo.com/bar/ – поисковик проиндексирует их как отдельные URL-ы – поэтому хорошей практикой является нормализация URL-ов.
Sets the Content-Length header for non-streaming responses.
GZip промежуточный слой¶
The django.middleware.gzip.GZipMiddleware compresses content for browsers that understand GZip compression (all modern browsers).
Этот промежуточный слой должен находится перед любым другим промежуточный слоем, который читает или пишет содержимое ответа, чтобы сжатие происходило в самом конце.
Содержимое ответа НЕ будет сжато при следующих условиях:
If the response has an ETag header, the ETag is made weak to comply with RFC 7232#section-2.1.
Промежуточный слой для обработки условных GET-запросов¶
Промежуточный слой локализации¶
Промежуточный слой сообщений¶
Промежуточный слой безопасности¶
django.middleware.security.SecurityMiddleware предоставляет ряд проверок безопасности при обработке запроса/ответа. Каждая из них может быть выключена/включена насройкой.
HTTP Strict Transport Security¶
For sites that should only be accessed over HTTPS, you can instruct modern browsers to refuse to connect to your domain name via an insecure connection (for a given period of time) by setting the «Strict-Transport-Security» header. This reduces your exposure to some SSL-stripping man-in-the-middle (MITM) attacks.
SecurityMiddleware будет устанавливать этот заголовок для всех HTTPS ответов, если вы укажите в настройке SECURE_HSTS_SECONDS не нулевое значение.
HSTS применяется ко всему домену, а не только URL, который вернул ответ с заголовком. Поэтому вам следует использовать его только, если весь домен доступен через HTTPS.
Браузеры, которые поддерживают заголовки HSTS, не позволят пользователям игнорировать предупреждение и подключиться к сайту с устаревшим, самостоятельно подписанным, или неправильным SSL сертификатом. Если вы используете HSTS, убедитесь, что с вашими сертификатами все впорядке!
Referrer Policy¶
Browsers use the Referer header as a way to send information to a site about how users got there. When a user clicks a link, the browser will send the full URL of the linking page as the referrer. While this can be useful for some purposes – like figuring out who’s linking to your site – it also can cause privacy concerns by informing one site that a user was visiting another site.
Some browsers have the ability to accept hints about whether they should send the HTTP Referer header when a user clicks a link; this hint is provided via the Referrer-Policy header. This header can suggest any of three behaviors to browsers:
There are two types of conditions this header can tell a browser to watch out for:
When your site is served via HTTPS, Django’s CSRF protection system requires the Referer header to be present, so completely disabling the Referer header will interfere with CSRF protection. To gain most of the benefits of disabling Referer headers while also keeping CSRF protection, consider enabling only same-origin referrers.
SecurityMiddleware can set the Referrer-Policy header for you, based on the the SECURE_REFERRER_POLICY setting (note spelling: browsers send a Referer header when a user clicks a link, but the header instructing a browser whether to do so is spelled Referrer-Policy ). The valid values for this setting are:
no-referrer Instructs the browser to send no referrer for links clicked on this site. no-referrer-when-downgrade Instructs the browser to send a full URL as the referrer, but only when no protocol downgrade occurs. origin Instructs the browser to send only the origin, not the full URL, as the referrer. origin-when-cross-origin Instructs the browser to send the full URL as the referrer for same-origin links, and only the origin for cross-origin links. same-origin Instructs the browser to send a full URL, but only for same-origin links. No referrer will be sent for cross-origin links. strict-origin Instructs the browser to send only the origin, not the full URL, and to send no referrer when a protocol downgrade occurs. strict-origin-when-cross-origin Instructs the browser to send the full URL when the link is same-origin and no protocol downgrade occurs; send only the origin when the link is cross-origin and no protocol downgrade occurs; and no referrer when a protocol downgrade occurs. unsafe-url Instructs the browser to always send the full URL as the referrer.
Unknown Policy Values
X-Content-Type-Options: nosniff ¶
Если ваш сайт позволяет пользователям загружать файлы, взломщик может загрузить специальный файл, который будет интерпретирован браузером как HTML или Javascript.
Обратите внимание, что в большинстве случаев, когда Django не раздает файлы с сервера, эта опция вам не поможет. Например, если MEDIA_URL раздается напрямую сервером (nginx, Apache, и прочие), тогда вам следует добавить этот заголовок для него. Если же вы используете Django, чтобы, например, проверить авторизацию перед возвращением файла, эта настройка вам пригодится.
X-XSS-Protection: 1; mode=block ¶
Некоторые браузеры умеют блокировать содержимое, которые может использоваться для XSS атаки. Они ищут Javascript в GET или POST параметрах на странице. Если Javascript возвращается сервером, страница блокируется и показывается пердупреждение.
The X-XSS-Protection header is used to control the operation of the XSS filter.
Фильтр XSS полезен, но вы не должны полностью полагаться на него. Браузер определяет не все XSS атаки и не все браузеры поддерживают этот фильтр. Вы все еще должны проверять весь ввод пользователя, чтобы избежать XSS атак.
SSL редирект¶
Если ваш сайт доступен по HTTP и HTTPS, большинство пользователей будут заходить по незащищенному подключению по умолчанию. Вам следует перенапралять их с HTTP на HTTPS.
Для повышения производительности лучше делать эти перенаправления не в Django, а на балансере нагрузки или прокси, таком как nginx. SECURE_SSL_REDIRECT следует использовать для разработки, чтобы не усложнять локальное окружение.
Если на сайте есть страницы, которые должны быть доступны по HTTP без перенаправления на HTTPS, вы можете указать в настройке SECURE_REDIRECT_EXEMPT регулярные выражение, которым удовлетворяют необходимые URL-ы.
Промежуточный слой сессии¶
Промежуточный слой определения текущего сайта¶
Промежуточный слой авторизации¶
Промежуточный слой для CSRF защиты¶
X-Frame-Options middleware¶
Порядок промежуточных слоёв¶
Несколько советов о порядке промежуточных слоёв Django:
Должен следовать в начале списка промежуточных слоев, если вы используете SSL перенаправление, чтобы избежать обработки небезопасного запроса другими промежуточными слоями.
Добавлять перед промежуточными слоями, которые могут изменять или читать тело ответа.
Before any middleware that may change the response (it sets the ETag header).
Следует одним из первых, после SessionMiddleware (использует сессию) и CacheMiddleware (изменяет заголовок Vary ).
Перед любым промежуточным слоем, который предполагает, что CSRF защита уже выполнена.
После SessionMiddleware : использует сессию.
После SessionMiddleware : может использовать сессию для хранения данных.
После любого промежуточного слоя, который может изменить заголовок Vary : его значение используется для генерации ключа в кеше.