2

私たちの ASP.NET アプリケーションは IIS 7.5 でホストされており、次のように設定されています。

  • http://siteurlメイン サイトは、 (1)でアクセス可能なルート IIS フォルダーの下でホストされます。
  • http://siteurl/Intranet(2)でホストされている同じ AppPool に別のアプリがあります。

メインアプリ (1) では、フォーム認証 (url: siteurl/loginform) とともに匿名認証が有効になっています。2 番目のアプリ (2) には、統合認証 (NTLM) があります。

ログイン手順は次のように機能します。

  1. ユーザーは最初にサイトの URL に移動します
  2. ユーザーは統合認証を確認するために /Intranet にリダイレクトされます
  3. 統合が承認された場合、ユーザーは適切な認証 Cookie を使用して siteurl にリダイレクトされ、サイトにアクセスできます。
  4. 統合に失敗した場合、ユーザーは siteurl/loginForm にリダイレクトされ、資格情報を手動で入力します

ステップ 4 でフォーム データの送信を拒否する Internet Explorer (8、9、10) には問題があります。そのセッションで NTLM ネゴシエーションが開始されると、認証されていないサイトに IE がコンテンツを POST しないという既知の動作のようです。 . これに対するいくつかの回避策を検討しました。

  1. 資格情報を Cookie (JS を使用) に保存し、POST コンテンツの長さが 0 の場合はサーバーに保存し、Cookie の値を確認してください。後でクッキーを削除します
  2. POST の代わりに GET を使用して資格情報を送信します (ブラウザのアドレス バーに投稿されたばかりのパスワードがユーザーに表示されないようにする必要があるため、醜い)
  3. 新しいタブを開き、別のブラウザ セッションで認証プロセスを続行するためのリンクをユーザーに提供します (これは、IE が 2 番目のタブから POST データを喜んで送信するため、うまくいくようです)。

この問題を回避するために他に必要なオプションはありますか? 上記の 3 つの中で、どれが望ましいでしょうか。

4

1 に答える 1

3

この問題についてここに書きました: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication -challenges-are-expected.aspx

あなたの質問には重要な情報が含まれていないため、トラブルシューティングが困難です。IE は保護スペースを使用して、サイトが HTTP/401 経由で資格情報を要求するかどうかを決定し、とは異なる保護スペースであるため、使用したリテラルURLで説明されている問題は決して発生しません。example.com/example.com/foo/

トラブルシューティングを改善するために、このシナリオの Fiddler ログを共有していただけると非常に役立ちます。

于 2013-08-30T19:53:25.463 に答える