Num aplicativo legado com HttpClient 4.2.2, o provedor de credenciais e o cache de autenticação fazem trabalhos diferentes. O provedor fornece a conta; o cache permite que um esquema de autenticação configurado deliberadamente de antemão participe antes que outro desafio chegue.

Para o antigo construtor BasicScheme específico do proxy, a transferência é assim:

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 trecho pressupõe que client já tenha a rota de proxy correspondente e o provedor de credenciais. proxy é o seu HttpHost, e request é a operação real. A chave do cache deve descrever esse intermediário, não o site de destino.

Passe o contexto preenchido para execute. Construí-lo e depois usar uma sobrecarga que cria outro contexto deixa o cache fora da troca. Para operações posteriores que devem compartilhar esse estado de autenticação, mantenha o contexto adequado em vez de reconstruir um vazio a cada vez.

O estado PROXY explícito pertence a esta API mais antiga. TARGET diz respeito à autenticação do destino. Gerações mais recentes do HttpClient mudaram pacotes e APIs de autenticação, então use isto como orientação de manutenção para código 4.2 existente e não como receita para um novo client.

Uma troca normal conduzida por desafio ainda pode estar correta. Semear autenticação Basic apenas para um proxy conhecido e pretendido, e consumir ou liberar cada resposta antes que a próxima operação precise da conexão. O resultado útil é uma conta e um esquema em cache ligados à execução que realmente envia a requisição.

Artigos relacionados