Git proxyAuthMethod изисква потребителско име за прокси

Проверете потребителското име за прокси, избрания метод, замяната от средата и версията на Git, когато настройка proxyAuthMethod изглежда неефективна.

Добавяте http.proxyAuthMethod, опитвате клонирането отново и все още виждате 407. Настройката има документирано условие, което лесно се пропуска: конфигурираният низ за прокси трябва да съдържа потребителско име.

Потребителското име не е длъжно да е придружено от буквална парола в URL адреса. Git може да получи липсваща парола чрез механизма си за идентификационни данни. Идентичността за маршрутизиране и методът за удостоверяване все още трябва да сочат към предвиденото прокси.

Прегледайте четири входа заедно

  1. Действащият URI на проксито, с премахната парола.
  2. Избраният метод за това прокси.
  3. Всяка замяна за отделен remote или замяна на GIT_HTTP_PROXY_AUTHMETHOD от средата.
  4. Версията на Git и възможностите на неговия HTTP бекенд.

Текущият Git документира методи, включително anyauth, Basic, Digest, Negotiate и NTLM. Изборът на един не добавя липсваща поддръжка към свързания бекенд. Администратор в корпорация също не бива да отслабва политиката на проксито, защото клиент е настроен за друг метод.

По-стари съобщения включват версии, които не са реализирали копираната опция. Произволен конфигурационен ключ може да бъде запазен без доказателство, че текущият трансфер го използва. Прочетете документацията за съответната версия и редактирания обмен.

И накрая, идентификационните данни за хранилището са по-късна връзка. Токен за Git хостинг не удовлетворява предизвикателството на проксито. Изключването на TLS проверката на хранилището също не кара проксито да приеме избраната схема за удостоверяване. Първо установете този обмен, след това диагностицирайте всеки отговор от хранилището, който последва.

Подобни статии