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 рэпазіторыя таксама не прымушае проксі прыняць выбраную схему аўтэнтыфікацыі. Спачатку ўстанавіце гэты абмен, затым дыягнастуйце любую адказ рэпазіторыя, які ідзе следам.