Периодические ошибки 403 из-за сбоя CSRF (Django 1.2.3)

Question

У меня немного сумасшедшая/раздражающая ошибка с сайтом и CSRF.

Мы используем Django 1.2.3, Python 2.6 в Ubuntu с Apache2 + mod_wsgi, и конечные пользователи сообщают о 403 ошибках проверки CRSF и, как следствие, о 403 ошибках.

Все наши формы имеют csrf_token и, насколько мне известно, в локальной разработке и на сцене все работает нормально (мы еще не в производстве)...кроме одного офиса (клиентского, естественно).В случайных случаях они получат такую ​​ошибку 403, но затем обновятся, и она исчезнет (так что это не HTML-код, в котором отсутствует токен и т. д.)

Я обдумываю причины и решения, и, возможно, в этом офисе слишком перегруженный или плохо настроенный прокси-кеш или что-то подобное, и я был бы признателен за некоторые советы о том, что мы можем сделать, используя Django/Apache. иметь дело с прокси-серверами over-the-top (офис клиента, скорее всего, не изменит их настройку) или что еще может быть причиной сбоя этих CSRF.

КСТАТИ:это был проект 1.2.3 с нуля, а не какое-то обновление 1.1, и мы используем только одно стандартное/правильное CSRFMiddleware 1.2.3 и добавляемые вручную csrf_tokens, а не CSRFResponseMiddleware для автоматического включения csrf_token

Также:это произошло на двух отдельных серверах (сервере разработки и промежуточном сервере), которые размещены в разных местах.Общими факторами являются (теоретически) одна и та же установка Django/Apache/mod_wsgi, одна и та же кодовая база и один и тот же офис, получающий 403-е (и неспособность воспроизвести 403-е в нашем собственном регионе).

Answer 1

просто обновление, если оно кому-нибудь поможет.

Мы отказались от защиты CRSF для тестирования (с помощью http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/).Это прояснило ошибки 403, но затем у нас появились периодические ошибки 500 для данных POST нулевой длины из одной и той же клиентской/локальной сети, что объясняло, что сбой CSRF произошел потому, что токен присутствовал в сеансе, но не присутствовал в полезной нагрузке (а не в наоборот).

Таким образом, это была не проблема CSRF, а проблема POST-попадания полезной нагрузки куда-то.(Скорее всего, из-за неправильно настроенного прокси-сервера только в одном месте)

ХТХ

Стив