URL адресът на прокси работи, когато е конфигуриран директно, но удостоверяването се проваля, след като същата стойност се премести в Windows batch файл. Проверете дали парсерът на batch е променил процентните знаци, преди HTTP клиентът да получи URL адреса.

Има две отделни представяния. URL кодирането може да представи обратна наклонена черта като %5C и въпросителен знак като %3F. Буквалният процентен знак в команда на batch файл трябва да бъде екраниран като %%.

За примерен акаунт domain\user с парола-заместител pass?, един .bat файл може да съдържа:

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

Стартираният след това процес трябва да получи URL адрес, съдържащ domain%5Cuser:pass%3F. Удвоените процентни знаци принадлежат на batch източника, а не на URL адреса на прокси, съхранен от клиента.

Не копирайте този batch правопис във файл .npmrc или в полето за прокси на приложение: тези входове не минават през същата стъпка на batch анализ. По същия начин този пример не е синтаксис на PowerShell. Друга обвивка, като CALL или команда, изградена за втора обвивка, може да въведе още един проход на анализ и се нуждае от собствен преглед.

Поставете присвояването SET в кавички, както е показано, за да не станат случайни интервали или метазнаци на обвивката част от нежелана команда. Самите кавички не предотвратяват разгръщането на процента.

Когато проверявате резултата, сравнявайте очакваното кодиране с редактирано представяне, вместо да отпечатвате URL адреса с паролата в споделен журнал. Поправката на екранирането на обвивката запазва идентификационните данни; тя не избира схема за удостоверяване, която клиентът не е поддържал.

Подобни статии