Во постара HttpClient 4.2.2 апликација, добавувачот на акредитиви и кешот за автентикација вршат различни работи. Добавувачот ја дава сметката; кешот му овозможува на намерно однапред конфигурираната шема за автентикација да учествува пред да пристигне следниот предизвик.

За стариот конструктор BasicScheme специфичен за прокси, предавањето изгледа вака:

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

Овој фрагмент претпоставува дека client веќе ја има соодветната прокси рута и добавувачот на акредитиви. proxy е неговиот HttpHost, а request е вистинската операција. Клучот на кешот мора да го опише тој посредник, а не целната веб-страница.

Предајте го пополнетиот контекст на execute. Ако го изградите и потоа користите преоптоварување што создава друг контекст, кешот останува надвор од размената. За подоцнежните операции што треба да го делат тоа автентикациско состојба, задржете го соодветниот контекст наместо секој пат да градите нов празен.

Експлицитната состојба PROXY припаѓа на овој постар API. TARGET се однесува на автентикацијата на целта. Новоте генерации на HttpClient ги променија пакетите и API-то за автентикација, затоа користете го ова како упатство за одржување на постоечкиот код 4.2, а не како рецепт за нов client.

Нормалната размена водена од предизвик сè уште може да биде точна. Засејте Basic автентикација само за познато и предвидено прокси, и потрошете или ослободете го секој одговор пред следната операција да ја побара неговата врска. Корисниот резултат е сметка и кеширана шема поврзани со извршувањето што го испраќа барањето.

Поврзани статии