NuGet 407 a 401: logowanie do serwera proxy czy poświadczenia prywatnego kanału?
Oddziel poświadczenia kanału NuGet od poświadczeń serwera proxy i sprawdź konfigurację używaną przez narzędzie, które faktycznie wykonuje przywracanie.
Przywracanie NuGet może wymagać zarówno konta serwera proxy, jak i konta prywatnego kanału. Użyj odpowiedzi, aby zdecydować, którą konfigurację sprawdzić:
| Obserwacja | Zacznij tutaj |
|---|---|
| Serwer proxy zwraca 407 | Trasa i konto używane do dotarcia do serwera proxy |
| Źródło pakietów zwraca 401 | Konfiguracja uwierzytelniania kanału |
| Połączenie lub TLS zawodzi przed odpowiedzią | Dowody dotyczące punktu końcowego, transportu i certyfikatu |
Token kanału nie może odpowiedzieć na 407 serwera proxy. Podobnie awaria połączenia lub TLS przed odpowiedzią nie wykazała, które hasło jest nieprawidłowe.
Skonfiguruj serwer proxy osobno od kanału
Wpis serwera proxy w NuGet należy do config. Dla trasy bez osadzonych poświadczeń:
<configuration>
<config>
<add key="http_proxy" value="http://proxy.example:8080" />
</config>
</configuration>Scal ten przykład z odpowiednią istniejącą konfiguracją. Dla publicznego kanału, w którym dozwolone są publiczne pośredniki, lista serwerów proxy HTTP oferuje kandydata do tej trasy bez poświadczeń. Trzymaj źródła pakietów w ich własnej sekcji; zastąpienie adresu URL kanału ogólnym adresem serwera proxy prosi pośrednika o pakiety.
Udokumentowana wartość http_proxy.password jest zaszyfrowana. Używaj obsługiwanych narzędzi konfiguracyjnych, zamiast wpisywać zwykły tekst w tym polu lub kopiować z innego komputera wartość wyglądającą na zaszyfrowaną, jakby była przenośnym formatem poświadczeń.
Sprawdź przywracanie, które faktycznie zawodzi
Nazwij klienta, użytkownika i środowisko uruchomienia, a następnie znajdź efektywną hierarchię konfiguracji. Wkład mogą wnosić ustawienia użytkownika, komputera i rozwiązania. Stara poprawka devenv.exe.config dotyczy konkretnego procesu Visual Studio; nie ustala, co czyta przywracanie z wiersza poleceń lub usługa kompilacji. Zachowaj działające źródła pakietów i zasady, szukając nieaktualnego wpisu serwera proxy.
Gdy uwierzytelnianie działa, śledź każdy później nieudany adres URL. Metadane kanału i zawartość pakietów mogą używać różnych punktów końcowych, więc jedno zaakceptowane żądanie nie ustala całej trasy przywracania. Zachowaj normalną walidację podpisu pakietów i TLS podczas poprawiania tego.