NuGet 407 बनाम 401: प्रॉक्सी लॉगिन या निजी फ़ीड क्रेडेंशियल?

NuGet रिस्टोर के लिए फ़ॉरवर्ड-प्रॉक्सी खाता और निजी फ़ीड खाता दोनों आवश्यक हो सकते हैं। यह तय करने के लिए कि कौन-सा कॉन्फ़िगरेशन जाँचना है, प्रतिक्रिया का उपयोग करें:

फ़ीड टोकन प्रॉक्सी के 407 का उत्तर नहीं दे सकता। इसी तरह, प्रतिक्रिया से पहले कनेक्शन या TLS विफलता ने यह स्थापित नहीं किया है कि कौन-सा पासवर्ड गलत है।

प्रॉक्सी को फ़ीड से अलग कॉन्फ़िगर करें

NuGet की प्रॉक्सी प्रविष्टि config के अंतर्गत आती है। बिना अंतर्निहित क्रेडेंशियल वाले मार्ग के लिए:

<configuration>
  <config>
    <add key="http_proxy" value="http://proxy.example:8080" />
  </config>
</configuration>

इस उदाहरण को उपयुक्त मौजूदा कॉन्फ़िगरेशन में मिलाएँ। जहाँ सार्वजनिक मध्यस्थों की अनुमति है ऐसे सार्वजनिक फ़ीड के लिए, HTTP प्रॉक्सी सूची इस क्रेडेंशियल-रहित मार्ग के लिए एक उम्मीदवार देती है। पैकेज स्रोतों को उनके अपने अनुभाग में रखें; फ़ीड URL को सामान्य प्रॉक्सी पते से बदलना मध्यस्थ से पैकेज माँगता है।

प्रलेखित http_proxy.password मान एन्क्रिप्टेड है। उस फ़ील्ड में सादा टेक्स्ट लिखने या किसी अन्य मशीन से एन्कोडेड दिखने वाला मान पोर्टेबल क्रेडेंशियल प्रारूप मानकर कॉपी करने के बजाय समर्थित कॉन्फ़िगरेशन टूल का उपयोग करें।

उसी रिस्टोर की जाँच करें जो वास्तव में विफल होता है

क्लाइंट, उपयोगकर्ता और लॉन्च वातावरण का नाम लें, फिर उसका प्रभावी कॉन्फ़िगरेशन पदानुक्रम खोजें। उपयोगकर्ता, मशीन और समाधान सेटिंग्स योगदान कर सकती हैं। पुराना devenv.exe.config सुधार किसी विशेष Visual Studio प्रक्रिया से संबंधित है; यह स्थापित नहीं करता कि कमांड-लाइन रिस्टोर या बिल्ड सेवा क्या पढ़ती है। अप्रचलित प्रॉक्सी प्रविष्टि खोजते समय काम करने वाले पैकेज स्रोत और नीति सुरक्षित रखें।

प्रमाणीकरण काम करने के बाद, बाद में विफल होने वाले किसी भी URL का अनुसरण करें। फ़ीड मेटाडेटा और पैकेज सामग्री अलग-अलग एंडपॉइंट उपयोग कर सकते हैं, इसलिए एक स्वीकृत अनुरोध पूरा रिस्टोर मार्ग स्थापित नहीं करता। इसे ठीक करते समय सामान्य पैकेज-हस्ताक्षर और TLS सत्यापन बनाए रखें।