Git-ի proxyAuthMethod-ին անհրաժեշտ է պրոքսիի օգտանուն
Ստուգեք պրոքսիի օգտանունը, ընտրված մեթոդը, միջավայրի վերագրանցումը և Git-ի տարբերակը, երբ proxyAuthMethod կարգավորումն անարդյունավետ է թվում։
Դուք ավելացնում եք http.proxyAuthMethod, կրկին փորձում կլոնավորել և դեռ տեսնում 407։ Կարգավորումն ունի փաստաթղթավորված պայման, որը հեշտ է բաց թողնել՝ կարգավորված պրոքսիի տողը պետք է պարունակի օգտանուն։
Օգտանունը պարտադիր չէ, որ URL-ում ուղեկցվի բառացի գաղտնաբառով։ Git-ը կարող է բացակայող գաղտնաբառը ձեռք բերել իր հավատարմագրերի մեխանիզմով։ Երթուղային ինքնությունը և նույնականացման մեթոդը դեռ պետք է վերաբերեն նախատեսված պրոքսիին։
Միասին ուսումնասիրեք չորս մուտքագրում
- Գործող պրոքսիի URI-ն՝ առանց գաղտնաբառի։
- Այդ պրոքսիի համար ընտրված մեթոդը։
- Ցանկացած per-remote վերագրանցում կամ
GIT_HTTP_PROXY_AUTHMETHODմիջավայրի վերագրանցում։ - Git-ի տարբերակը և նրա HTTP backend-ի հնարավորությունները։
Ընթացիկ Git-ը փաստաթղթավորում է մեթոդներ, ներառյալ anyauth, Basic, Digest, Negotiate և NTLM։ Մեկն ընտրելը չի ավելացնում բացակայող աջակցությունը կապված backend-ին։ Կորպորատիվ ադմինիստրատորն էլ չպետք է թուլացնի պրոքսիի քաղաքականությունը, որովհետև հաճախորդը կարգավորված է այլ մեթոդի համար։
Ավելի հին հաղորդումները ներառում են տարբերակներ, որոնք չեն իրականացրել պատճենվող ընտրանքը։ Ցանկացած կամայական կարգավորման բանալի կարելի է պահել առանց ապացույցի, որ ընթացիկ փոխանցումն օգտագործում է այն։ Կարդացեք տարբերակին համապատասխան փաստաթղթերը և խմբագրված փոխանակումը։
Վերջապես, պահոցի հավատարմագրերը ավելի ուշ հարաբերություն են։ Git հոսթինգի թոքենը չի բավարարում պրոքսիի մարտահրավերը։ Պահոցի TLS ստուգման անջատումը նույնպես չի ստիպում պրոքսիին ընդունել ընտրված նույնականացման սխեման։ Նախ հաստատեք այդ փոխանակումը, ապա ախտորոշեք դրան հաջորդող ցանկացած պահոցի պատասխան։