Në një aplikacion të vjetër HttpClient 4.2.2, ofruesi i kredencialeve dhe cache-i i vërtetimit bëjnë punë të ndryshme. Ofruesi furnizon llogarinë; cache-i lejon një skemë vërtetimi të konfiguruar qëllimisht paraprakisht të marrë pjesë përpara se të mbërrijë një sfidë tjetër.

Për konstruktorin e vjetër BasicScheme specifik për proxy-n, dorëzimi duket kështu:

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);

Ky fragment supozon se client tashmë ka rrugën përkatëse të proxy-t dhe ofruesin e kredencialeve. proxy është HttpHost-i i tij, dhe request është operacioni aktual. Çelësi i cache-it duhet të përshkruajë atë ndërmjetës, jo faqen e destinacionit.

Kalo kontekstin e plotësuar te execute. Ndërtimi i tij dhe më pas përdorimi i një mbingarkese që krijon një kontekst tjetër e lë cache-in jashtë shkëmbimit. Për operacionet pasuese që duhet të ndajnë atë gjendje vërtetimi, mbaj kontekstin e duhur në vend që të rindërtosh një bosh çdo herë.

Gjendja e qartë PROXY i përket këtij API më të vjetër. TARGET ka të bëjë me vërtetimin e destinacionit. Gjeneratat më të reja të HttpClient ndryshuan paketat dhe API-t e vërtetimit, prandaj përdore këtë si udhëzim mirëmbajtjeje për kodin ekzistues 4.2, jo si recetë për një client të re.

Një shkëmbim normal i drejtuar nga sfida mund të jetë ende i saktë. Mbill vërtetimin Basic vetëm për një proxy të njohur dhe të synuar, dhe konsumo ose lësho çdo përgjigje përpara se operacioni tjetër të ketë nevojë për lidhjen e saj. Rezultati i dobishëm është një llogari dhe një skemë e ruajtur në cache të lidhura me ekzekutimin që dërgon vërtet kërkesën.

Artikuj të ngjashëm