私たちは Web ショップを開発しており、サードパーティの UI で支払いを処理しています。
支払いソリューション プロバイダーがトップレベル ウィンドウの使用を推奨しているにもかかわらず (現在認識しています)、支払い UI を iframe 内外のチェックアウト ページ内に表示することを選択しました。
IE7/IE8 では、支払い UI は最初のポストバック (iframe 内) でセッション状態を失いますが、Firefox では問題なく動作します。支払い UI は ASP.NET を使用して開発されていることがわかります。
サーバーに関する限り、iframe からの参照とトップレベル ウィンドウからの参照の間に違いはないという印象を受けましたが、明らかに存在します。
誰も手がかりを持っていますか？支払いサーバーに違いをもたらし、セッション状態を失う可能性のある iframe は何をしますか?
それは（突然私に気づきました）Cookieの処理の違いでしょうか？おそらくより厳格なセキュリティ？
おそらくこれが原因です：
Internet Explorer 6 では、Platform for Privacy Preferences (P3P) プロジェクトのサポートが導入されました。P3P 標準では、FRAMESET または親ウィンドウが FRAME 内または子ウィンドウ内の別のサイトを参照する場合、子サイトはサード パーティのコンテンツと見なされることに注意してください。中のデフォルトのプライバシー設定を使用する Internet Explorer は、サード パーティのサイトから送信された Cookie を黙って拒否します。
http://support.microsoft.com/kb/323752/en-us
IFrame は実際には IE の新しいインスタンスであると誰かが言っているのを聞いたことがありますが、どうやらそれはもう少し複雑なようです。
フレーム化されたページが別のセッション ID を取得する理由を説明するには、Milan Negovan によるこの記事が役立つかもしれません。この記事では、上記の Gerrie Schenck が言及した P3P ソリューションについても説明しています。
したがって、コード/サイトの構造は次のようになります。
iframe のコンテンツを右クリックすると、URL がサイト A に対応していることを確認できますか?
デバッグする場合、Page 2 は期待どおりにブレークポイントを起動しますか?