Squid کی Basic تصدیق اب بھی پرانا پاس ورڈ کیوں قبول کرتی ہے

Squid کی پاس ورڈ فائل بدلنے سے ضروری نہیں کہ ہر اگلی درخواست helper کو دوبارہ بلائے۔ Basic تصدیق میں Squid کامیابی سے جانچی گئی صارف نام اور پاس ورڈ کی جوڑی کیش کر سکتی ہے۔

Squid 6.13 کی وہ ترتیب جو اس جانچ کے معتبر رہنے کا وقت طے کرتی ہے credentialsttl ہے۔ مثال کے طور پر:

auth_param basic credentialsttl 5 minutes

یہ پالیسی قدر کی مثال ہے، عمومی سفارش نہیں۔ اسے قابل قبول منسوخی تاخیر اور آپ کے تصدیقی بیک اینڈ کے سنبھالنے والے بوجھ کے مطابق منتخب کریں۔

تین جانچیں الگ کریں

پہلے یقینی بنائیں کہ آپ نے فعال helper کی استعمال کردہ فائل میں ترمیم کی ہے۔ غیر استعمال شدہ فائل کی درست تبدیلی بے اثر ہے۔ پھر دیکھیں کہ helper فائل پڑھ کر نئے اکاؤنٹ کی معلومات جانچ سکتا ہے۔ آخر میں چلتے ہوئے instance کے ذریعے نئی پراکسی درخواست آزمائیں، جہاں اسناد کی کیش اور رسائی کے قواعد بھی لاگو ہوتے ہیں۔

helper اور چلتی پراکسی کو الگ الگ آزمائیں۔ helper بتاتا ہے کہ بیک اینڈ فی الحال کیا قبول کرتا ہے، جبکہ Squid کیش شدہ جانچ دوبارہ استعمال کر سکتی ہے۔ تبدیلی کے دوران نئی اسناد کے کام کرنے اور متعلقہ جانچ مدت کے بعد پرانی کے مسترد ہونے دونوں کو دیکھیں۔

اس رویے کی تحقیق کے لیے مخصوص آزمائشی اکاؤنٹ استعمال کریں۔ درخواست، کلائنٹ کے ماخذ اور ہدف کو ایک جیسا رکھیں اور حقیقی پاس ورڈ مشترکہ کمانڈ آؤٹ پٹ میں نہ ڈالیں۔

فائل بدلنے پر انحصار کے بجائے منسوخی کی منصوبہ بندی کریں

جانچ کی کم مدت بیک اینڈ کا کام بڑھاتی ہے۔ مصروف سروس میں کم کرنے سے پہلے helper کی صلاحیت دیکھیں اور حقیقی بیک اینڈ سے رویہ جانچیں۔ اگر آپ کے ورژن اور ترتیب کے لیے ثابت نہ ہو تو یہ نہ سمجھیں کہ configuration reload تمام متعلقہ تصدیقی حالتیں صاف کر دیتی ہے۔

فوری رسائی ہٹانے کے لیے اکاؤنٹ یا ماخذ کی واضح ممانعت الگ حد دے سکتی ہے۔ صرف پاس ورڈ فائل سے حذف کرنے پر انحصار نہ کریں؛ متاثرہ راستے سے اس ممانعت کو آزمائیں۔

یہ ترتیب Basic جانچ کی کیش بیان کرتی ہے۔ کنکشن پر مبنی تصدیقی اسکیموں کی اضافی حالت ہوتی ہے، اس لیے محض مماثلت کی وجہ سے وہی منسوخی ماڈل لاگو نہ کریں۔