CSRFの故障による断続的403s（ジャンゴ1.2.3）

Question

私は、サイトやCSRFと少しクレイジー/腹立たしいバグを持っています。

私たちは、Apache2の+のmod_wsgiをとUbuntuの上でDjangoの1.2.3、Pythonの2.6を実行しているし、結果として403のCRSF検証の失敗と403sを報告するエンドユーザーを取得されています。

私たちのすべてのフォームはcsrf_tokenを持っている - 私は承知しています限り - 物事の仕事の罰金（私たちはまだ生産されていないなら）ローカルdevに、ステージ上の...離れて1つの事務所（クライアント、natch）のための。ランダムな機会に、彼らは、このような403を取得したが、その後、

をリフレッシュし、（それがトークンなどを欠くHTMLではありませんので）それが離れて行きますよよ

私は、原因と解決策を考えていて、それがその事務所がひどくオーバー熱心または不十分セットアッププロキシキャッシュ、または類似していることもあり、とDjangoで、私たちは何ができるかについていくつかのヒントをいただければ幸いです/ （クライアントのオフィスがありそうな自分の設定を変更しません）、または他に何オーバーザトッププロキシに対処するためのApacheの方法は、これらのCSRFが失敗した原因までかもしれません。

ところで：これは最初から1.2.3プロジェクト、1.1アップグレードのではないいくつかの種類があって、私達はちょうど単一の標準/正しい1.2.3 CSRFMiddlewareと手動で追加csrf_tokens使用 - 自動的にcsrf_token も：これは別の場所でホストされている2台の別々のサーバー（DEVサーバーとステージングサーバー）上で起こっています。一般的な要因は、（理論的には）同じジャンゴ/のApache / mod_wsgiを設定している、同じコードベースと同じ事務所403sを取得（そして私たち自身の場所に403sを複製することができない）。

Answer 1

場合だけ、更新、それは誰にも助けます。

私たちは HTTPを使用して（テストにCRSF保護を落としました：//johnmc.co/llum/disable-csrf-protection-for-django-1-2/する）。これは、403sをクリアしたが、その後私たちは、CSRFのではなく（トークンがセッションに存在したためであったが、いないペイロードに失敗したことを説明し、同じクライアント/ローカルネットワークから、長さゼロのPOSTデータの断続的500Sを持っていました他の方法で回避）。

だから、それは具体的には、CSRFの問題ではありませんでしたが、POST-ペイロード-なっ-してやら-どこかの問題。 （ほとんどのひとつの場所で誤って設定代理人による）

HTH

スティーブ