與

Question

我們的ASP.NET應用程序在IIS 7.5主辦，具有下列設置在IE窗體身份驗證（空POST問題）混合NTLM：

• 主站點是根據與http://siteurl訪問根目錄IIS託管（1 ）
• 我們在相同程序池一個單獨的應用程序下託管http://siteurl/Intranet（2）

主應用程序（1）具有沿側表單驗證（URL啓用匿名驗證：SITEURL /登錄表單）。 第二個應用程序（2）具有集成身份驗證（NTLM）。

登錄程序的工作原理如下：

1. 用戶進入SITEURL第一
2. 用戶被重定向到/ Intranet的檢查集成身份驗證
3. 如果集成接受用戶獲取與適當的身份驗證餅乾重定向到siteurl並訪問該站點
4. 如果集成失敗用戶被重定向到siteurl/loginForm以手動填寫憑證

我們在Internet Explorer（8,9,10）拒絕在步驟4提交表單數據時遇到了一些問題。它似乎是一種已知的行爲，即一旦NTLM協商啓動，IE就不會將內容發佈到未經身份驗證的站點爲那屆會議。我已經考慮了一些解決方法：

1. 將憑據存儲在cookie（帶有JS）和服務器上（如果POST內容長度爲0）嘗試檢查cookie值。刪除cookie之後
2. 使用發送憑據GET而不是POST（醜陋的，因爲我們需要確保用戶不會看到在瀏覽器地址欄中他剛剛發佈的密碼）
3. 提供一個鏈接，用戶可以打開一個新的並在單獨的瀏覽器會話中繼續驗證過程（這似乎工作，因爲IE將愉快地從第二個選項卡發送POST數據）

是否有任何其他選項可能需要解決此問題？ 從上述3哪個更可取，哪些是我們可能遇到的不容忽視的陷阱？

Answer 1

我寫了一篇關於這個問題在這裏：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請求證書，並且example.com/和example.com/foo/是不同的保護空間，所以您永遠不應該看到使用文字描述的問題。

如果您可以共享此場景的Fiddler日誌以更好地排除故障，這將非常有幫助。