Ошибки CSRF в Django Fargate Docker при использовании HTTPS Application Load Balancer
Я реализовал веб-приложение Django на AWS Fargate, используя Docker за балансировщиками нагрузки приложений.
Когда я пытаюсь войти в веб-приложение, я получаю следующее:
Ошибка 403 CSRF verification failed. Request aborted.
Среда: Я использую Application Load Balancer (ALB) в соответствии с лучшими практиками AWS. У ALB также есть сертификат TLS для правильной обработки HTTPS, когда я запускаю несколько экземпляров веб-приложения.
Я попытался решить эту проблему, принудительно закрепив цели ALB, предполагая, что Round-Robin отправляет запросы на разные серверы. Я также уменьшил количество экземпляров докеров до одного (чтобы не было циклического перебора).
Ничто из этого не имело никакого значения.
Мне удалось войти в систему (чтобы заставить CSRF работать хорошо), когда я подключился напрямую к экземпляру докера (без балансировщика нагрузки) и когда я использовал только HTTP в балансировщике нагрузки приложений - отключил перенаправление на HTTPS. Это наводит меня на мысль, что проблема заключается между HTTPS-частью балансировщика нагрузки и веб-приложением Django.
Отключение HTTPS не готово к производству, поэтому я вернулся к исходной точке. Я видел аналогичный вопрос, опубликованный здесь, без ответов: сообщения django получают ошибку проверки CSRF после переключения на балансировщик нагрузки
Ответы 1
После размещения отладки в работающей системе в качестве временной меры основная проблема стала ясной.
Ошибка проверки реферера - https://test.domain.tld/path/ не соответствует ни одному надежные источники.
Решение — через параметр CSRF_TRUSTED_ORIGINS в Django. Цитата из документации Django:
CSRF_TRUSTED_ORIGINS
Default: [] (Empty list)
A list of hosts which are trusted origins for unsafe requests (e.g. POST).
For a secure unsafe request, Django’s CSRF protection requires that the request have a Referer header that matches the origin present in the Host header.
This prevents, for example, a POST request from subdomain.example.com from succeeding against api.example.com.
If you need cross-origin unsafe requests over HTTPS, continuing the example, add "subdomain.example.com" to this list.
The setting also supports subdomains, so you could add ".example.com", for example, to allow access from all subdomains of example.com.
Аналогичное обсуждение и решение можно найти в этой теме. Проверка CSRF не работает на Django с использованием HTTPS