Պրոքսի 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"

Այնուհետև գործարկվող գործընթացը պետք է ստանա domain%5Cuser:pass%3F պարունակող URL։ Կրկնապատկված տոկոսանշանները պատկանում են batch աղբյուրին, ոչ թե հաճախորդի պահած պրոքսի URL-ին։

Չպատճենեք այդ batch գրությունը .npmrc ֆայլում կամ հավելվածի պրոքսի դաշտում. այդ մուտքերը չեն անցնում batch վերլուծության նույն քայլով։ Նույն կերպ, այս օրինակը PowerShell շարահյուսություն չէ։ Այլ փաթաթիչ, օրինակ CALL-ը կամ երկրորդ shell-ի համար կառուցված հրահանգը, կարող է ներմուծել վերլուծության ևս մեկ անցում և պահանջում է իր սեփական վերանայումը։

Տեղադրեք SET վերագրումը չակերտների մեջ, ինչպես ցույց է տրված, որպեսզի պատահական բացատները կամ shell-ի մետանշանները չդառնան ակամա հրահանգի մաս։ Միայն չակերտները չեն կանխում տոկոսի ընդլայնումը։

Արդյունքը ստուգելիս համեմատեք սպասվող կոդավորումը խմբագրված ներկայացման հետ՝ փոխարենը գաղտնաբառ պարունակող URL-ը ընդհանուր մատյանում տպելու։ Shell-ի escape ուղղումը պահպանում է հավատարմագիրը. այն չի ընտրում նույնականացման սխեմա, որը հաճախորդն արդեն չէր աջակցում։

Առնչվող հոդվածներ