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 যাচাই সংরক্ষণ করুন।