4

作業中のアプリケーションで Ajax の問題に直面しています。Web アプリは ASP.NET 4.5 で記述されており、具体的には Visual Studio 2012 の既定の MVC サンプル アプリケーションから派生しています。アプリケーションはローカルの IIS サーバー (エクスプレス バージョンではない) でホストされ、Windows 認証 (現在は NTLM) が必要です。セキュリティ上の理由から、クライアントのなりすましのために。

ここで 2 つの質問があります。

  1. ウェブサイトは閲覧時にクライアントを正しく認証していますが、何らかの理由ですべての Ajax 呼び出しが 401 Unauthorized エラーで失敗します (匿名認証を使用している場合は機能しているため、資格情報が要求にカプセル化されていないと思います?!)。彼らの間のコミュニケーションを調査する時間はまだありませんでしたが、ここにいるグルの 1 人が助けてくれると確信しています。

  2. 最終的に、Windows 認証プロバイダーは kerberos に移行されます。この Ajax の問題に関して特に注意すべきことはありますか?

他の情報が必要な場合はお知らせください。

編集 1

私はばかげているように感じます... IISを再起動すると問題が解決します。いつかはITが楽しみ…

皆さんのお陰で。

4

1 に答える 1

6

次の回答は、NTLM/Kerberos に関する私の理解と、ブラウザーが認識している情報を XmlHttpRequest がどのように再利用するかについての推測に基づいています。ただし、実際にシナリオを再現しようとしたわけではないため、間違っている可能性があります。

わかりました、ここに行きます。NTLM セッションは接続指向のプロトコルです。これは、サーバーが「キープアライブ」を返し続け、クライアントが同じ接続を再利用する場合、別の認証ハンドシェイクが必要ないことを意味します。ただし、接続が閉じられて再び開かれると、新しいハンドシェイクが必要になります。これがサーバーを要求するブラウザーである限り、新しいハンドシェークは、ブラウザーのメモリにキャッシュされた資格情報 (最初のハンドシェークで提供した正確な資格情報) を使用して自動的に行われます。

これが、あなたのajax呼び出しが機能しないと私が信じる理由です-おそらく新しい接続を開き、新しいハンドシェイクが必要になるだけです(何らかの理由で、ブラウザのメモリにキャッシュされた資格情報を再利用しないようです)。

ただし、Kerberos に切り替えると、これは変わるはずです。Kerberos は、ブラウザとサーバーが認証機関に直接接続するチャレンジ/レスポンス パターンに基づいています。次に、kerberos は、チケットを使用して http ヘッダーで認証を保持します。ヘッダーが AJAX リクエストに自動的に追加される可能性があります。

NTLM とは対照的に、Kerberos は、ブラウザーとサーバーの両方が認証機関にアクセスできる場合にのみ機能することに注意してください。これが、通常、IIS で「ネゴシエート」が認証スキームとして設定される理由です。これは、最初に Kerberos を試行し、認証機関がブラウザで直接利用できない場合は NTLM に戻ります。

于 2013-01-23T14:52:46.937 に答える