ব্যবহারযোগ্য Proxy-Authenticate চ্যালেঞ্জ ছাড়া HTTP 407

শুধু একটি স্ট্যাটাস নম্বর থেকে ক্লায়েন্ট প্রমাণীকরণ প্রক্রিয়া বেছে নিতে পারে না। প্রক্সির প্রতিক্রিয়ায় বর্ণনা থাকতে হবে যে এটি কী গ্রহণ করে।

HTTP-তে 407 তৈরি করা প্রক্সিকে Proxy-Authenticate চ্যালেঞ্জ পাঠাতে হয়। Basic পরিষেবার জন্য একটি সহজ উদাহরণ:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

সাংখ্যিক স্ট্যাটাস, হেডারের নাম এবং স্কিম-নির্দিষ্ট বাক্য গঠন—সবই গুরুত্বপূর্ণ। বডিতে authentication শব্দযুক্ত কোনো ব্র্যান্ডেড ত্রুটি পৃষ্ঠা হেডারের বিকল্প নয়। কাস্টম বাস্তবায়নকেও হেডার সমাপ্তিকারী ও বডি ফ্রেমিংসহ সম্পূর্ণ HTTP 407 প্রতিক্রিয়া পাঠাতে হবে।

এই ক্লায়েন্টের কাছে পৌঁছানো প্রতিক্রিয়া পরীক্ষা করুন

গোপন মান সরিয়ে স্ট্যাটাস ও চ্যালেঞ্জ ক্ষেত্রগুলি ধারণ করুন। কোনো মধ্যস্থতাকারী প্রতিক্রিয়াটি রূপান্তরিত করে থাকতে পারে, বা কাস্টম প্রক্সি একটি অবৈধ চ্যালেঞ্জ তৈরি করে থাকতে পারে। সেই প্রমাণ প্রক্সির নিজস্ব লেনদেন লগের সঙ্গে তুলনা করুন।

পরিষেবাটি যদি এর বদলে 405 বা অন্য ত্রুটি পাঠায়, তবে কাস্টম ক্লায়েন্টের ভেতরে এমন প্রতিটি প্রতিক্রিয়াকে 407 হিসেবে পুনরায় লেবেল করবেন না। তাহলে আপনি প্রকৃত পদ্ধতি-নীতির ব্যর্থতা লুকাবেন এবং তবুও নির্ভরযোগ্য স্কিম আলোচনা পাবেন না। পরিষেবার আচরণ ঠিক করুন বা তার নথিভুক্ত সমর্থিত প্রমাণীকরণ পথ ব্যবহার করুন।

একাধিক চ্যালেঞ্জের জন্যও প্রকৃত HTTP পার্সার দরকার। একটি কমা প্যারামিটার বা চ্যালেঞ্জ আলাদা করতে পারে; সম্পূর্ণ হেডারকে অন্ধভাবে কমায় ভাগ করলে উদ্ধৃত realm নষ্ট হতে পারে। ধারাবাহিক স্ট্রিং প্রতিস্থাপনের বদলে ক্লায়েন্টের সমর্থিত প্রমাণীকরণ বাস্তবায়ন ব্যবহার করুন।

চ্যালেঞ্জটি ব্যবহারযোগ্য হওয়ার পরেই কেবল ক্রেডেনশিয়াল সরবরাহকারী কেন কোনো অ্যাকাউন্ট ফেরত দেয়নি তা তদন্ত করা অর্থবহ।