Forms Authを使用するASP.NETアプリケーションがあります。ユーザーがログインすると、セッションID Cookieとフォーム認証チケット(Cookieとして保存)が生成されます。これらはセッションCookieであり、永続的なCookieではありません。ブラウザを閉じたときに、ユーザーが効果的にログアウトされることが意図的であり、望ましいことです。
ユーザーがログインすると、window.open('location here');
を使用して新しいウィンドウがポップアップ表示されます。開かれるページは、事実上、ユーザーが残りのセッションを通して作業するワークスペースです。このページから、他のポップアップも使用されます。
最近、多くのお客様が(すべてIE8の最新バージョンを使用して)お客様がログインすると、最初のポップアップでホームページではなくログイン画面に戻るという苦情がありました。代わりに、ユーザーは時々ログインしてホームページに戻ることができ(これも新しいポップアップウィンドウにあります)、追加のポップアップが作成されてログイン画面にリダイレクトされるまで、すべて正常に見えます再び。
この問題のトラブルシューティングを試みる際に、古き良きFiddlerを使用しました。問題が顕在化し始めると、ブラウザはASP.NETセッションIDセッションCookie OR Forms AuthチケットセッションCookieを、ログインへの応答にもかかわらず送信していないことに気付きました。 POSTはこれらのCookieを明確にプッシュダウンします。
さらに奇妙なのは、Ctrlキーを押しながらNキーを押して、セッションCookieのないポップアップウィンドウから新しいウィンドウを開き、手動でURLをホームページに入力すると、それらのCookieが魔法のように再び表示されることです。ただし、その後のwindow.open();
呼び出しは引き続き中断され、セッションCookieを送信してユーザーをログイン画面に移動させることはありません。
正当な理由がないように思われる場合がありますが、同じユーザーが突然ログインしてしばらくの間正常に動作し、その後壊れた状態に戻る場合があることに注意することが重要です。
今、ブラウザのアドオン、プラグイン、ツールバーなどが実行されていないことを確認しました。サイトを信頼済みサイトとして追加し、セキュリティ設定を「低」に落としました。Cookieプライバシーポリシーを「すべて受け入れる」に変更し、自動ポリシー設定を無効にし、すべてを受け入れてセッションCookieを含めるように手動で強制しました。それに影響を与えるものは何もありません。
また、Webアプリケーションは単一のサーバー上にあることに注意してください。負荷分散、Webガーデン、サーバーファーム、クラスターなどはありません。サーバーはISAサーバーの背後にありますが、それ以外は非常に単純です。
私は何日も探していましたが、実用的なものは見つかりませんでした。ちなみに、時にはそれを確実に再現することさえできない。私はこの同じ問題を抱えている人々への参照をいくつか見つけましたが、彼らはベータまたはRCリリースで修正されたと言われている問題を参照しているようです(例: IE8はリダイレクト後に新しいウィンドウを開くとCookieを失います )。これらは、最新のパッチが適用されたIEのリリースバージョンです。
セッションCookieの代わりにパーマネントCookieを設定できることを認識しています。ただし、これはアプリケーションのセキュリティに大きく影響します。
ユーザーがマシンのローカル管理者として追加されると、問題は自動的に解消されるようです。この変更がこの問題に恒久的(かつ積極的に)影響を与えるかどうかは、時間だけがわかります。
ProcMonを無効にし、リソースアクセスの問題があるかどうかを確認します。
特異な問題と思われるものには、複数の角度があるようです。私はずっと前に、ユーザーをローカル管理者にすることが助けになったようだと報告しました。そして、それは多くのユーザーに対して行われました。もちろん、それは実際には解決策ではありませんが、やり遂げることができました。
その後、より多くのユーザーが問題の報告を開始しましたが、管理者による修正は役に立ちませんでした。ユーザーは主にWin7のようでしたが、Vistaも影響を受けました。また、ほとんどが64ビットインストールであるように見えました。
以下の一部のメンバーによって提案されているように、TabProcGrowthを0または1(どちらも機能する)に設定すると、この問題はほぼ解決されたようです。それで、私が受け入れた答えを、それを示唆した最初の人に移動します。
これは、再現するのが難しく、直接通信していないユーザーと頻繁に発生するため、またはそれらに到達するまでに機能していないように見えるため、解決しようとすると非常にイライラする問題でした。私が言えるのは、セッションマージ機能に問題があるということだけですが、永続的な修正を見つけるためにMicrosoftに提供するデータはあまりありません。
これはIE8の「新しい」機能です!
以下のIE8ブログをご覧ください。
IE8は、x個のIEウィンドウを処理するために複数のプロセスを使用できます。プロセス空間を横断すると、Cookieが失われます(Asp.NetセッションIDは、このプロセス境界を越えて保持されているようです)。
私は個人的には壊れているかバグだと思っています。ご存知のように、「同じドメインターゲット」Cookieを参照する場合は、Cookieを保持して再送信する必要があります。 IE8には、セキュリティのための異なる処理動作があります。動作がおかしく、「別のウィンドウで同じターゲットドメインに移動してもCookieをドロップする」というのは、私の見解では単なるバグです。
IE8が使用するプロセスの数は、Internet Explorerのオプションehh。を使用して変更できます。レジストリ設定の変更!!!!!! (これが私のビューのバグです。IEこれらの設定を変更するためのUIを提供すると、「エンタープライズレベルで受け入れ可能」になります。
よろしく、
マーヴィン・スミット
これには複数の可能性があります-
「タブプロセスの成長を設定」を0に変更することで、この問題を解決しました。
ただし、保護モードをオンにしておらず、ゾーンは「イントラネット」でした。明らかに、これは他の人が述べているように、Windows 7 64Bitの問題/バグです。
このページ(#4)から解決策に導かれます: http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/ =
私が知る限り、タブ間のCookieに対する別の変更は、2013年11月12日から このセキュリティ更新プログラム で公開され、IEのすべてのバージョンのアプリの機能が壊れています。ユーザーが最初にログインリンクをクリックしたときに参照していたページからユーザーをリダイレクトする必要がないように、ポップアップウィンドウでOpenID認証を行っています。ログイン用のセッションCookieは、ポップアップウィンドウのリクエストで正しく送信されますが、メインのブラウザーウィンドウには表示されないため、サーバーへの次のリクエストには、そのようなセッションCookieはありません。したがって、ログインは実際には機能しません。
誰にもこれに対する解決策はありますか?
IE6、7、8でこの問題が発生しました。シナリオは、親ウィンドウ(1)がモーダルウィンドウ(2)を開き、モーダルウィンドウが非モーダルウィンドウ(3)へのリンクを持っていることです。 3番目のウィンドウで別のセッションIDを取得していました。
ここで言及した回避策は問題を修正しました http://support.Microsoft.com/kb/831678
IE 5であるため、モーダルポップアップウィンドウでのみセッションの変数を使用します...非モーダルポップアップウィンドウを開くと、すべてのセッションの変数をASP.NETキャッシュと新しいオブジェクトコレクション...しかし、それは非常に面倒です!
他のブラウザ(Firefoxなど)にはこの問題はありません...
これは実際にはIEのバグだと思います。フィードバックを確認するためにここに報告しました: http://social.msdn.Microsoft.com/Forums/en-US/83bb3b91-1c1f-4d51-9281-9bc5f51d3640/log-in-fails- cookie-is-not-sent-to-originating-tab?forum = iewebdevelopment
この問題の実行可能な修正も見つけました。 IE8が/ testなどの相対パスを持つ別のウィンドウでサーブレットを開く方法に問題があるようです。新しいウィンドウと同様に新しいセッションを開いているようです。実行可能な修正は、相対パスで新しいウィンドウを開く代わりに、jspページを使用したことです。したがって、URLに移動するとき、/ testには移動しません。特定のファイルに移動します。 jspファイルでは、リクエストを相対パスに転送します。唯一の違いは特定のファイルを間に配置することであるため、これはうまくいくように見えますが、ちょっと厄介です。
これがお役に立てば幸いです。
IE8以降、私たち(およびお客様)も同じ問題を経験しています。フォームを作成するためのASPサービスがあります。このアプリケーションは、要素の追加またはユーザーアカウントの管理に新しいウィンドウを使用します。ランダムに(新しいウィンドウを開くとき)、アプリケーションは他の「永続的な」Cookieとの認証に必要なセッションIDを取得しません。したがって、セッションIDは一時的なCookieです。ほとんどの場合はうまくいきますが、新しいウィンドウを開くたびにセッションが中断することもあります。すべてのIEウィンドウを閉じて、最初からやり直すことをお客様にアドバイスする必要があります。
私はWeb開発者としてIEを広く使用しています。個人的には、上記の問題は発生していません。しかし、関連する問題だと思います。1日に数回IE新しいウィンドウを開くと、完全にハングします(応答しなくなります。タスクマネージャを使用して特定のIEプロセスを強制終了すると、IEが再び応答を開始します。ほとんどの場合、IEのクリーンな新しいインスタンスで最初からやり直すことをお勧めします。このため、すべてのIEプロセスを終了させるRAMの使用量が最も少ないプロセスを強制終了します。
マイクロソフトは、これらの問題/バグは最終バージョンでつぶされていると言って、まだ経験されている問題を解決する彼らの努力の信頼を私に与えません。
セッション変数を使用して値をポップアップウィンドウに渡すことで、同様の問題が発生していました。永続的なCookieに値を書き込み、ポップアップウィンドウでCookieを読み取ることになりました。これは、フォーム認証で発生していた問題では機能しない可能性がありますが、セッション変数を使用してIE8のウィンドウに値を渡すだけの場合、永続的なCookieが機能しているようです。
編集:参照 このスレッド
LocalStoprageメソッドを使用して、親ウィンドウの値をリセットすることもできます。 localStorage( "Key")= "Value"; // Javascript
同じような問題はありませんが、似ています。 window.open()
でポップアップを開くWebページをIEブラウザーコントロールにロードします。IE6とIE8のいずれかを搭載したマシンでは、ポップアップウィンドウには常に新しいSessionIDが割り当てられます。 ASPコントロールから起動した場合。ただし、通常のブラウザ(IEまたはFirefox)から起動した場合、ポップアップウィンドウは既存のSessionIDを取得します。
コントロールから起動すると、新しい_iexplore.exe
_プロセスが生成されることがわかります。したがって、セッション損失の動作は、インプロセスCookieが新しいプロセスに引き継がれないことについて言及されていることを考えると理にかなっています。
私はまだ自分自身の回避策を見つけようとしています...
更新
実行可能な修正を見つけました! SessionIDManager
をサブクラス化して、デフォルト(_<sessionState sessionIDManagerType="...">
_ inWeb.config)の代わりにこのクラスを使用するように指定することができます。サブクラスは、CreateSessionID()
のオーバーライドで既存のセッションIDを含むクエリパラメーターを検索し、見つかった場合はそれを返します。これにより、基本的に、ページは、知識のある既存のセッションに「マージ」されることを要求できます。
window.open()
の呼び出しには、そのURLで指定されたクエリパラメータが必要です。
ホービン
PHP5とIE8でも同様の問題がありました。 window.openを使用してJavascriptで特定のポップアップウィンドウを開くと、IE8はセッションCookieを失い、ユーザーにログインを強制しました。
一方、他のポップアップウィンドウは正常に機能しました。
犯人は画像タグであることが判明しました。テンプレートシステムは、画像src =値を動的に生成し、画像が欠落すると、空のsrc句(
これは、IE空のsrc-tagを安全でないURLとして解釈し、ユーザーに通知せずにポップアップでセッションを分離することと関係があると思います。