Հին HttpClient 4.2.2 հավելվածում հավատարմագրերի մատակարարը և նույնականացման քեշը տարբեր աշխատանքներ են կատարում։ Մատակարարը տալիս է հաշիվը. քեշը թույլ է տալիս դիտավորյալ նախապես կարգավորված նույնականացման սխեմային մասնակցել մինչև հաջորդ մարտահրավերի գալը։

Հին proxy-հատուկ 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 երթուղին և հավատարմագրերի մատակարարը։ proxy-ն նրա HttpHost-ն է, իսկ request-ը՝ իրական գործողությունը։ Քեշի բանալին պետք է նկարագրի այդ միջնորդին, ոչ թե նպատակակետ կայքը։

Լրացված կոնտեքստը փոխանցեք execute-ին։ Այն կառուցելուց հետո մեկ այլ կոնտեքստ ստեղծող ծանրաբեռնված օգտագործելը քեշը թողնում է փոխանակումից դուրս։ Հետագա գործողությունների համար, որոնք պետք է կիսեն այդ նույնականացման վիճակը, պահեք համապատասխան կոնտեքստը՝ ամեն անգամ դատարկը վերակառուցելու փոխարեն։

Հստակ PROXY վիճակը պատկանում է այս ավելի հին API-ին։ TARGET-ը վերաբերում է նպատակակետի նույնականացմանը։ Նոր HttpClient սերունդները փոխել են փաթեթներն ու նույնականացման API-ները, ուստի սա օգտագործեք որպես գոյություն ունեցող 4.2 կոդի սպասարկման ուղեցույց, ոչ որպես նոր client-ի բաղադրատոմս։

Սովորական մարտահրավերով ղեկավարվող փոխանակումը դեռ կարող է ճիշտ լինել։ Basic նույնականացումը սերմանեք միայն հայտնի և նախատեսված proxy-ի համար, և սպառեք կամ ազատեք յուրաքանչյուր պատասխան նախքան հաջորդ գործողությանը դրա կապը պետք գալը։ Օգտակար արդյունքը հաշիվն ու քեշավորված սխեման է, որը կապված է այն կատարմանը, որն իրականում ուղարկում է հարցումը։

Առնչվող հոդվածներ