Eit rett passord hos leverandøren etablerer ikkje legitimasjon som passar til proxyen som faktisk er vald. Start med skjemaet, verten og porten til det endepunktet; eit vertsfelt tek vanlegvis berre eit vertsnamn eller ein IP, ikkje ein full URL.

  1. Les heile autentiseringsutvekslinga. Ein 407 følgd av eit godteke nytt forsøk kan vere normalt. Stadfest at sluttresultatet framleis er 407 før du handsamar innlogginga som avvist.
  2. Samanlikn rute og legitimasjonsomfang. Match den faktiske verten/porten og dei andre felta som den utrulla HttpClient 5 AuthScope definerer. Ein feil port kan la BasicCredentialsProvider stå utan ei høveleg oppføring.
  3. Kontroller metode og identitet. Tilbaud proxyen den støtta metoden? Brukte det nye forsøket den venta tilknytinga? Krev operatøren ein domenekvalifisert konto eller eit anna dokumentert format?

Bruk API-et til den installerte hovudversjonen. Ein oppskrift for autentiseringshurtiglager i HttpClient 4 blir ikkje overført uendra til versjon 5. Bruk kontokrava til operatøren i staden for å gå gjennom vilkårlege variantar av brukarnamn.

Førebyggjande autentisering er eit anna medvite val. For eit kompatibelt skjema kan det fjerne ein runde, men det endrar når legitimasjonen forlèt systemet og krev eit støtta omfang. Det kan ikkje vere den første rettinga for eit endepunkt som ikkje passar eller ein metode som ikkje er støtta.

Hald den utfordra proxy-identiteten, metoden, omfangssamsvaret og sluttstatusen i redigerte diagnostikkdata. Passordet og rå spor som ber legitimasjon, er unødvendige for den samanlikninga.

Relaterte artiklar