Apache ProxyRemote اسناداد اور proxy-chain-auth

ایک کلائنٹ ایک اکاؤنٹ سے Apache فارورڈ پراکسی پر تصدیق کر سکتا ہے، جبکہ Apache دوسرے اکاؤنٹ سے پیرنٹ پراکسی پر تصدیق کرتا ہے:

client ── client account ── Apache ── parent account ── parent proxy

httpd 2.4.59 یا اس کے بعد مقررہ پیرنٹ اکاؤنٹ کے لیے ProxyRemote تیسرا آرگیومنٹ قبول کرتا ہے:

ProxyRemote "*" "http://parent.example:3128" "parent-user:replace_with_private_password"

یہ موجودہ رسائی-کنٹرول شدہ فارورڈ-پراکسی ترتیب کی تکمیل کرتا ہے، مثلاً کوئی نجی سننے والا جو کلائنٹ IP اور پراکسی لاگ اِن دونوں کا تقاضا کرتا ہے۔ اکاؤنٹ منتخب کردہ پیرنٹ کا ہے۔ اس پر مشتمل ترتیب کی حفاظت کریں اور تعیناتی کے لیے درکار مطابقت کی حد منتخب کریں۔

Apache یہ Basic اسناداد پہلے سے بھیجتا ہے، پہلے چیلنج کا انتظار کیے بغیر۔ اسی لیے پیرنٹ کنکشن کی ترسیل اور اکاؤنٹ پالیسی اہم ہو جاتی ہے؛ ویب سائٹ کا بعد کا HTTPS سیشن خود پیرنٹ تک کے صریح متن HTTP چھلانگ کی حفاظت نہیں کرتا۔

وہی آنے والا اکاؤنٹ کب جاری رہنا چاہیے

عام طور پر Apache اپنی طرف بھیجی گئی پراکسی توثیق استعمال کرتا ہے۔ proxy-chain-auth ماحولیاتی ترتیب اس کے بجائے کلائنٹ کے پراکسی اسناداد کو اگلی پراکسی تک بھیجنے کی اجازت دیتی ہے:

SetEnv proxy-chain-auth On

یہ صرف جان بوجھ کر مشترکہ توثیق زنجیر کے لیے موزوں ہے۔ یہ آنے والے اکاؤنٹ کا مواد آگے بھیجتا ہے؛ یہ پیرنٹ کے لیے مختلف صارف نام اور پاس ورڈ نہیں گھڑتا۔

ProxyRemote کے واضح اسناداد آرگیومنٹ کے ساتھ proxy-chain-auth کا کوئی اثر نہیں ہوتا۔ اس امید میں کہ کون سا پاس ورڈ چلے گا دونوں ترتیبات کو تہہ نہ لگائیں، بلکہ اسناداد کا ماخذ جان بوجھ کر منتخب کریں۔

یہ طریقے پراکسی چھلانگوں کی توثیق کرتے ہیں۔ منزل ویب سائٹ کا Authorization ہیڈر الگ تبادلہ ہی رہتا ہے۔