NuGet 407 vs. 401: Proxy-Anmeldung oder Anmeldeinformationen für privaten Feed?
Trennen Sie NuGet-Feed-Anmeldeinformationen von Forward-Proxy-Anmeldeinformationen und prüfen Sie die Konfiguration des Tools, das die Wiederherstellung tatsächlich ausführt.
Eine NuGet-Wiederherstellung kann sowohl ein Forward-Proxy-Konto als auch ein Konto für einen privaten Feed erfordern. Nutzen Sie die Antwort, um zu entscheiden, welche Konfiguration zu prüfen ist:
| Beobachtung | Hier beginnen |
|---|---|
| Proxy gibt 407 zurück | Die Route und das Konto, mit denen der Forward-Proxy erreicht wird |
| Paketquelle gibt 401 zurück | Die Authentifizierungskonfiguration des Feeds |
| Verbindung oder TLS schlägt vor einer Antwort fehl | Die Belege zu Endpunkt, Transport und Zertifikat |
Ein Feed-Token kann den 407 des Proxys nicht beantworten. Ebenso hat ein Verbindungs- oder TLS-Fehler vor einer Antwort nicht geklärt, welches Passwort falsch ist.
Proxy getrennt vom Feed konfigurieren
Der Proxy-Eintrag von NuGet gehört unter config. Für eine Route ohne eingebettete Anmeldeinformationen:
<configuration>
<config>
<add key="http_proxy" value="http://proxy.example:8080" />
</config>
</configuration>
Fügen Sie dieses Beispiel in die passende vorhandene Konfiguration ein. Für einen öffentlichen Feed, bei dem öffentliche Zwischenstellen zulässig sind, bietet die HTTP-Proxy-Liste einen Kandidaten für diese anmeldeinformationsfreie Route. Behalten Sie Paketquellen in ihrem eigenen Abschnitt; das Ersetzen einer Feed-URL durch eine allgemeine Proxyadresse verlangt von der Zwischenstelle Pakete.
Der dokumentierte Wert http_proxy.password ist verschlüsselt. Verwenden Sie die unterstützten Konfigurationswerkzeuge, statt Klartext in dieses Feld zu schreiben oder einen verschlüsselt aussehenden Wert von einem anderen Rechner zu kopieren, als wäre er ein übertragbares Anmeldeinformationsformat.
Die Wiederherstellung prüfen, die tatsächlich fehlschlägt
Benennen Sie Client, Benutzer und Startumgebung und ermitteln Sie dann deren wirksame Konfigurationshierarchie. Einstellungen von Benutzer, Computer und Lösung können dazu beitragen. Eine alte devenv.exe.config-Korrektur betrifft einen bestimmten Visual Studio-Prozess; sie belegt nicht, was eine Kommandozeilen-Wiederherstellung oder ein Builddienst liest. Bewahren Sie funktionierende Paketquellen und Richtlinien, während Sie einen veralteten Proxy-Eintrag suchen.
Wenn die Authentifizierung funktioniert, folgen Sie jeder später fehlschlagenden URL. Feed-Metadaten und Paketinhalt können unterschiedliche Endpunkte verwenden, daher belegt eine akzeptierte Anforderung nicht die vollständige Wiederherstellungsroute. Bewahren Sie die normale Paketsignatur- und TLS-Prüfung, während Sie dies korrigieren.