ইউজারনেম এবং পাসওয়ার্ড থেকে একটি HTTP Basic প্রমাণীকরণ হেডার তৈরি করুন, পেস্ট করার উপযোগী curl কমান্ড পান, এবং একটি বিদ্যমান Basic টোকেন ডিকোড করে ক্রেডেনশিয়ালে ফিরে পান।
একটি HTTP Basic প্রমাণীকরণ হেডার তৈরি করুন, অথবা একটি ডিকোড করুন। ইউজারনেম ও পাসওয়ার্ড লিখুন, Authorization হেডার, raw base64 টোকেন এবং একটি curl কমান্ড পান যা আপনি সরাসরি টার্মিনালে পেস্ট করতে পারেন। নিচের ডিকোডার একটি বিদ্যমান টোকেন বিপরীত করে।
একটি বিদ্যমান টোকেন ডিকোড করুন
সবকিছু আপনার ব্রাউজারে গণনা করা হয় এবং কিছুই প্রেরণ করা হয় না। তবুও, যেকোনো ওয়েব পৃষ্ঠায়, এই পৃষ্ঠাসহ, প্রকৃত প্রোডাকশন ক্রেডেনশিয়াল পেস্ট করা এড়িয়ে চলুন।
HTTP Basic প্রমাণীকরণ আসলে কীভাবে কাজ করে
প্রক্রিয়া
RFC 7617-এ সংজ্ঞায়িত Basic প্রমাণীকরণ, HTTP-তে সবচেয়ে সহজ স্কিম। ক্লায়েন্ট ইউজারনেম ও পাসওয়ার্ডকে কোলন দিয়ে যুক্ত করে, ফলাফল base64 হিসেবে এনকোড করে এবং একটি হেডারে পাঠায়:
Authorization: Basic YWxpY2U6czNjcjN0
যখন একটি সার্ভার ক্রেডেনশিয়াল চায় তখন এটি 401 Unauthorized উত্তর দেয় WWW-Authenticate: Basic realm="..." হেডারসহ, এবং ব্রাউজার তার নেটিভ লগইন ডায়ালগ দেখায়। কোনো হ্যান্ডশেক, ননস বা মেয়াদ শেষ হওয়া নেই — প্রতিটি অনুরোধ একই হেডার বহন করে।
Base64 এনক্রিপশন নয়
এটি সেই বিষয় যা সবাইকে অন্তর্ভুক্ত করতে হবে। Base64 একটি বিপরীতমুখী ট্রান্সপোর্ট এনকোডিং, কোনো কী বা গোপন নেই। যে কেউ হেডার দেখলে তাৎক্ষণিকভাবে ডিকোড করতে পারে, যা এই পৃষ্ঠার ডিকোডার অবিকল করে। তাই Basic অথ নিজে থেকে শূন্য গোপনীয়তা প্রদান করে এবং শুধুমাত্র HTTPS-এ ব্যবহার করা উচিত, যেখানে TLS পুরো অনুরোধ রক্ষা করে। প্লেইন HTTP-তে এটি পাসওয়ার্ড প্লেইন টেক্সটে পাঠানোর সমতুল্য।
কোলন নিয়ম
ইউজারনেমে কোলন থাকতে পারে না, কারণ প্রথম কোলনটি বিভাজক। পাসওয়ার্ডে যত খুশি থাকতে পারে — একটি ডিকোডার প্রথমটিতে ভাগ করে বাকিগুলো পাসওয়ার্ড হিসেবে বিবেচনা করে। যদি আপনার ইউজারনেমে সত্যিই কোলন প্রয়োজন হয়, তবে Basic অথ ব্যবহারযোগ্য নয় এবং আপনার ভিন্ন স্কিম দরকার।
অক্ষর এনকোডিং
মূল স্পেসিফিকেশনটি ASCII-র বাইরের যেকোনো বিষয়ে অস্পষ্ট ছিল, যা ঐতিহাসিকভাবে ক্লায়েন্ট ও সার্ভারের মধ্যে নন-ASCII পাসওয়ার্ড ভাঙার কারণ হয়েছিল। RFC 7617 charset="UTF-8" প্যারামিটার যোগ করেছে যাতে একটি সার্ভার তার প্রত্যাশা জানাতে পারে, এবং বাস্তবে প্রতিটি আধুনিক স্ট্যাক UTF-8 ব্যবহার করে। এই টুলটি base64-এর আগে UTF-8 বাইটে এনকোড করে, বর্তমান ব্রাউজার আচরণের সাথে মিল রেখে।
যেখানে এটি এখনও অর্থবোধক
অভ্যন্তরীণ নেটওয়ার্কে মেশিন-থেকে-মেশিন কল, nginx বা Apache-এর পিছনে স্টেজিং পরিবেশের দ্রুত সুরক্ষা, সহজ ক্রেডেনশিয়াল প্রয়োজন এমন CI কাজ এবং API কী-র পরিবহন — যেখানে কী ইউজারনেম ফিল্ডে যায় এবং পাসওয়ার্ড ফাঁকা রাখা হয় বা x এর মতো প্লেসহোল্ডার সেট করা হয় — এর জন্য Basic অথ একটি যুক্তিসঙ্গত পছন্দ হিসেবে রয়ে গেছে। বেশ কয়েকটি পেমেন্ট ও মেইল API ঠিক এই প্যাটার্ন ব্যবহার করে।
পাবলিক সাইটে শেষ-ব্যবহারকারী লগইনের জন্য এটি একটি খারাপ পছন্দ। কোনো লগআউট নেই, ব্রাউজার সেশনের জন্য ক্রেডেনশিয়াল ক্যাশ করে, ডায়ালগটি স্টাইল করা যায় না, এবং প্রতি-সেশনে মাল্টি-ফ্যাক্টর প্রমাণীকরণ বা রেট লিমিটিং যোগ করার কোনো উপায় নেই। পরিবর্তে টোকেন বা সেশন-ভিত্তিক স্কিম ব্যবহার করুন।
ব্যবহারিক সতর্কতা
URL-এ এমবেড করা ক্রেডেনশিয়াল — user:pass@example.com — অবনমিত এবং বেশিরভাগ ব্রাউজার ব্লক বা ছিনিয়ে নেয়, কারণ সেগুলো ইতিহাস, লগ এবং রেফারার হেডারে ফাঁস হয়। curl-এ -u user:pass পাস করলে পাসওয়ার্ড আপনার শেল ইতিহাস এবং প্রসেস লিস্টে রেকর্ড হয়, যেখানে মেশিনের অন্যান্য ব্যবহারকারী দেখতে পারে; -u user পছন্দ করুন এবং curl-কে প্রম্পট করতে দিন, অথবা পরিবেশ ভেরিয়েবল থেকে মান পড়ুন।
FAQ
Basic অথ কি নিরাপদ?
শুধুমাত্র HTTPS-এ। base64 এনকোডিং কোনো সুরক্ষা দেয় না — এটি তুচ্ছভাবে বিপরীতমুখী। TLS সহ ক্রেডেনশিয়াল ট্রানজিটে অন্য যেকোনো অনুরোধ ডেটার মতো সুরক্ষিত; TLS ছাড়া এগুলো কার্যকরভাবে প্লেইন টেক্সট।
এনক্রিপশন না হলে base64 কেন?
এর উদ্দেশ্য পরিবহন নিরাপত্তা, গোপনীয়তা নয়। Base64 নিশ্চিত করে ক্রেডেনশিয়ালে শুধু হেডার-নিরাপদ ASCII অক্ষর থাকে, তাই পাসওয়ার্ডে একটি কোলন, স্পেস বা নন-ASCII বাইট হেডার নষ্ট করতে পারে না।
ইউজারনেমে কি কোলন থাকতে পারে?
না। প্রথম কোলন ইউজারনেম থেকে পাসওয়ার্ড আলাদা করে, তাই ইউজারনেমে কোলন ক্রেডেনশিয়ালকে অস্পষ্ট করে তোলে। পাসওয়ার্ডে যেকোনো সংখ্যক কোলন থাকতে পারে।
আমি কীভাবে Basic অথ থেকে লগআউট করব?
কোনো সঠিক প্রক্রিয়া নেই। ব্রাউজার সেশনের জন্য ক্রেডেনশিয়াল ক্যাশ করে, এবং সাধারণ উপায় হলো ব্রাউজার বন্ধ করা বা একটি বিশেষ এন্ডপয়েন্টে 401 ফেরানো। এই সীমাবদ্ধতাই একটি কারণ যে Basic অথ শেষ-ব্যবহারকারী লগইনের জন্য অনুপযুক্ত।
টোকেনের কি মেয়াদ শেষ হয়?
কখনোই না। পাসওয়ার্ড পরিবর্তন না হওয়া পর্যন্ত একই হেডার বৈধ, তাই ফাঁস হওয়া Basic টোকেন ফাঁস হওয়া পাসওয়ার্ডের মতোই গুরুতর। একবার প্রকাশিত হলে ক্রেডেনশিয়াল ঘোরান।
আমার ক্রেডেনশিয়াল কি কোথাও পাঠানো হয়?
না। এনকোডিং ও ডিকোডিং সম্পূর্ণ আপনার ব্রাউজারে চলে। তবুও, যেকোনো ওয়েব পৃষ্ঠায় প্রকৃত প্রোডাকশন ক্রেডেনশিয়াল না পেস্ট করাই ভালো অভ্যাস।