Prokura URL funkcias kiam ĝi estas agordita rekte, sed aŭtentigo malsukcesas post kiam la sama valoro moviĝas en Windows-batch-dosieron. Kontrolu ĉu la batch-analizilo ŝanĝis la procentosignojn antaŭ ol la HTTP-kliento ricevis la URL.

Estas du apartaj reprezentoj. URL-kodado povas reprezenti maldekstran deklivan strekon kiel %5C kaj demandosignon kiel %3F. Laŭvorta procentosigno en batch-dosiera komando bezonas eskapigon kiel %%.

Por ilustra konto domain\user kun la anstataŭa pasvorto pass?, .bat-dosiero povas enhavi:

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

La poste lanĉata procezo devus ricevi URL-on enhavantan domain%5Cuser:pass%3F. La duobligitaj procentosignoj apartenas al la batch-fonto, ne al la prokura URL konservita de la kliento.

Ne kopiu tiun batch-literumadon en .npmrc-dosieron aŭ en la prokuran kampon de aplikaĵo: tiuj enigoj ne trairas la saman batch-analizan paŝon. Same, ĉi tiu ekzemplo ne estas PowerShell-sintakso. Alia volvaĵo, kiel CALL aŭ komando konstruita por dua ŝelo, povas enkonduki plian analizan paŝon kaj bezonas sian propran revizion.

Metu la SET-agordon en citilojn kiel montrite, por ke hazardaj spacoj aŭ ŝelaj metaj signoj ne fariĝu parto de neintencita komando. Citiloj sole ne malhelpas procentan vastiĝon.

Kontrolante la rezulton, komparu la atendatan kodadon kun redaktita reprezentado anstataŭ presi la pasvortenhavan URL-on al komuna protokolo. Riparo de ŝela eskapigo konservas la akreditaĵon; ĝi ne elektas aŭtentigan skemon, kiun la kliento jam ne subtenis.

Rilataj artikoloj