Dodajesz http.proxyAuthMethod, ponawiasz klonowanie i nadal widzisz 407. Ustawienie ma udokumentowany warunek, który łatwo przeoczyć: skonfigurowany ciąg proxy musi zawierać nazwę użytkownika.

Nazwa użytkownika nie musi być w adresie URL opatrzona dosłownym hasłem. Git może uzyskać brakujące hasło przez swój mechanizm poświadczeń. Tożsamość routingu i metoda uwierzytelniania nadal muszą odnosić się do zamierzonego proxy.

Zbadaj cztery dane wejściowe razem

  1. Rzeczywisty URI proxy, bez hasła.
  2. Metoda wybrana dla tego proxy.
  3. Każde nadpisanie dla danego remote lub nadpisanie środowiskowe GIT_HTTP_PROXY_AUTHMETHOD.
  4. Wersja Git i możliwości jej backendu HTTP.

Obecny Git dokumentuje metody, w tym anyauth, Basic, Digest, Negotiate i NTLM. Wybór jednej nie dodaje brakującego wsparcia połączonemu backendowi. Administrator korporacyjny również nie powinien osłabiać polityki proxy tylko dlatego, że klient został skonfigurowany dla innej metody.

Starsze raporty obejmują wersje, które nie implementowały kopiowanej opcji. Dowolny klucz konfiguracji można zapisać bez dowodu, że bieżące przesyłanie go używa. Przeczytaj dokumentację dla danej wersji i zredagowaną wymianę.

Na koniec poświadczenia repozytorium to późniejsza relacja. Token hostingu Git nie zaspokaja wyzwania proxy. Wyłączenie weryfikacji TLS repozytorium również nie sprawia, że proxy akceptuje wybrany schemat uwierzytelniania. Najpierw ustal tę wymianę, a następnie zdiagnozuj każdą następującą odpowiedź repozytorium.

Powiązane artykuły