Chrome onAuthRequired: تحقّق من isProxy قبل إرسال بيانات الاعتماد

قد يواجه امتداد المتصفح تحدّيات مصادقة من مكانين مختلفين: الوكيل الذي ينقل الطلب والموقع الوجهة. ويجب ألّا يتلقّى الاثنان الحساب نفسه تلقائيًا.

المميّز المفيد في حدث webRequest.onAuthRequired في Chrome هو isProxy. فالاستدعاء الذي يزيل هذا الفحص لمجرد إخفاء مطالبة قد يبدأ في تقديم بيانات اعتماد الوكيل لتحدّي أصل.

طابِق الوكيل الذي تنوي الوثوق به

فحص isProxy بداية. وقيّد أيضًا المعالجة بالتحدّي المتوقّع للوكيل وسياق الطلب. والامتداد الذي يدير عدة نقاط نهاية ينبغي أن يختار الحساب التابع لتلك النقطة، لا كلمة مرور عالمية واحدة لكل تحدٍّ.

لا تفترض أن ضبط مسار الوكيل ومعالجة تسجيل الدخول إليه إذن واحد أو استدعاء API واحد. فChrome يوثّق كليهما منفصلين. استخدم مرجع webRequest الحالي لبيانات الأحداث وأذونات المصادقة. ويوضّح مثال تسجيل مستمع Manifest V3 التسجيل المتزامن واختيار الحساب داخل الاستدعاء.

تحقّق من جيل البيان

الأمثلة التي تذكر واجهة WebRequest التجريبية تأتي من إصدارات امتدادات قديمة. وتعتمد متطلبات الأذونات الحالية على جيل بيان الامتداد ونموذج نشره. وبشكل خاص، لمعالجة المصادقة مسار أذونات مدعوم خاص بها؛ ومثال مستمع حجب قديم لا يكفي لإثبات أن امتداد Manifest V3 يمكنه تشغيله دون تغيير.

وعلى المعالج الصحيح أيضًا أن يتجنّب إعادة محاولة بيانات الاعتماد المرفوضة نفسها إلى ما لا نهاية. تعامل مع التحدّي الثاني بعد تقديم حساب كدليل يستحق التحقيق، لا كطلب لإعادة كلمة المرور إلى الأبد.

ينبغي أن تبقى بيانات الاعتماد في مسار المعالجة المحمي المناسب للامتداد. لا تنشرها في ملف PAC ولا تثبّتها في عيّنة موزّعة. الهدف تسجيل دخول وكيل محدود النطاق، لا قاعدة على مستوى المتصفح تجيب كل تحدّي مصادقة بالسر نفسه.