NuGet 407 kontraŭ 401: saluto al prokurilo aŭ akreditaĵoj de privata fluo?
Apartigu la akreditaĵojn de la NuGet-fluo disde tiuj de la antaŭa prokurilo, kaj inspektu la agordon uzatan de la ilo, kiu efektive faras la restarigon.
Restarigo de NuGet povas postuli kaj konton ĉe antaŭa prokurilo kaj konton ĉe privata fluo. Uzu la respondon por decidi kiun agordon inspekti:
| Observo | Komencu ĉi tie |
|---|---|
| La prokurilo redonas 407 | La vojo kaj konto uzataj por atingi la antaŭan prokurilon |
| La paka fonto redonas 401 | La aŭtentiga agordo de la fluo |
| La konekto aŭ TLS malsukcesas antaŭ respondo | La pruvoj pri finpunkto, transporto kaj atestilo |
Ĵetono de fluo ne povas respondi la 407 de la prokurilo. Same, konekta aŭ TLS-malsukceso antaŭ respondo ne pruvis, kiu pasvorto estas malĝusta.
Agordu la prokurilon aparte de la fluo
La prokurila ero de NuGet apartenas sub config. Por vojo sen enkonstruitaj akreditaĵoj:
<configuration>
<config>
<add key="http_proxy" value="http://proxy.example:8080" />
</config>
</configuration>Kunfandu ĉi tiun ekzemplon en la taŭgan ekzistantan agordon. Por publika fluo, kie publikaj perantoj estas permesataj, la listo de HTTP-prokuriloj proponas kandidaton por ĉi tiu akreditaĵa vojo. Konservu pakajn fontojn en ilia propra sekcio; anstataŭigi la fluan URL per ĝenerala prokurila adreso petas de la peranto pakojn.
La dokumentita valoro http_proxy.password estas ĉifrita. Uzu la subtenatajn agordilojn anstataŭ skribi klartekston en tiu kampo aŭ kopii de alia maŝino ŝajne koditan valoron kvazaŭ ĝi estus portebla akreditaĵa formato.
Inspektu la restarigon, kiu efektive malsukcesas
Nomu la klienton, uzanton kaj lanĉan medion, poste trovu ĝian efektivan agordan hierarkion. Agordoj de uzanto, maŝino kaj solvo povas kontribui. Malnova riparo per devenv.exe.config koncernas apartan Visual Studio-procezon; ĝi ne pruvas, kion legas komandlinia restarigo aŭ konstrua servo. Konservu funkciantajn pakajn fontojn kaj politikon dum vi serĉas eksvalidiĝintan prokurilan eron.
Post kiam aŭtentigo funkcias, sekvu ĉiun poste malsukcesan URL. Fluaj metadatumoj kaj paka enhavo povas uzi malsamajn finpunktojn, do unu akceptita peto ne pruvas la plenan restarigan vojon. Konservu la normalan pakan subskribon kaj TLS-kontrolon dum vi korektas ĝin.