Данная глава временно взята из первой версии книги и подлежит корректировке. Вы можете помочь с этим!
Перевод © Попов Руслан <radz • yandex • ru>
Иногда появляется необходимость выполнения некоторого кода на каждый запрос, обрабатываемый Django. Этот код может изменять запрос перед его передачей в функцию представления, может организовывать журналирование информации о запросе в целях отладки и так далее.
Вы можете делать такие вещи с помощью среды Django для работы с компонентами. Это лёгкая, низкоуровневая плагинная система, которая имеет возможность глобально влиять на ввод и вывод Django.
Каждый компонент этой системы отвечает за выполнение определённой задачи. Если вы читаете эту книгу с самого начала, вы уже встречались с такими компонентами:
Все инструменты для работы с сессиями и пользователями, описанные в главе «Сессии, пользователи и регистрация», появились благодаря этой системе. Точнее, компоненты были подключены к вашей функции представления с помощью модулей request.session и request.user.
Кэш для сайта, описанный в главе «Кэширование», на самом деле является таким компонентом, который пропускает через себя вызов вашей функции представления в случае, когда это представление уже было помещено в кэш.
Сторонние приложения, такие как flatpages, redirects и csrf, описанные в главе «Средства от других разработчиков», делают всю свою волшебную работу через систему компонентов.
Эта глава подробно рассматривает что такое компоненты, как они работают и объясняет как вы можете самостоятельно создавать такие компоненты.
Компонент является обычным классом языка Python, который соответствует определённому API. Перед изучением формальных аспектов API, давайте рассмотрим очень простой пример.
Сайты с высокой нагрузкой часто нуждаются в установке Django за балансировщиком нагрузки (обратитесь к главе «Развёртывание Django»). Это может вызвать некоторые трудности, одной из которых является то, что каждый IP адрес от которого идёт запрос (request.META['REMOTE_IP']) будет теперь указывать на балансировщик, а не актуальный IP адрес. Балансировщики нагрузки решают эту проблему установкой специального заголовка, X-Forwarded-For, назначая ему IP адрес машины, которая сделала запрос.
Ниже приведён код небольшого компонента, который позволяет сайтам, работающим за балансировщиком, получать правильный IP адрес из request.META['REMOTE_IP']:
class SetRemoteAddrFromForwardedFor(object):
def process_request(self, request):
try:
real_ip = request.META['HTTP_X_FORWARDED_FOR']
except KeyError:
pass
else:
# HTTP_X_FORWARDED_FOR может быть списком IP адресов,
# разделённых запятой. Берём только первый.
real_ip = real_ip.split(",")[0]
request.META['REMOTE_ADDR'] = real_ip
Если этот компонент установлен (обратитесь к следующей секции), значение X-Forwarded-For каждого запроса будет автоматически помещено в request.META['REMOTE_ADDR']. Это означает, что вашему приложению больше не требуется определять работает ли оно за балансировщиком или нет. Оно может просто использовать request.META['REMOTE_ADDR'] и всё будет работать как надо.
Действительно, этот функционал нужен многим и должен быть встроен в Django. Так и есть, он находится в django.middleware.http, и вы можете узнать о нём больше в следующем разделе.
0 комментариев | Оставьте комментарий