Une URL proxy fonctionne lorsqu'elle est configurée directement, mais l'authentification échoue une fois la même valeur déplacée dans un fichier batch Windows. Vérifiez si l'analyseur batch a modifié les signes de pourcentage avant que le client HTTP ait reçu l'URL.

Il existe deux représentations distinctes. L'encodage d'URL peut représenter une barre oblique inverse par %5C et un point d'interrogation par %3F. Un signe de pourcentage littéral dans une commande de fichier batch doit être échappé en %%.

Pour un compte illustratif domain\user avec le mot de passe fictif pass?, un fichier .bat peut contenir :

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

Le processus lancé ensuite doit recevoir une URL contenant domain%5Cuser:pass%3F. Les signes de pourcentage doublés appartiennent à la source batch, non à l'URL proxy stockée par le client.

Ne copiez pas cette graphie batch dans un fichier .npmrc ni dans le champ proxy d'une application : ces entrées ne passent pas par la même étape d'analyse batch. De même, cet exemple n'est pas de la syntaxe PowerShell. Un autre habillage, comme CALL ou une commande construite pour un second shell, peut introduire une passe d'analyse supplémentaire et nécessite sa propre vérification.

Placez l'affectation SET entre guillemets comme indiqué, afin que des espaces fortuits ou des métacaractères du shell ne fassent pas partie d'une commande involontaire. Les guillemets seuls n'empêchent pas l'expansion du pourcentage.

Lors de la vérification du résultat, comparez l'encodage attendu à une représentation expurgée plutôt que d'imprimer l'URL porteuse du mot de passe dans un journal partagé. Une correction d'échappement du shell préserve l'identifiant ; elle ne choisit pas un schéma d'authentification que le client ne prenait pas déjà en charge.

Articles similaires