HTTP 407 নাকি 401: কোন লগইন ব্যর্থ হচ্ছে?
প্রক্সির প্রমাণীকরণ ও ওয়েবসাইটের প্রমাণীকরণ আলাদা করুন, সঠিক হেডার দেখুন এবং ভুল পক্ষকে লগইন তথ্য পাঠাবেন না।
407 প্রক্সিতে প্রমাণীকরণ চায়। 401 গন্তব্যের রিসোর্সের জন্য প্রমাণীকরণ চায়। একই অনুরোধ দুটির মুখোমুখি হতে পারে, তাই পাসওয়ার্ড দেওয়ার আগে কে চাইছে বুঝুন।
স্ট্যাটাস ও প্রমাণীকরণের চ্যালেঞ্জ হেডার তুলনা করুন
| প্রতিক্রিয়া | চ্যালেঞ্জ হেডার | লগইন তথ্যের হেডার | সংশ্লিষ্ট পক্ষ |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | মধ্যবর্তী প্রক্সি |
| 401 Unauthorized | WWW-Authenticate | Authorization | মূল রিসোর্সের প্রমাণীকরণ প্রবাহ |
স্ট্যাটাস প্রথম গুরুত্বপূর্ণ সূত্র, কিন্তু পুরো আদান-প্রদান দেখুন। পৃষ্ঠার লেখায় 407 থাকলেই তা আসল HTTP 407 প্রতিক্রিয়া নয়। একইভাবে নিজস্ব লগইন পৃষ্ঠা 200 ফেরত দিয়েও অ্যাপ্লিকেশন স্তরে প্রমাণীকরণ চাইতে পারে।
HTTPS কেন ওয়েবসাইটে পৌঁছানোর আগেই 407 দিয়ে ব্যর্থ হতে পারে
সাধারণ HTTP প্রক্সি দিয়ে HTTPS অনুরোধ গেলে ক্লায়েন্ট সাধারণত আগে CONNECT টানেল তৈরি করতে বলে। প্রক্সি সেই CONNECT অনুরোধের প্রমাণীকরণ চাইতে পারে। তা শেষ না হলে টানেল দিয়ে গন্তব্যের TLS সেশন এখনও গড়ে ওঠেনি, তাই ওয়েবসাইটের API টোকেন বদলে এই ধাপ ঠিক হওয়ার সম্ভাবনা কম।
বিস্তারিত আউটপুট দিয়ে চ্যালেঞ্জ কোথায় আসে দেখুন:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/স্থানীয় লিসেনারের বদলে নিজেরটি দিয়ে লগের প্রথম চ্যালেঞ্জ পড়ুন। CONNECT চলাকালীন 407 গন্তব্যের TLS-এর আগে আসে; সফল টানেলের পরে 401 আসতে পারে।
প্রক্সির ইন্টারফেস দিয়ে তার লগইন তথ্য দিন
বিশ্বস্ত প্রশাসকের দেওয়া এন্ডপয়েন্ট ও অ্যাকাউন্টের জন্য curl প্রক্সির প্রমাণীকরণ পদ্ধতি ঠিক করতে এবং না দেওয়া পাসওয়ার্ড চাইতে পারে:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/উদাহরণের এন্ডপয়েন্ট ও ব্যবহারকারীকে অনুমোদিত সেবার তথ্য দিয়ে বদলান। শুধু ব্যবহারকারী দিলে উপরের কমান্ডে সরাসরি পাসওয়ার্ড রাখতে হয় না। সমর্থিত পদ্ধতি curl-এর বিল্ড ও প্রক্সি অনুযায়ী বদলায়; সমঝোতা ব্যর্থ হলে আসল চ্যালেঞ্জ ও বিল্ডের ক্ষমতা দেখুন।
প্রক্সির প্রমাণীকরণ বিকল্প curl-এর মূল সার্ভারের ব্যবহারকারী প্রমাণীকরণ থেকে আলাদা। প্রক্সির চ্যালেঞ্জের উত্তরের বদলে মূল সার্ভারের Authorization হেডার যোগ করবেন না। প্রক্সির লগইন হেডারও হাতে করে সম্পর্কহীন অনুরোধে পাঠাবেন না বা পুরো অ্যাপে পুনর্ব্যবহৃত হেডারে রাখবেন না।
প্রক্সি বারবার 407 দিলে
- কাঙ্ক্ষিত প্রক্সির হোস্ট ও পোর্ট ব্যবহার করছেন নিশ্চিত করুন।
- Basic ধরে না নিয়ে প্রক্সির ঘোষিত পদ্ধতি দেখুন।
- অ্যাকাউন্টের অবস্থা এবং সেবার প্রত্যাশিত ব্যবহারকারী নামের বিন্যাস নিশ্চিত করুন।
- লগইন তথ্য URL-এ থাকলে বিশেষ অক্ষর কীভাবে পাঠানো হচ্ছে দেখুন।
- ব্রাউজারের সঙ্গে যুক্ত প্রাতিষ্ঠানিক প্রমাণীকরণে রানটাইম বা প্ল্যাটফর্মের সমর্থন লাগে কি না জানুন।
- ক্লায়েন্টের প্রমাণ যথেষ্ট না হলে প্রশাসকের কাছে সংবেদনশীল তথ্যমুক্ত অনুরোধ পরিচয় বা সার্ভার লগ এন্ট্রি চান।
সফল লগইনের পরেও 403 বা প্রত্যাখ্যাত CONNECT প্রবেশ নীতির সিদ্ধান্ত হতে পারে। আরও পাসওয়ার্ড চেষ্টা নিষিদ্ধ গন্তব্যে অধিকার দেবে না।
গন্তব্যের HTTPS সব প্রক্সি লগইন তথ্যের আদান-প্রদান রক্ষা করে না
প্রক্সির প্রমাণীকরণ গন্তব্যের TLS গড়ার আগেই হতে পারে। প্রক্সি পর্যন্ত সংযোগ এনক্রিপশনহীন হলে এবং পদ্ধতি সেখানে পুনর্ব্যবহারযোগ্য লগইন তথ্য প্রকাশ করলে HTTPS গন্তব্য আগের আদান-প্রদান পরে সুরক্ষিত করে না। সেবার উপযোগী পরিবহন ও প্রমাণীকরণ বাছুন; অজানা সর্বজনীন প্রক্সিতে ব্যক্তিগত অ্যাকাউন্ট পাঠাবেন না।
বিস্তারিত লগ ভাগ করার আগে দেখুন। সাধারণ লগইন ক্ষেত্র ঢাকলেও ব্যবহারকারী নাম, অভ্যন্তরীণ এন্ডপয়েন্টের নাম, কুকি বা অন্য শনাক্তকারী তথ্য থাকতে পারে।