विंडोज क्रेडेंशियल

Question

यहाँ के साथ एक HTTPS समाप्ति बिंदु को एक WCF सेवा रीडायरेक्ट करने के लिए कैसे स्थिति मैं से निपटने के लिए कोशिश कर रहा हूँ है:

हम एक WCF ग्राहक कि एक http endpoint के साथ काम करता है और एक https endpoint नहीं बल्कि जब यह http से https तक रीडायरेक्ट किया गया है (302)। हमारे पास एक F5 लोड बैलेंसर है जो रीडायरेक्ट और SSL कार्यक्षमता कर रहा है लेकिन जहां तक ​​मैं कह सकता हूं, यह अनुरोधों के लिए अप्रत्याशित कुछ भी नहीं कर रहा है। रीडायरेक्ट अपराधी प्रतीत होता है जहां डब्ल्यूसीएफ रीडायरेक्ट किए जाने के बाद विंडोज केर्बेरोस प्रमाणीकरण जानकारी प्रदान नहीं करना चाहता है।

एक सफल कॉल (यानी http कोई रीडायरेक्ट के साथ) के लिए अनुक्रम इस प्रकार है:

• क्लाइंट -
• सर्वर http योजना के साथ सेवा के लिए पोस्ट अनुरोध भेजता है - के साथ 401 अनधिकृत
• ग्राहक प्रतिक्रिया करता है - भेजता प्राधिकरण के साथ पोस्ट निगोशिएट
• सर्वर - 100 के साथ प्रतिक्रिया करता है जारी
• क्लाइंट - साबुन डेटा भेजता है और सफलतापूर्वक पूरा

जब कॉल पुनः निर्देशित है और यह इस प्रकार है विफल रहता है:

• क्लाइंट - http योजना के साथ सेवा के लिए पोस्ट अनुरोध भेजता
• सर्वर - एक ही पते
के लिए https योजना को पुन: निर्देशन के साथ रिटर्न 302
• क्लाइंट - भेजता https पते के लिए प्राप्त (मैं समझ नहीं क्यों यह एक GET और नहीं एक पोस्ट है)
• सर्वर - 401 अनधिकृत
साथ प्रतिक्रिया करता है 0
• क्लाइंट - अपवाद फेंकता है "HTTP अनुरोध क्लाइंट प्रमाणीकरण योजना 'वार्तालाप' के साथ अनधिकृत है। प्रमाणीकरण सर्वर से प्राप्त हैडर था 'निगोशिएट, NTLM'। तोड़ने WCF प्रोटोकॉल "

यह this problem के समान है लेकिन ठीक उसी नहीं है (और वहाँ वास्तव में एक जवाब नहीं है, हालांकि यह संदर्भ करता है" " जो मुझे ड्यूमेटेशन मिल सकता है)। अगर हम एफ 5 रीडायरेक्ट नियम http और https ट्रैफिक को ठीक से काम करते हैं। क्या डब्ल्यूसीएफ वास्तव में इस सरल रीडायरेक्ट को संभाल नहीं लेता है? क्या इस दोष पर कोई कामकाज या कोई दस्तावेज है?

क्लाइंट कॉन्फ़िगरेशन (ध्यान दें कि https के साथ इसका परीक्षण करते समय, मैं ट्रांसपोर्ट क्रेडिट को केवल परिवहन में बदलता हूं):

<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> 

सर्वर config इस तरह दिखता है:

<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> 

Answer 1

मैं समझ नहीं क्यों यह एक प्राप्त है और एक पोस्ट

आपकी समस्या का कारण है कि नहीं। किसी पोस्ट के लिए 302 प्रतिक्रिया प्राप्त करने के बाद, क्लाइंट के लिए नया यूआरएल प्राप्त करने के लिए व्यवहार की उम्मीद है।http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

पर निम्न 302 स्थिति कोड GET या HEAD, उपयोगकर्ता एजेंट नहीं स्वचालित रूप से अनुरोध यदि इसे उपयोगकर्ता द्वारा पुष्टि की जा सकती रीडायरेक्ट करना चाहिए के अलावा किसी अन्य अनुरोध के जवाब में प्राप्त होता है, तो यह हो सकता है के बाद से देखें उन शर्तों को बदलें जिनके तहत अनुरोध जारी किया गया था। Response.Redirect with POST instead of Get?

तो WCF कर रही है क्या यह एक 302 रीडायरेक्ट के बाद फिर से पोस्ट से इनकार करके करना चाहिए:

इसके अलावा, अतः निम्नलिखित पोस्ट कुछ अच्छी जानकारी है। दुर्भाग्यवश मुझे यकीन नहीं है कि आपकी समस्या को हल करने के लिए क्या किया जा सकता है, प्रोटोकॉल को 302 से बचने के लिए पहली बार सही ढंग से निर्दिष्ट करने के अलावा।

Answer 2

मैंने अभी कुछ ऐसा किया है और मैं पुष्टि कर सकता हूं कि यह काम नहीं करता है। इससे भी बदतर क्या संभवतः डिफ़ॉल्ट डब्ल्यूसीएफ HTTP परिवहन कार्यान्वयन को बदले बिना बदलना संभव नहीं है।

दोनों पुनर्निर्देशन और प्रमाणीकरण सीधे डब्ल्यूसीएफ की HTTP प्रसंस्करण के अंदर संभाला जाता है जो आंतरिक है। आप मैन्युअल रूप से पुनर्निर्देशन को संभाल नहीं सकते हैं, यदि आपको 301 स्थायी रूप से स्थानांतरित किया गया है और WCF पुनर्निर्देशन के बाद आपके कॉन्फ़िगर किए गए क्लाइंट प्रमाण-पत्रों का उपयोग नहीं करता है तो समस्या का कारण बनता है।

पुनर्निर्देशन के बाद पोस्ट की बजाय भेजने के साथ समस्या यह सैद्धांतिक रूप से 307 अस्थायी रीडायरेक्ट लौटने के बजाय 302 मिली द्वारा हल किया जाना चाहिए।