Katika programu ya zamani ya HttpClient 4.2.2, mtoa vyeti na akiba ya uthibitishaji hufanya kazi tofauti. Mtoaji hutoa akaunti; akiba huruhusu mpango wa uthibitishaji ulioandaliwa kimakusudi mapema kushiriki kabla changamoto nyingine haijafika.

Kwa kijenzi cha zamani cha BasicScheme kinachohusika na proksi, uhamishaji unaonekana hivi:

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

Kipande hiki hudhani kuwa client tayari ana njia inayolingana ya proksi na mtoa vyeti. proxy ni HttpHost yake, na request ni operesheni halisi. Ufunguo wa akiba lazima ueleze mpatanishi huyo, sio tovuti lengwa.

Pitisha muktadha uliojazwa kwa execute. Kuujenga kisha kutumia upakiaji wa ziada unaounda muktadha mwingine huacha akiba nje ya mabadilishano. Kwa operesheni zinazofuata zinazopaswa kushirikiana hali hiyo ya uthibitishaji, weka muktadha unaofaa badala ya kuunda upya tupu kila wakati.

Hali ya wazi ya PROXY ni ya API hii ya zamani. TARGET inahusika na uthibitishaji wa lengo. Vizazi vipya vya HttpClient vimebadilisha vifurushi na API za uthibitishaji, kwa hivyo tumia hii kama mwongozo wa matengenezo kwa msimbo uliopo wa 4.2, sio kama mapishi ya client mpya.

Mabadilishano ya kawaida yanayoendeshwa na changamoto bado yanaweza kuwa sahihi. Panda uthibitishaji wa Basic kwa proksi inayojulikana na inayokusudiwa pekee, na tumia au toa kila jibu kabla operesheni inayofuata haijahitaji muunganisho wake. Matokeo yenye manufaa ni akaunti na mpango uliohifadhiwa unaohusishwa na utekelezaji unaotuma ombi kwa kweli.

Makala zinazohusiana