Adres URL proxy działa, gdy jest skonfigurowany bezpośrednio, ale uwierzytelnianie kończy się niepowodzeniem po przeniesieniu tej samej wartości do pliku wsadowego Windows. Sprawdź, czy parser wsadowy zmienił znaki procentu, zanim klient HTTP otrzymał adres URL.

Istnieją dwie odrębne reprezentacje. Kodowanie URL może przedstawić ukośnik odwrotny jako %5C, a znak zapytania jako %3F. Dosłowny znak procentu w poleceniu pliku wsadowego trzeba escapować jako %%.

Dla przykładowego konta domain\user z hasłem zastępczym pass? plik .bat może zawierać:

set "https_proxy=http://domain%%5Cuser:pass%%[email protected]:8080"

Uruchomiony później proces powinien otrzymać adres URL zawierający domain%5Cuser:pass%3F. Podwojone znaki procentu należą do źródła wsadowego, a nie do adresu URL proxy przechowywanego przez klienta.

Nie kopiuj tej pisowni wsadowej do pliku .npmrc ani do pola proxy aplikacji: te dane wejściowe nie przechodzą przez ten sam etap analizy wsadowej. Podobnie ten przykład nie jest składnią PowerShell. Inna otoczka, na przykład CALL lub polecenie zbudowane dla drugiej powłoki, może wprowadzić kolejny przebieg analizy i wymaga własnego przeglądu.

Umieść przypisanie SET w cudzysłowach, jak pokazano, aby przypadkowe spacje lub metaznaki powłoki nie stały się częścią niezamierzonego polecenia. Same cudzysłowy nie zapobiegają rozwinięciu procentu.

Sprawdzając wynik, porównaj oczekiwane kodowanie z zredagowaną reprezentacją, zamiast drukować adres URL z hasłem do współdzielonego dziennika. Poprawka escapowania powłoki zachowuje dane logowania; nie wybiera schematu uwierzytelniania, którego klient już nie obsługiwał.

Powiązane artykuły