如何WCF服務重定向到HTTPS端點與Windows憑據

這裏是我試圖處理情況：如何WCF服務重定向到HTTPS端點與Windows憑據

我們有一個WCF客戶端與HTTP端點工作和HTTPS端點而不是在它從http重定向（302）到https。我們有一個正在執行重定向和SSL功能的F5負載均衡器，但據我所知，它並沒有對請求產生任何意想不到的結果。重定向似乎是WCF在重定向執行後不想提供Windows Kerberos身份驗證信息的罪魁禍首。

一個成功的調用（即HTTP無重定向）的順序是這樣的：

客戶端 - 發送POST請求的服務以http方式
服務器 - 與401未經授權
客戶端響應 - 發送具有授權的協商POST
服務器 - 以100繼續響應
客戶端 - 發送肥皂數據併成功完成

當呼叫重定向和失敗，它是這樣的：

客戶端 - 發送POST請求的服務以http方式
服務器 - 具有重定向返回302到https方案爲同一地址
客戶端 - 發送GET爲HTTPS地址（我想不通爲什麼這是一個GET而不是POST）
服務器 - 與401未經授權
客戶端 - 拋出異常「HTTP請求未經客戶端身份驗證方案」協商「授權。從服務器接收認證報頭是「協商，NTLM」。」

它類似於this problem但不完全相同（並沒有一個真正的答案了，雖然它引用‘破WCF協議’如果我們關閉F5重定向規則http和https通信工作正常WCF是否真的不處理這個簡單的重定向？是否有解決方法或任何文檔在這個缺陷？

客戶端配置請注意，當使用https測試時，我將TransportCredentialOnly更改爲傳輸）：

<client> 
     <endpoint address="http://fooserver/MyService.svc/" binding="basicHttpBinding" bindingConfiguration="clientBinding" contract="Contracts.IMyService" /> 
</client> 
<bindings> 
<basicHttpBinding> 
    <binding name="clientBinding"> 
     <security mode="TransportCredentialOnly"> 
      <transport clientCredentialType="Windows" proxyCredentialType="Windows" /> 
     </security> 
    </binding> 
</basicHttpBinding>

服務器的配置是這樣的：

<system.serviceModel> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    <services> 
     <service behaviorConfiguration="MyServiceBehavior" name="MyService"> 
      <endpoint address="" binding="basicHttpBinding" bindingConfiguration="securedBinding" contract="Contracts.IMyService"> 
      </endpoint> 
     </service> 
    </services> 
    <bindings> 
     <basicHttpBinding> 
      <binding name="securedBinding"> 
       <security mode="TransportCredentialOnly"> 
        <transport clientCredentialType="Windows" proxyCredentialType="Windows"/> 
       </security> 
      </binding> 
     </basicHttpBinding> 
    </bindings> 
    <behaviors> 
     <serviceBehaviors> 
      <behavior name="MyServiceBehavior"> 
       <serviceMetadata httpGetEnabled="true"/> 
       <serviceDebug includeExceptionDetailInFaults="true"/> 
       <useRequestHeadersForMetadataAddress> 
        <defaultPorts> 
         <add scheme="http" port="80" /> 
         <add scheme="https" port="443" /> 
        </defaultPorts> 
       </useRequestHeadersForMetadataAddress> 
      </behavior> 
     </serviceBehaviors> 
    </behaviors> 
</system.serviceModel>

來源

2012-03-14 Uriah Blatherwick

的可能的複製[爲什麼會失敗WCF調用遇到302響應時，SOAP服務？（http://stackoverflow.com/questions/17152385/why-would-wcf-fail-to-call-a -so--302-response-is-encounter） – Luizgrs 2015-10-08 20:12:04

我想不通爲什麼這是一個GET而不是POST

那是你的問題的原因。在接收到對POST的302響應之後，預計客戶端會獲取新URL的行爲。看到在http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

如果接收響應302個的狀態碼比GET或HEAD，用戶代理不能自動重定向請求，除非它可以由用戶來確認其他的請求下，因爲這可能改變發出請求的條件。

此外，下面的SO職位有一些好的信息：Response.Redirect with POST instead of Get?

所以WCF是做什麼的，應該拒絕302重定向後重新發布做。不幸的是我不知道可以做些什麼來解決你的問題，其他的不是指定正確的協議，在第一時間，以避免302

來源

2012-03-14 18:24:05

這肯定解釋了GET，但它看起來像WCF應該能夠處理這個開關。也許在它的內部WCF只發送一個帖子的信用？就像這個框架的一部分沒有正確實現？一定要知道的方法會很棒。 – 2012-03-14 18:34:37

401 Unauthorized包含相應的WWW-Authenticate頭文件嗎？ – 2012-03-14 19:49:16

這兩個401s（與重定向和沒有重定向是相同的） – 2012-03-14 20:00:41

我只是做了類似的事情，我可以證實，這是行不通的。更糟的是，如果不更換默認的WCF HTTP傳輸實現，則可能無法進行更改。

重定向和身份驗證均直接在內部的WCF HTTP處理內處理。您不能手動處理重定向導致問題，如果您得到301永久移動和WCF重定向後不使用您配置的客戶端憑據。

具有重定向後發送GET代替POST的問題應該通過返回307臨時重定向代替302實測值從理論上得到解決。

來源

2012-05-16 14:39:14

我敢肯定，我們嘗試了這一點，WCF不理解響應。我希望有辦法在4.5中處理這個，但我沒有看着它呢。 – 2012-05-31 12:43:01

如何WCF服務重定向到HTTPS端點與Windows憑據

回答

相關問題