Apache HttpClient 4.2: অনুৰোধ প্ৰসংগত প্ৰক্সি AuthCache ৰাখক

পুৰণি HttpClient 4.2.2 এপ্লিকেচনত credential provider আৰু authentication cache-এ বেলেগ বেলেগ কাম কৰে। Provider-এ একাউণ্ট যোগান ধৰে; cache-এ ইচ্ছাকৃতভাৱে পূৰ্বতে সজোৱা authentication scheme-ক আন এটা challenge অহাৰ আগতে অংশগ্ৰহণ কৰিব দিয়ে।

পুৰণি প্ৰক্সি-নিৰ্দিষ্ট BasicScheme constructor-ৰ বাবে হস্তান্তৰ এনেকুৱা দেখা যায়:

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

এই fragment-এ ধৰি লয় যে client-ৰ ওচৰত ইতিমধ্যে মিল থকা প্ৰক্সি ৰুট আৰু credential provider আছে। proxy হৈছে তাৰ HttpHost, আৰু request হৈছে প্ৰকৃত কাৰ্য। cache key-এ সেই মধ্যৱৰ্তীটো বৰ্ণনা কৰিব লাগে, গন্তব্য ৱেবছাইট নহয়।

ভৰোৱা context-টো execute-লৈ পঠিয়াওক। ইয়াক সাজি তাৰ পিছত আন এটা context সৃষ্টি কৰা overload ব্যৱহাৰ কৰিলে cache-টো বিনিময়ৰ বাহিৰত থাকি যায়। সেই authentication অৱস্থা ভাগ কৰিবলৈ ইচ্ছা কৰা পৰৱৰ্তী কাৰ্যৰ বাবে প্ৰতিবাৰে খালী context পুনৰ নিৰ্মাণ নকৰি উপযুক্ত context-টো ৰাখক।

স্পষ্ট PROXY অৱস্থাটো এই পুৰণি API-ৰ। TARGET-এ গন্তব্যৰ authentication সূচায়। নতুন HttpClient প্ৰজন্মই package আৰু authentication API সলনি কৰিছে, গতিকে ইয়াক বিদ্যমান 4.2 ক'ডৰ ৰক্ষণাবেক্ষণৰ নির্দেশনা হিচাপে ব্যৱহাৰ কৰক, নতুন client-ৰ ৰেচিপি হিচাপে নহয়।

স্বাভাৱিক challenge-চালিত বিনিময় এতিয়াও শুদ্ধ হ'ব পাৰে। কেৱল জনা আৰু ইচ্ছাকৃত প্ৰক্সিৰ বাবেহে Basic authentication ৰোপণ কৰক, আৰু পৰৱৰ্তী কাৰ্যই ইয়াৰ সংযোগ বিচৰাৰ আগতে প্ৰতিটো response খৰচ কৰক বা এৰি দিয়ক। উপযোগী ফলাফল হৈছে অনুৰোধ প্ৰকৃততে পঠিওৱা execution-ৰ সৈতে সংযুক্ত একাউণ্ট আৰু কেশ্ব কৰা scheme।