Hou geënkodeerde proxy-aanmeldingsdata ongeskonde in 'n batch-lêer

'n Proxy-URL werk wanneer dit direk gekonfigureer word, maar verifikasie misluk nadat dieselfde waarde na 'n Windows-batchlêer verskuif het. Kontroleer of die batch-ontleder die persenttekens verander het voordat die HTTP-kliënt die URL ontvang het.

Daar is twee afsonderlike voorstellings. URL-enkodering kan 'n terugskuinsstreep as %5C en 'n vraagteken as %3F voorstel. 'n Letterlike persentteken in 'n batchlêer-opdrag moet as %% ontsnap word.

Vir 'n illustratiewe rekening domain\user met die plekhouerwagwoord pass?, kan 'n .bat-lêer die volgende bevat:

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

Die proses wat daarna gelanseer word, behoort 'n URL te ontvang wat domain%5Cuser:pass%3F bevat. Die verdubbelde persenttekens behoort aan die batch-bron, nie aan die proxy-URL wat die kliënt stoor nie.

Moenie daardie batch-spelling in 'n .npmrc-lêer of 'n toepassing se proxyveld kopieer nie: daardie insette gaan nie deur dieselfde batch-ontledingstap nie. Net so is hierdie voorbeeld nie PowerShell-sintaks nie. 'n Ander omhulsel, soos CALL of 'n opdrag wat vir 'n tweede dop gebou is, kan nog 'n ontledingsronde invoer en het sy eie hersiening nodig.

Plaas die SET-toekenning tussen aanhalingstekens soos getoon, sodat toevallige spasies of dop-metatekens nie deel van 'n onbedoelde opdrag word nie. Aanhalingstekens alleen verhoed nie persentuitbreiding nie.

Wanneer die resultaat gekontroleer word, vergelyk die verwagte enkodering met 'n geredigeerde voorstelling eerder as om die wagwoordbevattende URL na 'n gedeelde log te druk. 'n Herstel van dop-ontsnapping bewaar die aanmeldingsdata; dit kies nie 'n verifikasieskema wat die kliënt nie reeds ondersteun het nie.