প্রক্সি ক্রেডেনশিয়ালে ডোমেইন-যোগ্য ব্যবহারকারীনাম

অস্পষ্ট অ্যাকাউন্ট নামকে পৃথক ডোমেইন ক্ষেত্রযুক্ত API থেকে আলাদা করুন, এবং কেবল URL ব্যাকরণ মেটাতে অ্যাকাউন্ট পরিচয় পরিবর্তন করা এড়িয়ে চলুন।

একটি উত্তর বলে DOMAIN\ সরিয়ে ফেলতে। আরেকটি বলে এটি যোগ করতে। দুটি পরিবর্তনই আপনার প্রক্সির জন্য ভুল হতে পারে।

দুটি প্রশ্ন আছে: পরিষেবাটি কোন পরিচয় আশা করে, এবং নির্বাচিত API সেই পরিচয় কীভাবে উপস্থাপন করে।

ইন্টারফেসকী নিশ্চিত করতে হবে
একক অ্যাকাউন্ট-নাম ক্ষেত্রঅপারেটর যে সঠিক অ্যাকাউন্ট ব্যাকরণ গ্রহণ করে
ডোমেইন ক্ষেত্রযুক্ত ক্রেডেনশিয়াল APIডোমেইন ও ব্যবহারকারীনাম আলাদাভাবে দিতে হবে কি না
URI-এর ভিতরে ক্রেডেনশিয়াল উপাদানউদ্দিষ্ট মানগুলি ওই ধারকের জন্য কীভাবে এনকোড করতে হবে

উদাহরণস্বরূপ, .NET পৃথক ব্যবহারকারীনাম, পাসওয়ার্ড ও ডোমেইন আর্গুমেন্টসহ একটি NetworkCredential কনস্ট্রাক্টর দেয়। ডোমেইনকে বাছবিচার ছাড়া দুটি ক্ষেত্রে রাখা ইন্টিগ্রেটেড প্রমাণীকরণ কনফিগার করার বহনযোগ্য উপায় নয়।

Basic প্রমাণীকরণ আরেকটি ক্ষেত্রে: সার্ভার প্রদত্ত অ্যাকাউন্ট পাঠ্য নিজের নীতিতে ব্যাখ্যা করে। একই নেটওয়ার্কে থাকা ডোমেইন উপসর্গ নিহিত আছে বলে প্রমাণ করে না। আবার ডোমেইন-যোগ্য নাম স্বয়ংক্রিয়ভাবে ভিন্ন প্রমাণীকরণ প্রোটোকলও নয়।

URL এস্কেপিংয়ের উচিত উদ্দিষ্ট অ্যাকাউন্ট সংরক্ষণ করা, তা পরিবর্তন নয়। উৎস-ভাষার স্ট্রিংয়ে ব্যাকস্ল্যাশ, অ্যাকাউন্ট নামে ব্যাকস্ল্যাশ এবং URI-এর ভিতরে তার শতাংশ-এনকোডেড উপস্থাপনা আলাদা স্তর।

অপারেটরের কাছ থেকে গৃহীত পরিচয়-রূপ ও স্কিম নিন, তারপর উপযুক্ত ক্রেডেনশিয়াল ইন্টারফেস ব্যবহার করুন। সংক্ষিপ্ত নাম, ডোমেইন নাম ও ইমেইল-সদৃশ নামের মধ্যে এলোমেলোভাবে পরিবর্তন মূল 407 সম্পর্কে দুর্বল প্রমাণ তৈরি করে।

সম্পর্কিত নিবন্ধ