Intermittent 403s aufgrund CSRF Versagen (Django 1.2.3)

Question

Ich habe ein bisschen verrückt / ärgerliche Fehler mit einer Website und CSRF bekam.

Wir laufen Django 1.2.3, Python 2.6 auf Ubuntu mit Apache2 + mod_wsgi und wurden Endanwendern immer Berichterstattung 403 CRSF Überprüfung Ausfälle und 403s als Folge.

haben alle unsere Formulare ein csrf_token und - soweit mir bekannt - die Dinge funktionieren in lokalen Entwickler und auf der Bühne (wir sind nicht in der Produktion noch) nicht ... außer für ein Büro (des Kunden, natch) . Auf zufälligen Gelegenheiten, werden sie eine solche 403, bekommen aber dann neu geladen und es wird weggehen (so es ist nicht das HTML ein Token usw. fehlt)

Ich grüble Ursachen und Lösungen, und es kann sein, dass dieses Amt hat einen teuflisch übereifrig oder schlecht Setup-Proxy-Cache, oder ähnlich, und würde einige Tipps schätzen, was wir tun können, in einem Django / Apache Art und Weise zu behandeln over-the-Top-Proxies (Büro des Kunden wahrscheinlich nicht ihre Einstellung wieder ändern) oder was sonst könnte bis verursachen diese CSRF ausfällt.

BTW: Das war ein 1.2.3 Projekt von Grund auf neu, nicht irgendeine Art von 1.1 Upgrade, und wir verwenden nur den einzigen Standard / korrigieren 1.2.3 CSRFMiddleware und manuell hinzugefügt csrf_tokens - nicht die CSRFResponseMiddleware automatisch die umfassen csrf_token

Auch: dies hat sich auf zwei separaten Servern (dev-Server und Staging-Server) passiert, die an verschiedenen Orten gehostet werden. Gemeinsame Faktoren sind (in der Theorie) gleicher Django / Apache / mod_wsgi Setup, die gleiche Code-Basis und das gleiche Büro die 403s bekommen (und nicht in der Lage, die 403s in unserem eigenen Standort zu replizieren).

Answer 1

nur ein Update, falls es hilft niemandem.

Wir ließen die CRSF Schutz-Test (unter Verwendung von http : //johnmc.co/llum/disable-csrf-protection-for-django-1-2/ ). Damit war die 403s, aber dann hatten wir intermittierende 500s für Null-Länge POST-Daten von demselben Client / lokales Netzwerk, die erklärten, dass die CSRF versagt waren, weil das Token in der Sitzung anwesend war, aber nicht in der Nutzlast (statt dem umgekehrt).

So war es kein Problem CSRF, speziell, aber ein POST-Nutzlast-getting-gezappt-irgendwo Problem. (Höchstwahrscheinlich durch einen falsch konfigurierten Proxy nur an einem Standort)

HTH

Steve