Прокси URL работи кога е конфигуриран директно, но автентикацијата не успева откако истата вредност ќе се премести во Windows batch-датотека. Проверете дали batch-парсерот ги променил знаците за процент пред HTTP-клиентот да го прими URL-то.

Постојат две одделни претстави. URL-кодирањето може да претстави обратна коса црта како %5C и прашалник како %3F. Буквален знак за процент во наредба на batch-датотека треба да се escape-ира како %%.

За илустративна сметка 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 или наредба изградена за втор shell, може да внесе уште еден премин на парсирање и бара сопствен преглед.

Ставете го SET-доделувањето во наводници како што е прикажано, за да не станат случајни празни места или метазнаци на shell дел од ненамерна наредба. Самите наводници не спречуваат проширување на процентот.

Кога го проверувате резултатот, споредете го очекуваното кодирање со редактирана претстава наместо да го печатите URL-то со лозинката во споделен дневник. Поправката на escape-ирањето во shell ги зачувува податоците за најава; таа не избира шема за автентикација што клиентот веќе не ја поддржувал.

Поврзани статии