Проблема с маркерами CSRF в Django 1.6
В нашем последнем выпуске у нас возникли проблемы с дублированными файлами cookie CSRF-токенов в Django. Мы только что обновились с Django 1.4 до 1.6, и у нас никогда не было проблем с версией 1.4. В принципе, все запускается нормально для каждого пользователя, но в какой-то момент у него появляется более одного файла cookie CSRF-токена, и браузер запутывается и не знает, какой из них использовать. Обычно он выбирает неправильно и вызывает проблемы с CSRF. Наш сайт использует несколько поддоменов, поэтому обычно есть файлы cookie для.site.com, .sub.site.com, site.com и других вариантов.
Мы попытались установить "CSRF_COOKIE_DOMAIN" на.site.com, и это, похоже, приводило к тому, что проблема возникала реже, но иногда это происходило, когда использовались субдомены, а пользователи выходили из системы и снова входили в нее как другие пользователи.
Мы также обнаружили, что ярлык favicon не был определен в нашем базовом шаблоне, из-за чего дополнительный запрос проходил через промежуточное ПО, но это было исправлено. Затем мы подтвердили, что только промежуточный запрос проходил через промежуточное программное обеспечение, а не статические или мультимедийные файлы.
Мы по-прежнему не можем воспроизвести проблему по команде, и, как правило, всякий раз, когда это происходит, очистка cookie-файлов работает как временное исправление, но периодически оно продолжается. Кто-нибудь знает, почему это может происходить? Есть ли что-то, чего нам не хватает в документах?
Благодарю.
РЕДАКТИРОВАТЬ:
Я забыл упомянуть, что у нас есть несколько серверных сред (site.com, demo.site.com и beta.site.com). После еще нескольких копаний, похоже, что пользователи, которые тестировали бета-версию, а затем использовали продукт, столкнулись с конфликтами между файлами cookie. Только что мы попытались установить домены cookie csrf для каждой среды как ".beta.site.com" и ".demo.site.com" вместо просто ".site.com", и это, похоже, помогло, особенно когда вы очищаете свой куки между работой в каждой среде. Тем не менее, существует вероятность возникновения коллизий между cookie-файлами.site.com при столкновении бета-версии и демо-версии, но это, по крайней мере, не проблема.
Так что мы можем еще с этим сделать? Кроме того, можно ли что-то сделать, когда мы отправим это в производство, когда у пользователей будут старые файлы cookie "site.com", которые сталкиваются с новыми указанными файлами cookie ".site.com"?
РЕДАКТИРОВАТЬ 2:
Я опубликовал решение, но оно не позволит мне принять его в течение нескольких дней.
1 ответ
Я думаю, что мы наконец поняли это. Отдельные "CSRF_COOKIE_DOMAIN" для каждой среды (".beta.site.com", ".demo.site.com" и т. Д.) Позволили устранить проблемы между средами. Мы также настроили настройку "CSRF_COOKIE_NAME" на "csrf_token" вместо "csrftoken" по умолчанию, чтобы пользователи со старыми файлами cookie csrftoken не пострадали.