403S intermitentes debido a un fallo CSRF (Django 1.2.3)

Question

Tengo un error poco loco / exasperante con un sitio y CSRF.

Nos estamos quedando Django 1.2.3, Python 2.6 en Ubuntu con Apache 2 + mod_wsgi y ha estado recibiendo los usuarios finales de información 403 fallas en la verificación MERC y 403S como consecuencia de ello.

Todas las formas tienen un csrf_token y - por lo que yo soy consciente - las cosas funcionen bien en dev local y en el escenario (no estamos todavía en la producción) ... además de por una oficina (del cliente, naturalmente) . En ocasiones al azar, van a tener un 403 por ejemplo, pero a continuación, renueve y se le pasará (lo que no es el HTML que carecen de una ficha, etc.)

Estoy sopesando causas y soluciones, y puede ser que esa oficina tiene un caché de proxy puesta a punto diabólicamente demasiado entusiasta o mal, o similares, y agradecería algunos consejos sobre lo que podemos hacer, en un Django / Apache manera de tratar con over-the-top proxies (la oficina del cliente probablemente no va a cambiar su configuración) o qué otra cosa podría ser de hasta causar estos CSRF falla.

Por cierto: este fue un proyecto 1.2.3 desde cero, no algún tipo de actualización 1.1, y usamos sólo el único estándar / correcta 1.2.3 CsrfMiddleware y csrf_tokens añadidos manualmente - no es el CSRFResponseMiddleware para incluir automáticamente el csrf_token

También: esto ha sucedido en dos servidores separados (servidor dev y servidor de ensayo), que están alojadas en lugares separados. Los factores comunes son (en teoría) misma configuración Django / Apache / mod_wsgi, el mismo código base y la misma oficina conseguir los 403S (y no ser capaz de replicar los 403S en nuestra propia ubicación).

Answer 1

sólo una actualización en caso de que ayuda a nadie.

Nos cayó la protección a prueba de MERC (mediante el uso de http : //johnmc.co/llum/disable-csrf-protection-for-django-1-2/ ). Este aclarado los 403S, pero luego tuvimos 500s intermitentes para datos POST de longitud cero de la / red local mismo cliente, que ha explicado que el CSRF no fuera porque el testigo estaba presente en la sesión, pero no en la carga útil (en lugar de la otra manera alrededor).

Por lo tanto, no era una cuestión CSRF, en concreto, sino un problema en algún lugar-zapping conseguir POST-carga útil. (Lo más probable es mediante un proxy mal configurado en un solo lugar)

HTH

Steve