Apache HttpClient 4.2: păstrați AuthCache-ul proxy-ului pe contextul cererii
Păstrați cache-ul Basic-auth al proxy-ului HttpClient 4.2 pe același context de execuție folosit de cererile ulterioare.
Într-o aplicație veche cu HttpClient 4.2.2, furnizorul de credențiale și cache-ul de autentificare fac lucruri diferite. Furnizorul livrează contul; cache-ul permite unei scheme de autentificare configurate intenționat în prealabil să participe înainte de a sosi o altă provocare.
Pentru vechiul constructor BasicScheme specific proxy-ului, predarea arată astfel:
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);Acest fragment presupune că client are deja ruta de proxy potrivită și furnizorul de credențiale. proxy este HttpHost-ul său, iar request este operația reală. Cheia cache-ului trebuie să descrie acel intermediar, nu site-ul destinației.
Transmiteți contextul completat către execute. Construirea lui și apoi folosirea unei supraîncărcări care creează alt context lasă cache-ul în afara schimbului. Pentru operațiile ulterioare care trebuie să partajeze acea stare de autentificare, păstrați contextul potrivit în loc să reconstruiți unul gol de fiecare dată.
Starea PROXY explicită aparține acestei API mai vechi. TARGET privește autentificarea destinației. Generațiile mai noi de HttpClient au schimbat pachetele și API-urile de autentificare, așa că folosiți asta ca îndrumar de întreținere pentru codul 4.2 existent, nu ca rețetă pentru un client nou.
Un schimb normal condus de provocare poate rămâne corect. Semănați autentificarea Basic doar pentru un proxy cunoscut și intenționat, și consumați sau eliberați fiecare răspuns înainte ca operația următoare să aibă nevoie de conexiunea lui. Rezultatul util este un cont și o schemă din cache legate de execuția care trimite efectiv cererea.