En proxy-URL fungerar när den konfigureras direkt, men autentiseringen misslyckas efter att samma värde har flyttats till en Windows-batchfil. Kontrollera om batchparsern ändrade procenttecknen innan HTTP-klienten fick URL:en.

Det finns två separata representationer. URL-kodning kan representera ett omvänt snedstreck som %5C och ett frågetecken som %3F. Ett bokstavligt procenttecken i ett batchfilskommando måste escapas som %%.

För ett illustrativt konto domain\user med platshållarlösenordet pass? kan en .bat-fil innehålla:

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

Processen som startas efteråt bör få en URL som innehåller domain%5Cuser:pass%3F. De dubblade procenttecknen tillhör batchkällan, inte proxy-URL:en som klienten sparar.

Kopiera inte den batchstavningen till en .npmrc-fil eller ett programs proxyfält: dessa indata går inte genom samma batchparsningssteg. På samma sätt är det här exemplet inte PowerShell-syntax. Ett annat omslag, som CALL eller ett kommando byggt för ett andra skal, kan införa ytterligare en parsningsomgång och behöver sin egen granskning.

Sätt SET-tilldelningen inom citattecken som visat, så att tillfälliga blanksteg eller skalmetatecken inte blir en del av ett oavsiktligt kommando. Citattecken ensamma förhindrar inte procentexpansion.

När du kontrollerar resultatet, jämför den förväntade kodningen med en redigerad representation i stället för att skriva ut URL:en med lösenordet till en delad logg. En rättning av skal-escaping bevarar inloggningsuppgifterna; den väljer inte ett autentiseringsschema som klienten inte redan stödde.

Relaterade artiklar