Git-ის proxyAuthMethod-ს პროქსის მომხმარებლის სახელი სჭირდება

თქვენ ამატებთ http.proxyAuthMethod-ს, ხელახლა ცდილობთ კლონირებას და კვლავ ხედავთ 407-ს. პარამეტრს აქვს დოკუმენტირებული პირობა, რომლის გამოტოვება ადვილია: კონფიგურირებული პროქსის სტრიქონი უნდა შეიცავდეს მომხმარებლის სახელს.

მომხმარებლის სახელს URL-ში არ სჭირდება პაროლის ლიტერატურული თანხლება. Git-ს შეუძლია დაკარგული პაროლი მიიღოს საკუთარი სერტიფიკატების მექანიზმით. მარშრუტიზაციის იდენტობა და ავთენტიფიკაციის მეთოდი კვლავ უნდა მიუთითებდეს სასურველ პროქსიზე.

ოთხი შეყვანა ერთად შეამოწმეთ

1. მოქმედი პროქსის URI, პაროლის გარეშე.
2. ამ პროქსისთვის არჩეული მეთოდი.
3. ნებისმიერი per-remote გადაფარვა ან GIT_HTTP_PROXY_AUTHMETHOD გარემოს გადაფარვა.
4. Git-ის ვერსია და მისი HTTP backend-ის შესაძლებლობები.

ამჟამინდელი Git ადოკუმენტირებს მეთოდებს, მათ შორის anyauth, Basic, Digest, Negotiate და NTLM. ერთის არჩევა არ ამატებს დაკარგულ მხარდაჭერას დაკავშირებულ backend-ს. კორპორატიულმა ადმინისტრატორმაც არ უნდა შეასუსტოს პროქსის პოლიტიკა მხოლოდ იმიტომ, რომ კლიენტი სხვა მეთოდზეა კონფიგურირებული.

ძველი მოხსენებები მოიცავს ვერსიებს, რომლებმაც არ განახორციელეს კოპირებული ოპცია. თვითნებური კონფიგურაციის გასაღების შენახვა შესაძლებელია იმის მტკიცების გარეშე, რომ მიმდინარე გადაცემა მას იყენებს. წაიკითხეთ ვერსიის შესაბამისი დოკუმენტაცია და რედაქტირებული გაცვლა.

ბოლოს, რეპოზიტორიის სერტიფიკატები უფრო გვიანდელი კავშირია. Git ჰოსტინგის ტოკენი არ აკმაყოფილებს პროქსის გამოწვევას. რეპოზიტორიის TLS შემოწმების გამორთვა ასევე არ აიძულებს პროქსის მიიღოს არჩეული ავთენტიფიკაციის სქემა. ჯერ დაადასტურეთ ეს გაცვლა, შემდეგ დაადგინეთ ნებისმიერი მომდევნო რეპოზიტორიის პასუხი.