2010-10-25 45 views
5

J'ai un bug un peu fou/exaspérant avec un site et CSRF. Nous exécutons Django 1.2.3, Python 2.6 sur Ubuntu avec Apache2 + mod_wsgi et obtenons que les utilisateurs finaux signalent 403 échecs de vérification CRSF et 403 en conséquence.Intermittent 403s en raison d'une défaillance CSRF (Django 1.2.3)

Tous nos formulaires ont un csrf_token et - pour autant que je sache - les choses fonctionnent bien dans les dévs locaux et sur scène (nous ne sommes pas encore en production) ... à part pour un bureau (le client, natch). À des occasions aléatoires, ils obtiendront un tel 403, mais ensuite rafraîchir et ça va disparaître (donc ce n'est pas le HTML qui manque d'un jeton, etc.)

Je réfléchis aux causes et aux solutions, et il se peut que bureau a un cache proxy diabolique ou mal installé, ou similaire, et aimerait avoir quelques conseils sur ce que nous pouvons faire, de manière Django/Apache pour traiter les proxys over-the-top (le bureau du client a probablement gagné ne changez pas leur configuration) ou quoi d'autre pourrait être à l'origine de ces échecs CSRF.

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 le CSRFResponseMiddleware d'inclure automatiquement le csrf_token

En outre: cela s'est produit sur deux serveurs distincts (serveur de développement et serveur de transfert), hébergés dans des emplacements distincts. Les facteurs communs sont (en théorie) la même configuration de Django/Apache/mod_wsgi, la même base de code et le même bureau recevant les 403 (et ne pouvant pas répliquer les 403 dans notre propre emplacement).

Répondre

2

juste une mise à jour dans le cas où cela aide quelqu'un.

Nous avons abandonné la protection CRSF pour tester (en utilisant http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/). Cela a éclairci les 403, mais nous avons ensuite eu 500s intermittent pour les données POST de longueur nulle à partir du même client/réseau local, ce qui explique que les CSRF échouent parce que le jeton était présent dans la session mais pas dans la charge utile inverse). Par conséquent, il ne s'agissait pas d'un problème CSRF, mais d'un problème POST-payload-getting-zapped-something. (Très probablement par un proxy mal configuré à un seul endroit)

HTH

Steve