URL прокси работает при прямой настройке, но аутентификация перестаёт работать после переноса того же значения в пакетный файл Windows. Проверьте, не изменил ли синтаксический анализатор пакетного файла знаки процента до того, как HTTP-клиент получил URL.

Есть два разных представления. Кодирование URL может представлять обратную косую черту как %5C, а вопросительный знак как %3F. Буквальный знак процента в команде пакетного файла нужно экранировать как %%.

Для иллюстративной учётной записи domain\user с паролем-заполнителем pass? файл .bat может содержать:

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

Запускаемый после этого процесс должен получить URL, содержащий domain%5Cuser:pass%3F. Удвоенные знаки процента принадлежат исходнику пакетного файла, а не URL прокси, который хранит клиент.

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

Заключите присваивание SET в кавычки, как показано, чтобы случайные пробелы или метасимволы оболочки не стали частью непредусмотренной команды. Одни кавычки не предотвращают раскрытие процента.

Проверяя результат, сравнивайте ожидаемое кодирование с отредактированным представлением, а не печатайте URL с паролем в общий журнал. Исправление экранирования оболочки сохраняет учётные данные; оно не выбирает схему аутентификации, которую клиент и так не поддерживал.

Похожие статьи