Azure。 URL重寫。認證模式表單。

這是一個名爲「我如何處理，通常IIS相關的東西」Azure。 URL重寫。認證模式表單。

前幾次長故事的最後一集（我希望）： Ep1。 Ep2。

所以。

我已經設置了URL重寫來處理所有主要網站API請求與反向代理並將它們傳遞到場景後面的新API。

除了api（新web應用程序）返回狀態401（由於錯誤的標記等）的情況以外，所有工作都很好。

用戶應該看到401未經授權，但它試圖將他重定向到"/login?returnUrl=some/api/url/which/returns/401/status"。

據我所知這是因爲我在主網站的web.config有這樣的身份驗證設置。

<authentication mode="Forms"> 
     <forms loginUrl="~/login" timeout="100000" requireSSL="false" /> 
</authentication>

所以請求工作流程是這樣的：

用戶請求mainapp.com/api/some/endpoint。
IIS與URL重寫處理它，並重定向到apiapp.com/api/some/endpoint
apiapp.com處理它，並返回401狀態
mainapp.com處理401種狀態，並返回/login?returnUrl=api/some/endpoint

爲什麼在p 302個狀態.4發生？我只需要傳遞迴應，並讓mainapp.com根本沒有想到它。

是否有可能以某種方式解決它？

來源

2017-07-04 korovaisdead

你期待什麼mainapp.com是來自mainapp.com的反向代理行爲。我檢查了你的EP1，所以我假設你已經配置了反向代理。然而，這與您在這裏提到的請求被重定向時的觀點2相矛盾。如果您提到網站在Azure中的託管位置以及這兩個網站的URL重寫部分，這將有所幫助。沒有這些，很難說什麼。此外，您可能希望爲Web應用啓用失敗請求跟蹤以進一步調查此問題。 –

URL只爲mainapp重寫。是的，在蔚藍。沒有重定向，只是重寫。 – korovaisdead

因此，當你說Azure時，它是Azure應用服務還是虛擬機或雲服務？ –

所以根據您的設置是這樣的請求流：

客戶端----> mainapp.com ----> apiapp.com

根據您的詳細信息Mainapp.com被設置爲反向代理。然而，第4點則表明不然。爲了確保，您可以在兩個Web應用上啓用失敗請求跟蹤並查看日誌。

這是一個2步處理，

啓用失敗請求門戶

添加以下部分到web跟蹤。你的web應用程序的配置（根）：

這將幫助你瞭解發生了什麼事的請求。

來源

2017-07-04 12:17:49

我很明白是什麼原因引起的問題。這是主網站web.config內的認證部分。但無論如何，我會嘗試驗證失敗的請求。 – korovaisdead

所以你有mainapp.com中的''部分？如果是，那麼我會建議您查看整個設置。 –

是的，我有...我寫在主要問題順便說一句。我唯一想做的就是用apiapp.com/api/*處理所有到mainapp.com/api/*的請求，就是這樣。 – korovaisdead

我有完全相同的問題。就我而言，罪魁禍首是在mainapp.com的web.config中。具體來說，根據需要設置了身份驗證，並且我爲login.aspx定義了一個重定向。有問題的代碼是在這裏：

<authentication mode="Forms"> 
     <forms name="yourAuthCookie" loginUrl="login.aspx" protection="All" path="/" /> 
</authentication> 
<authorization> 
     <allow users="?" /> 
</authorization>

評論了這一點後，我可以證明它是被交給了401未經授權從代理的調用返回的apiapp.com

來源

2017-12-11 15:48:18

Azure。 URL重寫。認證模式表單。

回答

相關問題