Git proxyAuthMethod bezonas proksan uzantnomon

Kontrolu la proksan uzantnomon, la elektitan metodon, la medivariadan anstataŭon kaj la Git-version kiam agordo proxyAuthMethod ŝajnas senefika.

Vi aldonas http.proxyAuthMethod, reprovas la klonon kaj ankoraŭ vidas 407. La agordo havas dokumentitan kondiĉon facile pretervideblan: la agordita proksa ĉeno devas enhavi uzantnomon.

La uzantnomo ne devas esti akompanata de laŭvorta pasvorto en la URL. Git povas akiri mankantan pasvorton per sia legitimila mekanismo. La enkursiga identeco kaj la aŭtentiga metodo tamen devas rilati al la celita prokso.

Ekzamenu kvar enigojn kune

  1. La efektiva proksa URI, sen la pasvorto.
  2. La metodo elektita por tiu prokso.
  3. Ajna anstataŭo por unuopa remote aŭ la medivariada anstataŭo GIT_HTTP_PROXY_AUTHMETHOD.
  4. La Git-version kaj la kapabloj de ĝia HTTP malantaŭo.

Nuna Git dokumentas metodojn inkluzive anyauth, Basic, Digest, Negotiate kaj NTLM. Elekti unu ne aldonas mankantan subtenon al la ligita malantaŭo. Nek korporacia administranto devus malfortigi la proksan politikon ĉar kliento estis agordita por alia metodo.

Pli malnovaj raportoj inkluzivas versiojn kiuj ne realigis la kopiatan opcion. Arbitra agorda ŝlosilo povas esti konservita sen pruvo ke la kuranta transigo uzas ĝin. Legu la versiigitan dokumentaron kaj la redaktitan interŝanĝon.

Finfine, deponejaj legitimiloj estas posta rilato. Git-gastiga ĵetono ne kontentigas la defion de prokso. Malŝalti la TLS-kontrolon de la deponejo ankaŭ ne igas la prokson akcepti la elektitan aŭtentigan skemon. Unue establu tiun interŝanĝon, poste diagnozu ajnan deponejan respondon kiu sekvas.

Rilataj artikoloj