Host Permissions في إضافات المتصفح: لماذا النطاق الواسع يحتاج مراجعة

Chrome Extensions تفصل بين permissions عامة و host permissions التي تحدد أين تستطيع الإضافة الوصول إلى الصفحات أو تنفيذ content scripts. استخدام <all_urls> يبدو مريحًا عندما تكبر قائمة المواقع، لكنه يرفع أثر أي bug أو compromise ويجعل المستخدم غير قادر على فهم لماذا تحتاج الإضافة هذا الوصول. التصميم الأفضل يربط كل نطاق بميزة حقيقية ويستخدم optional permissions عندما تكون الحاجة مؤقتة.

ارسم خريطة Feature إلى Host

لكل feature اكتب المواقع التي تحتاجها ونوع الوصول: قراءة DOM، تعديل، network observation، أو فتح tab فقط. قد تجد أن بعض features لا تحتاج host permission أصلًا إذا تستخدم activeTab بعد فعل واضح من المستخدم.

تجنب Patterns أوسع من الحاجة

نطاق مثل https://*.example.com/* أفضل من all_urls إذا المنتج يعمل على خدمة واحدة. لكن wildcard subdomain نفسه قد يكون واسعًا إذا مواقع العملاء تحت النطاق. راجع ownership والثقة لا syntax فقط.

استخدم Optional Permissions

ميزة نادرة تحتاج موقعًا إضافيًا يمكن أن تطلب permission عند تفعيلها بدل install time. اشرح السبب قبل prompt وسجل حالة الرفض بدون تعطيل بقية الإضافة.

راجع تحديثات ال ـManifest

أي release تضيف host جديدًا يجب أن تمر review أمني ومنتجي. diff لل manifest أسهل من اكتشاف التوسع بعد النشر. اختبر upgrade behavior وهل المتصفح يطلب موافقة جديدة.

افصل القراءة والكتابة داخل الكود

حتى إذا permission تسمح بالوصول، لا تجعل كل module قادرًا على تعديل DOM. APIs داخلية صغيرة تقلل surface وتسهّل اختبار أن feature معينة لا تستخدم host خارج نطاقها.

اختبر Deny و Revoke

ارفض permission الاختيارية ثم حاول feature. يجب أن تعرض حالة مفهومة لا loop prompts. اسحب permission بعد grant واختبر cleanup و listeners.

راقب Usage الفعلي

إذا host permission لم تُستخدم منذ أشهر، راجع إزالتها. Telemetry يجب أن تسجل feature/n طاق بصورة مجمعة لا browsing URLs حساسة.

اختبر الإضافة داخل دورة الحياة كاملة

عند التعامل مع «Host Permissions في إضافات المتصفح: لماذا النطاق الواسع يحتاج مراجعة» لا تكتفِ بتثبيت الإضافة وفتح popup. اختبر التثبيت والترقية وإعادة تشغيل المتصفح وتعليق service worker وإزالته، ثم تأكد من تنظيف listeners والتخزين الذي لم يعد مطلوبًا. شغّل السيناريو داخل بروفايلين للتأكد أن الحالة لا تتسرب بينهما، وجرب رفض permission ثم منحها ثم سحبها. إذا كانت هناك content scripts، راقب توقيت الحقن عند navigation و SPA transitions. بهذه المجموعة تظهر مشاكل لا تراها تجربة يدوية قصيرة بعد التثبيت مباشرة.

معيار القبول قبل الإغلاق

اختبر أثر الترقية وليس التثبيت النظيف فقط. احتفظ ببروفايل على النسخة السابقة ثم حدث الإضافة وراجع storage migrations وال permissions وال background lifecycle. أي warning جديد في console أو extension errors يجب تصنيفه قبل التعميم على كل البروفايلات.

حالة فشل يجب اختبارها

في «Host Permissions في إضافات المتصفح: لماذا النطاق الواسع يحتاج مراجعة» جرّب صفحة لا تطابق نطاق الإضافة ثم صفحة تطابقه جزئيًا. تأكد أن content script وال ـhost permissions لا تتوسع بسبب wildcard أوسع من الحاجة، وأن تعطيل الإضافة يوقف listeners والرسائل فورًا. هذه الاختبارات تكشف حدود النطاق أكثر من مجرد التأكد أن الميزة تعمل.