I en eldre HttpClient 4.2.2-applikasjon gjør en credential-provider og en autentiseringscache forskjellige jobber. Provideren leverer kontoen; cachen lar et bevisst forhåndskonfigurert autentiseringsskjema delta før en ny utfordring ankommer.

For den gamle proxy-spesifikke BasicScheme-konstruktøren ser overleveringen slik ut:

AuthCache cache = new BasicAuthCache();
cache.put(proxy, new BasicScheme(ChallengeState.PROXY));

HttpContext context = new BasicHttpContext();
context.setAttribute(ClientContext.AUTH_CACHE, cache);
HttpResponse response = client.execute(request, context);

Dette utdraget forutsetter at client allerede har den matchende proxy-ruten og credential-provideren. proxy er dens HttpHost, og request er den faktiske operasjonen. Cache-nøkkelen må beskrive det mellomleddet, ikke nettstedet for destinasjonen.

Send den fylte konteksten til execute. Å bygge den og deretter bruke en overbelastning som lager en annen kontekst, lar cachen stå utenfor utvekslingen. For senere operasjoner som skal dele denne autentiseringstilstanden, behold den aktuelle konteksten i stedet for å bygge en tom på nytt hver gang.

Den eksplisitte PROXY-tilstanden hører til denne eldre API-en. TARGET gjelder autentisering av destinasjonen. Nyere HttpClient-generasjoner har endret pakker og autentiserings-API-er, så bruk dette som vedlikeholdsveiledning for eksisterende 4.2-kode og ikke som oppskrift for en ny klient.

En vanlig utfordringsstyrt utveksling kan fortsatt være korrekt. Seed Basic-autentisering bare for en kjent og tiltenkt proxy, og forbruk eller frigjør hvert svar før neste operasjon trenger tilkoblingen. Det nyttige resultatet er en konto og et bufret skjema knyttet til utførelsen som faktisk sender forespørselen.

Relaterte artikler