Git proxyAuthMethod бара корисничко име за прокси
Проверете го корисничкото име на проксито, избраниот метод, замената од околината и верзијата на Git кога поставката proxyAuthMethod изгледа неефикасна.
Додавате http.proxyAuthMethod, го повторувате клонирањето и сè уште гледате 407. Поставката има документиран услов што лесно се пропушта: конфигурираната низа за прокси мора да содржи корисничко име.
Корисничкото име не мора да биде придружено со буквална лозинка во URL-то. Git може да добие лозинка што недостасува преку својот механизам за акредитиви. Идентитетот за насочување и методот за автентикација сè уште треба да се однесуваат на предвиденото прокси.
Прегледајте четири влезови заедно
- Ефективниот URI на проксито, без лозинката.
- Методот избран за тоа прокси.
- Секоја замена по remote или замената на околината
GIT_HTTP_PROXY_AUTHMETHOD. - Верзијата на Git и можностите на неговиот HTTP backend.
Тековниот Git документира методи вклучувајќи anyauth, Basic, Digest, Negotiate и NTLM. Изборот на еден не додава поддршка што недостасува на поврзаниот backend. Ниту корпоративен администратор не треба да ја ослаби политиката на проксито затоа што клиентот е конфигуриран за друг метод.
Поновите извештаи вклучуваат верзии што не ја имплементирале опцијата што се копира. Произволен конфигурациски клуч може да се зачува без доказ дека тековниот пренос го користи. Прочитајте ја документацијата за соодветната верзија и редактираната размена.
Конечно, акредитивите на складиштето се подоцнежен однос. Токенот за Git хостинг не го задоволува предизвикот на проксито. Исклучувањето на TLS проверката на складиштето исто така не го наведува проксито да ја прифати избраната шема за автентикација. Прво утврдете ја таа размена, потоа дијагностицирајте го секој одговор на складиштето што следи.