proxyAuthMethod de Git exige un nom d'utilisateur de proxy

Vérifiez le nom d'utilisateur du proxy, la méthode retenue, la surcharge d'environnement et la version de Git lorsqu'un réglage proxyAuthMethod semble sans effet.

Vous ajoutez http.proxyAuthMethod, relancez le clone et voyez toujours 407. Le réglage a une condition documentée facile à manquer : la chaîne de proxy configurée doit contenir un nom d'utilisateur.

Le nom d'utilisateur n'a pas besoin d'être accompagné d'un mot de passe littéral dans l'URL. Git peut obtenir un mot de passe manquant via son mécanisme d'identifiants. L'identité de routage et la méthode d'authentification doivent néanmoins viser le proxy prévu.

Examinez quatre entrées ensemble

  1. L'URI effective du proxy, mot de passe retiré.
  2. La méthode retenue pour ce proxy.
  3. Toute surcharge par remote ou la surcharge d'environnement GIT_HTTP_PROXY_AUTHMETHOD.
  4. La version de Git et les capacités de son backend HTTP.

Git actuel documente des méthodes telles que anyauth, Basic, Digest, Negotiate et NTLM. En choisir une n'ajoute pas la prise en charge manquante au backend lié. Un administrateur d'entreprise ne devrait pas non plus affaiblir la politique du proxy parce qu'un client a été configuré pour une autre méthode.

Les anciens signalements concernent des versions qui n'implémentaient pas l'option copiée. Une clé de configuration arbitraire peut être stockée sans preuve que le transfert en cours l'utilise. Lisez la documentation de la version concernée et l'échange expurgé.

Enfin, les identifiants du dépôt relèvent d'une relation ultérieure. Un jeton d'hébergement Git ne satisfait pas le défi d'un proxy. Désactiver la vérification TLS du dépôt ne fait pas non plus accepter au proxy le schéma d'authentification choisi. Établissez d'abord cet échange, puis diagnostiquez toute réponse du dépôt qui suit.

Articles similaires