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 منزل پچھلے تبادلے کو بعد میں محفوظ نہیں کرتی۔ سروس کے مطابق ٹرانسپورٹ اور تصدیق چنیں؛ نامعلوم عوامی پراکسی کو نجی اکاؤنٹ نہ بھیجیں۔
تفصیلی لاگ شیئر کرنے سے پہلے دیکھیں۔ عام لاگ ان خانے چھپانے کے باوجود صارف نام، اندرونی اینڈپوائنٹ کے نام، کوکی یا دوسری شناختی معلومات رہ سکتی ہیں۔