動的コンテンツとログインの問題

ログインフォーム、チェックアウトフロー、認証済みアプリケーションルートなどの動的ページは、キャッシュが強すぎると壊れます。

よくある症状は次のとおりです。

よくある原因は、動的 HTML をキャッシュするように設定した Cache Rule または従来の Page Rule です。

次の条件がすべて当てはまるときに起きがちです。

この設定では、Cloudflare がレスポンスをキャッシュし、エッジに保存する前に Set-Cookie ヘッダーを取り除くことがあります。その結果、ブラウザーはログインページを受け取りますが、次のリクエストに必要なセッション Cookie を受け取れません。

ログインページまたは他の動的ルートのレスポンスを確認します。

次の両方が見える場合、キャッシュすべきでないページがキャッシュされています。

フォーム送信後に、フレームワーク固有の失敗が見えることもあります。例:

この問題は、最初のページ読み込みでセッションまたは CSRF Cookie に依存するフレームワークでよく起きます。対象には JavaServer Faces、ASP.NET、PHP のセッションハンドラー、Django、Rails、Laravel があります。

ログインページやその他の認証済み HTML はキャッシュしないでください。

代わりに次を行います。

Eligible for cache または Cache Everything を静的パスだけに限定します。
/login、/account、/cart、/checkout、アプリケーション API パスなどのルートでキャッシュをバイパスまたは無効にする、より具体的な Cache Rule を追加します。
オリジンがキャッシュを制御する必要がある場合は、ページを強制的にキャッシュする Edge TTL の上書きを削除します。
修正後のレスポンスが CF-Cache-Status: DYNAMIC、MISS、または BYPASS を返し、Set-Cookie が保持されることを確認します。

Cookie の動作について詳しくは、Set-Cookie レスポンスヘッダーと Cache の相互作用を参照してください。

ログインまたはフォームフローでのチャレンジループ

セキュリティチャレンジも、動的フローを中断することがあります。

よくあるパターンは次の 2 つです。

ログインページの最初の GET リクエストでチャレンジが発生する。ユーザーはチャレンジを解決しますが、アプリケーションは元のセッションまたは CSRF コンテキストを失う。
ログインフォームやその他の機密操作を送信する POST リクエストでチャレンジが発生する。チャレンジ後にブラウザーがリクエストを再送する必要があり、元のフォーム送信が壊れることがある。

WAF カスタムルール、マネージドルール、またはレート制限ルールがログインパスに適用されているかを確認します。

/login、/signin、/checkout、/api/auth/* などのルートだけで問題が起き、それらのパスでチャレンジを無効にするとアプリケーションが動く場合、チャレンジがフローを中断しています。

次のいずれかの方法を使います。

デバッグ時は、ルールが /cdn-cgi/* など Cloudflare が生成するパスに一致していないかも確認します。