NuGet 407 і 401: вхід на проксі чи облікові дані приватного каналу?

Відокремте облікові дані каналу NuGet від облікових даних прямого проксі та перевірте конфігурацію, яку використовує інструмент, що фактично виконує відновлення.

Відновлення NuGet може вимагати як облікового запису прямого проксі, так і облікового запису приватного каналу. Використайте відповідь, щоб визначити, яку конфігурацію перевіряти:

СпостереженняПочніть тут
Проксі повертає 407Маршрут і обліковий запис, які використовуються для доступу до прямого проксі
Джерело пакетів повертає 401Конфігурація автентифікації каналу
З'єднання або TLS не вдається до відповідіДані про кінцеву точку, транспорт і сертифікат

Токен каналу не може відповісти на 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, поки це виправляєте.

Схожі статті