mod: контекстный-процессор теперь передает не только IS_DEBUG, но и ALLOW_TRACKING (куки, что клиент согласился на отлеживание через Google Tag Manager, Яндекс.Метрика и т.п.)

This commit is contained in:
2026-07-28 21:10:04 +03:00
parent 7a9d5c4056
commit f3ed126072
2 changed files with 42 additions and 11 deletions
+41 -10
View File
@@ -1,27 +1,58 @@
from django.conf import settings
from django.http import HttpRequest
# Имя куки, которая ставится клиенту, когда он СОГЛАСИЛСЯ на отслеживание
# (Google Tag Manager, Яндекс.Метрика и т.п.). Если кука присутствует —
# предупреждение о трекинге больше не показываем.
ALLOW_TRACKING_COOKIE_NAME = "allow_tracking"
def is_debug(request: HttpRequest) -> dict:
def site_context(request: HttpRequest) -> dict:
"""
Контекст-процессор Django.
Общий (универсальный) контекст-процессор Django для всего проекта.
ЗАЧЕМ ЭТО НУЖНО:
Автоматически добавляет флаг режима отладки во ВСЕ шаблоны проекта,
без необходимости передавать его вручную в контексте каждой вьюхе.
Контекстный-процессор необходимо зарегистрировать в settings.py:
TEMPLATES['OPTIONS']['context_processors']
Автоматически добавляет во ВСЕ шаблоны проекта переменные, которые
нужны почти на каждой странице, без необходимости передавать их
вручную в контексте каждой вьюхи. Контекст-процессор необходимо
зарегистрировать в settings.py: TEMPLATES['OPTIONS']['context_processors']
ПОЧЕМУ НЕ штатный django.template.context_processors.debug:
ПОЧЕМУ ОДИН УНИВЕРСАЛЬНЫЙ ПРОЦЕССОР, А НЕ НЕСКОЛЬКО РАЗНЫХ:
И DEBUG-флаг, и флаг согласия на трекинг — это одинаковые по сути
"сквозные" данные: маленькие, не завязанные на конкретную вьюху,
нужные почти во всех шаблонах (в _base.html). Заводить под каждую
такую мелочь отдельный контекст-процессор — это лишний файл и лишняя
строка регистрации в settings.py на ровном месте. Если в будущем
появится много разнородных "сквозных" переменных — тогда, возможно,
стоит разнести их по смыслу (например, отдельно cookies-consent,
отдельно debug/env), но пока их всего две — держим вместе.
ПОЧЕМУ НЕ штатный django.template.context_processors.debug (для IS_DEBUG):
Штатный context-processor отдаёт переменную `debug` только если
ОДНОВРЕМЕННО: settings.DEBUG == True И IP клиента входит в
settings.INTERNAL_IPS (сверяется по request.META['REMOTE_ADDR']).
В проекте с Docker/reverse-proxy — REMOTE_ADDR может быть не 127.0.0.1,
а IP шлюза docker-сети, и потому штатный контекстный-процессор ненадёжен.
ПРО ALLOW_TRACKING:
Читаем куку request.COOKIES.get(ALLOW_TRACKING_COOKIE_NAME) — её
ставит клиентский JS (или сервер) ПОСЛЕ того, как пользователь
согласился с предупреждением об отслеживании (Google Tag Manager,
Яндекс.Метрика и т.п.). Если кука присутствует (независимо от её
значения — само наличие куки уже означает согласие) — предупреждение
в шаблоне больше не показываем, а также можно подключать сами
счётчики трекинга ({% if ALLOW_TRACKING %}...{% endif %}).
:return
dict: словарь с единственным ключом IS_DEBUG (bool)
будет доступен во всех шаблонах как переменная контекста:
dict: словарь с ключами:
IS_DEBUG (bool) — режим отладки Django (settings.DEBUG);
ALLOW_TRACKING (bool) — согласился ли клиент на отслеживание
(определяется по наличию куки "allow_tracking").
Обе переменные доступны во всех шаблонах:
{% if IS_DEBUG %}...{% endif %}
{% if ALLOW_TRACKING %}...{% endif %}
"""
return {"IS_DEBUG": settings.DEBUG}
return {
"IS_DEBUG": settings.DEBUG,
"ALLOW_TRACKING": ALLOW_TRACKING_COOKIE_NAME in request.COOKIES,
}
+1 -1
View File
@@ -105,7 +105,7 @@ TEMPLATES = [
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
'frontend.context_processors.is_debug',
'frontend.context_processors.site_context',
],
},
},