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, докато го коригирате.

Подобни статии