Chrome onAuthRequired: اسناد بھیجنے سے پہلے isProxy جانچیں

براؤزر ایکسٹینشن کو دو مختلف جگہوں سے توثیقی چیلنجز مل سکتے ہیں: درخواست لے جانے والا پراکسی اور منزل ویب سائٹ۔ انہیں خودکار طور پر ایک ہی اکاؤنٹ نہیں ملنا چاہیے۔

Chrome کے webRequest.onAuthRequired ایونٹ میں مفید امتیاز isProxy ہے۔ صرف پرامپٹ غائب کرنے کے لیے وہ جانچ ہٹانے والا کال بیک پراکسی اسناد اصل چیلنج کو دینا شروع کر سکتا ہے۔

جس پراکسی پر بھروسہ کرنا ہے اس سے مطابقت رکھیں

isProxy جانچنا ایک آغاز ہے۔ ہینڈلنگ کو متوقع پراکسی چیلنجر اور درخواست کے سیاق تک بھی محدود کریں۔ متعدد اینڈ پوائنٹس سنبھالنے والی ایکسٹینشن کو ہر چیلنج کے لیے ایک عالمی پاس ورڈ کے بجائے اسی اینڈ پوائنٹ کا اکاؤنٹ منتخب کرنا چاہیے۔

یہ مت سمجھیں کہ پراکسی روٹ مقرر کرنا اور اس کا لاگ ان سنبھالنا ایک ہی اجازت یا ایک ہی API کال ہے۔ Chrome انہیں الگ الگ دستاویز کرتا ہے۔ ایونٹ ڈیٹا اور توثیقی اجازتوں کے لیے موجودہ webRequest حوالہ استعمال کریں۔ Manifest V3 سننے والے کی رجسٹریشن کی مثال کال بیک کے اندر ہم وقت رجسٹریشن اور اکاؤنٹ کا انتخاب دکھاتی ہے۔

مینی فیسٹ کی نسل جانچیں

تجرباتی WebRequest API کا ذکر کرنے والی مثالیں پرانی ایکسٹینشن ریلیز سے آتی ہیں۔ موجودہ اجازت کی ضروریات ایکسٹینشن کے مینی فیسٹ کی نسل اور تعیناتی ماڈل پر منحصر ہیں۔ خاص طور پر، توثیق کی ہینڈلنگ کا اپنا معاون اجازت راستہ ہے؛ فرسودہ بلاکنگ سننے والے کی مثال یہ ثابت کرنے کے لیے کافی نہیں کہ Manifest V3 ایکسٹینشن اسے بغیر تبدیلی کے چلا سکتی ہے۔

درست ہینڈلر کو انہی مسترد شدہ اسناد کو لامحدود دوبارہ آزمانے سے بھی بچنا چاہیے۔ اکاؤنٹ دینے کے بعد آنے والے دوسرے چیلنج کو پاس ورڈ ہمیشہ دوبارہ چلانے کی درخواست نہیں بلکہ تحقیق کے لیے ثبوت سمجھیں۔

اسناد ایکسٹینشن کے مناسب محفوظ ہینڈلنگ راستے میں ہی رہنی چاہئیں۔ انہیں PAC فائل میں شائع نہ کریں اور تقسیم شدہ نمونے میں ہارڈ کوڈ نہ کریں۔ مقصد تنگ دائرے کا پراکسی لاگ ان ہے، ہر توثیقی چیلنج کا ایک ہی راز سے جواب دینے والا براؤزر بھر کا قاعدہ نہیں۔