403S intermittents en raison de l'échec de CSRF (Django 1.2.3)

Question

J'ai un bug un peu fou / exaspérant avec un site et CSRF.

Nous courons Django 1.2.3, Python 2.6 sur Ubuntu avec Apache2 + mod_wsgi et ont été obtenir les utilisateurs finaux de rapports 403 échecs de vérification CRSF et 403S en conséquence.

Tous nos formulaires ont csrf_token et - pour autant que je sache - les choses fonctionnent bien dans dev local et sur scène (nous ne sommes pas dans la production encore) ... à part pour un bureau (, de natch du client) . Lors d'occasions au hasard, ils vont obtenir un 403, mais rafraîchir et il va disparaître (il est donc pas le HTML manque un jeton etc)

Je méditais les causes et les solutions, et il se peut que ce bureau a un cache diaboliquement trop impatients ou proxy mal mise en place, ou similaire, et apprécierait quelques conseils sur ce que nous pouvons faire, dans un Django / Apache façon de traiter avec over-the-top mandataires (bureau du client ne modifiera probablement pas leur configuration) ou quoi d'autre pourrait être à l'origine de ces CSRF échoue.

BTW: ce fut un projet 1.2.3 à partir de zéro, pas une sorte de mise à niveau 1.1, et nous utilisons juste la norme unique / correcte 1.2.3 CSRFMiddleware et csrf_tokens ajoutés manuellement - pas CSRFResponseMiddleware d'inclure automatiquement le csrf_token

En outre: il est arrivé sur deux serveurs distincts (serveur de dev et serveur de mise en scène), qui sont hébergés dans des endroits séparés. Les facteurs communs sont (en théorie) même configuration Django / Apache / mod_wsgi, la même base de code et le même bureau obtenir les 403S (et ne pas être en mesure de reproduire les 403S dans notre propre emplacement).

Answer 1

juste une mise à jour au cas où il aide tout le monde.

Nous avons abandonné la protection de CRSF à tester (en utilisant http : //johnmc.co/llum/disable-csrf-protection-for-django-1-2/ ). Cette éclairci les 403S, mais nous avons eu 500s intermittentes pour les données POST zéro longueur du même client / réseau local, ce qui explique que le CSRF échoue était parce que le jeton était présent à la session, mais pas dans la charge utile (plutôt que la inverse).

Alors, il n'a pas été un problème de CSRF, en particulier, mais une question POST-charge utile-getting-zappé, quelque part. (Très probablement par un proxy mal configuré à un seul endroit)

HTH

Steve