NuGet 407 vs. 401: proxy-login eller legitimationsoplysninger til privat feed?
Adskil legitimationsoplysninger til NuGet-feedet fra legitimationsoplysninger til forward-proxyen, og undersøg den konfiguration, som det værktøj, der faktisk udfører gendannelsen, bruger.
En NuGet-gendannelse kan kræve både en forward-proxy-konto og en konto til et privat feed. Brug svaret til at afgøre, hvilken konfiguration der skal undersøges:
| Observation | Start her |
|---|---|
| Proxyen returnerer 407 | Den rute og konto, der bruges til at nå forward-proxyen |
| Pakkekilden returnerer 401 | Feedets godkendelseskonfiguration |
| Forbindelsen eller TLS fejler før et svar | Dokumentationen for endepunktet, transporten og certifikatet |
Et feed-token kan ikke besvare proxyens 407. Ligeledes har en forbindelses- eller TLS-fejl før et svar ikke fastslået, hvilken adgangskode der er forkert.
Konfigurer proxyen separat fra feedet
NuGets proxy-post hører under config. For en rute uden indlejrede legitimationsoplysninger:
<configuration>
<config>
<add key="http_proxy" value="http://proxy.example:8080" />
</config>
</configuration>Flet dette eksempel ind i den relevante eksisterende konfiguration. Til et offentligt feed, hvor offentlige mellemled er tilladt, tilbyder listen over HTTP-proxier en kandidat til denne rute uden legitimationsoplysninger. Hold pakkekilder i deres egen sektion; at erstatte feedets URL med en generisk proxyadresse beder mellemleddet om pakker.
Den dokumenterede værdi http_proxy.password er krypteret. Brug det understøttede konfigurationsværktøj i stedet for at skrive klartekst i det felt eller kopiere en kodet udseende værdi fra en anden maskine, som om det var et portabelt legitimationsformat.
Undersøg den gendannelse, der faktisk fejler
Navngiv klienten, brugeren og startmiljøet, og find derefter dets effektive konfigurationshierarki. Indstillinger for bruger, maskine og løsning kan bidrage. En gammel devenv.exe.config-rettelse vedrører en bestemt Visual Studio-proces; den fastslår ikke, hvad en kommandolinje-gendannelse eller byggetjeneste læser. Bevar fungerende pakkekilder og politik, mens du finder en forældet proxy-post.
Når godkendelsen virker, følg enhver senere mislykket URL. Feedmetadata og pakkeindhold kan bruge forskellige endepunkter, så én accepteret anmodning fastslår ikke hele gendannelsesruten. Bevar normal validering af pakkesignatur og TLS, mens du retter det.