サイトと CSRF に少しクレイジーで腹立たしいバグがあります。
Apache2 + mod_wsgi を使用して Ubuntu で Django 1.2.3、Python 2.6 を実行しており、エンド ユーザーから 403 CRSF 検証の失敗と結果として 403 が報告されています。
私たちのすべてのフォームにはcsrf_tokenand があります - 私が知る限り、ローカル開発とステージ (私たちはまだ本番環境ではありません) で問題なく動作します... 1 つのオフィス (クライアントのナッチ) を除いて。ランダムな機会に、彼らはそのような 403 を取得しますが、その後更新すると消えます (したがって、トークンが欠けている HTML などではありません)。
私は原因と解決策を熟考しています.そのオフィスには、非常に熱心すぎるか、セットアップが不十分なプロキシキャッシュ、または同様のものがある可能性があります.Django / Apacheの方法で、オーバーザトッププロキシ（クライアントのオフィスはセットアップを変更しない可能性が高い）に対処するか、これらのCSRFが失敗する原因となる可能性があるもの.
ところで: これはゼロからの 1.2.3 プロジェクトであり、ある種の 1.1 アップグレードではありません。単一の標準/正しい 1.2.3 CSRFMiddleware と手動で追加された csrf_tokens のみを使用します。csrf_token を自動的に含める CSRFResponseMiddleware ではありません。
また、これは、別々の場所でホストされている 2 つの別々のサーバー (開発サーバーとステージング サーバー) で発生しました。共通の要因は、(理論上) 同じ Django/Apache/mod_wsgi セットアップ、同じコードベース、同じオフィスが 403 を取得している (そして、私たち自身の場所で 403 を複製できない) ことです。