Azure Storage Java: API ও টোকেন অনুরোধের জন্য প্রক্সি রুট

স্টোরেজ ক্লায়েন্টের HTTP পরিবহনে প্রক্সি কনফিগার করলে একটি প্রশ্নের উত্তর মেলে: ওই পরিবহন কীভাবে স্টোরেজ অনুরোধ পাঠায়। একটি পরিচয় ক্রেডেনশিয়ালের টোকেন পেতে অন্য একটি HTTP ক্লায়েন্ট থাকতে পারে।

এই পার্থক্যই একটি সাধারণ-দেখতে বিক্ষোভের ব্যাখ্যা দেয়: স্টোরেজ এন্ডপয়েন্ট প্রক্সি দিয়ে পৌঁছানো যায়, কিন্তু SDK প্রত্যাশিত অপারেশন পাঠানোর আগেই ব্যর্থ হয়। ব্যর্থতাটি পরিচয় এন্ডপয়েন্টের বিরুদ্ধে ক্রেডেনশিয়াল আহরণের হতে পারে।

প্রথমে লিখে রাখুন কোন গন্তব্য ব্যর্থ হয়েছে। তারপর স্টোরেজ বিল্ডারকে দেওয়া HTTP ক্লায়েন্ট এবং ক্রেডেনশিয়াল বাস্তবায়ন যে কনফিগারেশন ব্যবহার করে তা পরীক্ষা করুন। প্রতিটি পরিবহনের সমর্থিত প্রক্সি অপশন অনুসরণ করুন। অনুমোদিত পাবলিক প্রক্সি রুটে সর্বজনীনভাবে পৌঁছানো যায় এমন স্টোরেজ ও টোকেন এন্ডপয়েন্টের জন্য HTTP প্রক্সি তালিকা এন্ডপয়েন্ট প্রার্থী দেয়; ধরে নেবেন না যে একটি বিল্ডারের সেটিং অ্যাপ্লিকেশনের প্রতিটি বস্তু পুনরায় কনফিগার করে।

প্রক্সি অ্যাকাউন্ট Azure ক্রেডেনশিয়াল থেকে আলাদা রাখুন। সফল প্রক্সি লগইন একটি রুট দেয়; গন্তব্য পরিষেবা এখনও Azure অপারেশন অনুমোদন করে।

ঐতিহাসিক উত্তরগুলিতে Azure Storage Java ক্লাসের কয়েকটি প্রজন্ম ব্যবহৃত হয়, যার মধ্যে পুরোনো OperationContext ও পাইপলাইন API রয়েছে। উদাহরণটি অ্যাপ্লিকেশন এখন যে SDK ও HTTP পরিবহন ব্যবহার করে তার সঙ্গে মিলিয়ে নিন। Data Lake SDK-র জন্য স্টোরেজ ও পরিচয়ের জন্য ভাগ করা HTTP ক্লায়েন্ট সেটআপ দুটি বিল্ডার ইনপুটই দেখায়। প্রক্সি সমস্যা সমাধানে অচল ক্লায়েন্ট ধরন আবার আনা ডিবাগ করার আরেকটি কনফিগারেশন পথ তৈরি করে।

লগে নিরাপদ এন্ডপয়েন্ট শনাক্তকারী ব্যবহার করুন। স্টোরেজ URL-এ অ্যাক্সেস টোকেন থাকতে পারে, আর সম্পূর্ণ প্রক্সি URL-এ পাসওয়ার্ড থাকতে পারে।