Gecodeerde proxy-inloggegevens intact houden in een batchbestand

Een proxy-URL werkt wanneer deze rechtstreeks wordt geconfigureerd, maar verificatie mislukt nadat dezelfde waarde naar een Windows-batchbestand is verplaatst. Controleer of de batch-parser de procenttekens heeft gewijzigd voordat de HTTP-client de URL ontving.

Er zijn twee afzonderlijke representaties. URL-codering kan een backslash als %5C en een vraagteken als %3F voorstellen. Een letterlijk procentteken in een batchbestand-opdracht moet als %% worden geëscaped.

Voor een voorbeeldaccount domain\user met het plaatshouderwachtwoord pass? kan een .bat-bestand het volgende bevatten:

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

Het proces dat daarna wordt gestart, hoort een URL te ontvangen die domain%5Cuser:pass%3F bevat. De verdubbelde procenttekens horen bij de batchbron, niet bij de proxy-URL die de client opslaat.

Kopieer die batch-spelling niet naar een .npmrc-bestand of het proxyveld van een toepassing: die invoer gaat niet door dezelfde batch-parseringstap. Evenzo is dit voorbeeld geen PowerShell-syntaxis. Een andere wrapper, zoals CALL of een opdracht die voor een tweede shell is gebouwd, kan een extra parseerronde invoeren en vereist een eigen beoordeling.

Zet de SET-toewijzing tussen aanhalingstekens zoals getoond, zodat toevallige spaties of shell-metatekens geen deel worden van een onbedoelde opdracht. Aanhalingstekens alleen voorkomen de procentexpansie niet.

Vergelijk bij het controleren van het resultaat de verwachte codering met een geredigeerde weergave in plaats van de URL met het wachtwoord naar een gedeeld logboek af te drukken. Een shell-escaping-reparatie behoudt de inloggegevens; ze kiest geen verificatieschema dat de client al niet ondersteunde.