In un'applicazione legacy con HttpClient 4.2.2, il provider di credenziali e la cache di autenticazione svolgono compiti diversi. Il provider fornisce l'account; la cache consente a uno schema di autenticazione configurato di proposito in anticipo di partecipare prima che arrivi un'altra richiesta di autenticazione.

Per il vecchio costruttore BasicScheme specifico del proxy, il passaggio è questo:

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

Questo frammento presuppone che client abbia già la rotta proxy corrispondente e il provider di credenziali. proxy è il suo HttpHost, e request è l'operazione reale. La chiave della cache deve descrivere quell'intermediario, non il sito di destinazione.

Passate il contesto popolato a execute. Costruirlo e poi usare un overload che crea un altro contesto lascia la cache fuori dallo scambio. Per le operazioni successive che devono condividere quello stato di autenticazione, conservate il contesto adatto invece di ricostruirne uno vuoto ogni volta.

Lo stato PROXY esplicito appartiene a questa API più vecchia. TARGET riguarda l'autenticazione della destinazione. Le generazioni più recenti di HttpClient hanno cambiato pacchetti e API di autenticazione, quindi usate questo come guida di manutenzione per codice 4.2 esistente e non come ricetta per un nuovo client.

Uno scambio normale guidato da una richiesta di autenticazione può comunque essere corretto. Seminate l'autenticazione Basic solo per un proxy noto e voluto, e consumate o rilasciate ogni risposta prima che l'operazione successiva abbia bisogno della sua connessione. Il risultato utile è un account e uno schema in cache legati all'esecuzione che invia davvero la richiesta.

Articoli correlati