403s intermitentes devido à falha do CSRF (Django 1.2.3)

Question

Eu tenho um bug um pouco louco/irritante com um site e CSRF.

Estamos executando o Django 1.2.3, Python 2.6 no Ubuntu com Apache2 + mod_wsgi e estamos recebendo usuários finais relatando falhas de verificação de 403 CRSF e 403s como resultado.

Todas as nossas formas têm um csrf_token E - até onde eu conheço - as coisas funcionam bem no Dev local e no palco (ainda não estamos em produção) ... além de um escritório (o cliente, Natch). Em ocasiões aleatórias, eles receberão um 403, mas depois atualizam e vai desaparecer (então não é o html sem um token etc.

Estou pensando em causas e soluções, e pode ser que esse escritório tenha um cache de proxy de alta ou com mais de um cache de proxy, ou similar, e apreciaria algumas dicas sobre o que podemos fazer, de uma maneira Django/Apache para Lidar com proxies exagerados (o escritório do cliente provavelmente não mudará sua configuração) ou o que mais pode estar pronto para causar falhas no CSRF.

BTW: Este foi um projeto 1.2.3 do zero, não algum tipo de atualização 1.1, e usamos apenas o único padrão/correto 1.2.3 CSRFMiddleware e adicionamos manualmente CSRF_TOKENS - não o CSRFRESPONSIDDLEWARE para incluir automaticamente o CSRF_TOKN

Além disso: isso aconteceu em dois servidores separados (servidor de dev e servidor de estadiamento), que estão hospedados em locais separados. Os fatores comuns são (em teoria) a mesma configuração Django/Apache/Mod_WSGI, a mesma base de código e o mesmo escritório obtendo os 403s (e não sendo capaz de replicar os 403s em nosso próprio local).

Answer 1

Apenas uma atualização, caso ajude qualquer pessoa.

Abaixamos a proteção do CRSF para testar (usando http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/). Isso limpou os 403s, mas tivemos 500s intermitentes para dados de pós-comprimento de zero da mesma rede cliente/local, o que explicou que o CSRF falhou porque o token estava presente na sessão, mas não na carga útil (em vez do outra maneira de contornar).

Portanto, não foi um problema de CSRF, especificamente, mas um problema pós-payload-getting-Zapped-Somewhere. (Provavelmente por um proxy equivocado em apenas um local)

Hth

Steve