Nunha aplicación antiga con HttpClient 4.2.2, o provedor de credenciais e a caché de autenticación fan traballos distintos. O provedor fornece a conta; a caché permite que un esquema de autenticación configurado a propósito participe antes de que chegue outro desafío.

Para o antigo construtor BasicScheme específico do proxy, a entrega é así:

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

Este fragmento supón que client xa ten a ruta de proxy correspondente e o provedor de credenciais. proxy é o seu HttpHost, e request é a operación real. A clave da caché debe describir ese intermediario, non o sitio web de destino.

Pase o contexto xa cheo a execute. Construílo e despois usar unha sobrecarga que crea outro contexto deixa a caché fóra do intercambio. Para operacións posteriores que deban compartir ese estado de autenticación, conserve o contexto axeitado en lugar de reconstruír un baleiro cada vez.

O estado PROXY explícito pertence a esta API máis antiga. TARGET refírese á autenticación do destino. As xeracións máis recentes de HttpClient cambiaron paquetes e API de autenticación, así que use isto como guía de mantemento para código 4.2 existente e non como receita para un cliente novo.

Un intercambio normal impulsado por desafío pode seguir sendo correcto. Sementa a autenticación Basic só para un proxy coñecido e previsto, e consuma ou libere cada resposta antes de que a seguinte operación necesite a súa conexión. O resultado útil é unha conta e un esquema en caché ligados á execución que realmente envía a petición.

Artigos relacionados