Ve starší aplikaci s HttpClient 4.2.2 dělají poskytovatel přihlašovacích údajů a cache ověřování různé úlohy. Poskytovatel dodává účet; cache umožňuje záměrně předem nastavenému schématu ověřování zapojit se dřív, než dorazí další výzva.

U starého konstruktoru BasicScheme specifického pro proxy vypadá předání takto:

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

Tento fragment předpokládá, že client už má odpovídající trasu přes proxy a poskytovatele přihlašovacích údajů. proxy je jeho HttpHost a request je skutečná operace. Klíč cache musí popisovat tento prostředník, ne cílový web.

Předejte naplněný kontext do execute. Když ho sestavíte a pak použijete přetížení, které vytvoří jiný kontext, cache zůstane mimo výměnu. Pro další operace, které mají tento stav ověřování sdílet, si podržte příslušný kontext, místo abyste pokaždé vytvářeli prázdný.

Explicitní stav PROXY patří tomuto staršímu API. TARGET se týká ověřování cíle. Novější generace HttpClientu změnily balíčky i API ověřování, takže to berte jako pokyn k údržbě stávajícího kódu 4.2, ne jako recept pro nového klienta.

Běžná výměna řízená výzvou může být stále správná. Zasévejte Basic ověřování jen pro známý zamýšlený proxy a každou odpověď spotřebujte nebo uvolněte dřív, než další operace potřebuje její spojení. Užitečným výsledkem je účet a cachované schéma připojené k provádění, které požadavek skutečně odesílá.

Související články