مختبر دورة اشتراك Web Push: مشاريع تخرج تطوير الويب

قد يضغط المستخدم «السماح» للإشعارات مرة واحدة، ثم يغيّر رأيه أو ينتقل إلى جهاز آخر أو يفقد المتصفح قدرته على الوصول إلى الاشتراك القديم. مشروع تخرج لتطوير الويب يستطيع تتبع هذا العمر بدلاً من تخزين عنوان اشتراك إلى الأبد. ينشئ التطبيق اشتراكاً في متصفح اختبار، يحفظ مرجعاً مشفراً أو معرّفاً داخلياً، ويرسل رسالة غير حساسة، ثم يسجل النتيجة ويميز بين رفض مؤقت وإشارة إلى اشتراك لم يعد معروفاً. المشروع يدرس دورة بيانات محددة، ولا يثبت أن كل الإشعارات ستصل فوراً إلى كل جهاز.

تصلح الفكرة لمشاريع تخرج تطوير الويب عندما يكون المطلوب دراسة الاشتراك وسجل الموافقة ضمن نموذج محدود.

افهم الأطراف الثلاثة

تصف مواصفة W3C Push API مساراً يضم تطبيق الويب، خدمة الدفع التي يتواصل معها المتصفح، وخادم التطبيق الذي يطلب إرسال الرسالة. تصل الرسالة إلى Service Worker ضمن أصل الموقع، ويمكن للعامل استخدام بياناتها لتحديث حالة محلية أو عرض إشعار. لذلك فإن «الاشتراك موجود في قاعدة البيانات» لا يعني أن المستخدم ما زال موافقاً أو أن الخدمة ستسلم الرسالة الآن. اصنع مخططاً لكل طرف وحدد البيانات التي يملكها، ثم لا تخزن المفاتيح أو نقاط النهاية في سجل عام.

أنشئ واجهة محلية تسجل الحالات: غير مشترك، طلب إذن، اشتراك نشط، محاولة إرسال، رفض من خدمة الدفع، ألغاه المستخدم، أو حُذف من النظام. تجنب كلمة «تم التسليم» إذا كان الخادم يعرف فقط أن خدمة الدفع قبلت الطلب. الفرق بين قبول الطلب وعرض الإشعار على الشاشة يجب أن يظهر في نص المشروع وفي نموذج البيانات.

أنشئ اشتراك اختبار واضحاً

يحتاج Web Push عادة إلى سياق آمن وإذن المستخدم وتسجيل Service Worker، ثم يحفظ التطبيق قيمة الاشتراك الناتجة من واجهة المتصفح. اجعل الاشتراك خطوة صريحة وراء زر يشرح الغرض ومعدل الرسائل، ولا تعرض النافذة تلقائياً عند فتح الصفحة. وثائق MDN عن Push API تقدم ملخصاً للواجهات والعلاقة بخدمة العامل. افحص دعم المتصفح في بيئة المختبر قبل الوعد بميزة تعمل في كل منصة.

في قاعدة البيانات، احفظ معرفاً داخلياً ووقت الإنشاء وآخر محاولة وحالة الاشتراك؛ قلل الوصول إلى قيمة endpoint والمفاتيح المرتبطة به، ولا تطبعها في console أو صور العرض. لا تستخدم بيانات حقيقية للطلاب. جهز سكربت ينشئ اشتراكاً تجريبياً واحداً ويزيله بعد انتهاء الاختبار، واحتفظ بسجل بديل منقح يشرح النتائج دون كشف العنوان الفعلي.

تعامل مع الانتهاء والإلغاء كمسارين مختلفين

قد يصبح الاشتراك غير متاح لدى خدمة الدفع، وقد يلغيه المستخدم عبر إعدادات المتصفح، وهذان حدثان مختلفان في رحلة الاستخدام حتى لو أديا إلى تنظيف سجل الخادم. يحدد RFC 8030 سلوك موارد الدفع واستجابات مثل 404 عندما لا يكون المورد موجوداً، ويصف إمكان انتهاء صلاحية الاشتراك وإزالته. اجعل معالج النتيجة يوقف إعادة الإرسال غير المجدية، ويضع علامة منطقية ثم ينظف السجل وفق سياسة موثقة. لا تعتبر كل خطأ شبكة دليلاً على انتهاء الاشتراك.

اختبر ثلاثة سيناريوهات اصطناعية: طلب مقبول، خدمة دفع غير متاحة مؤقتاً، واشتراك منتهي يرجع حالة تدل على غياب المورد. أضف سيناريو إلغاء محلي عبر واجهة المتصفح حيث يكون العامل قادراً على الإبلاغ عن زوال الاشتراك عند الفتح القادم. لا تفترض أن الصفحة مفتوحة لحظة الإلغاء كي تتلقى إشارة مباشرة؛ قد لا يعمل العامل إلا عندما تتاح فرصة تشغيله.

مثال سجل دورة حياة

افترض اشتراكاً تجريبياً أنشئ الساعة 10:00، ثم أرسل التطبيق رسالة بعنوان «تحديث متاح» الساعة 10:05. سجل النظام قبول خدمة الدفع، لكن المستخدم لم يفتح المتصفح. الساعة 10:20 تعود محاولة أخرى بحالة 404؛ يسجل التطبيق الاشتراك على أنه غير صالح ويمنع محاولات لاحقة. هذه أوقات وحالات مختلقة لشرح الاختبار، وليست قياس زمن تسليم حقيقي. الرسالة نفسها لا تتضمن اسماً أو علامة أو محتوى خاصاً.

اعرض سجلاً مموهاً مثل sub_7f…، واحتفظ بالأصل في مخزن محمي إن كانت هناك حاجة عملية له. ضع مدة احتفاظ وحذفاً دورياً، وامسح الاشتراك عند تسجيل الخروج إذا كانت سياسة المنتج تربطه بحساب. لا تستخدم معرفاً قابلاً للتخمين بوصفه وسيلة تفويض؛ يجب أن يتحقق الخادم من صاحب الطلب.

اختبر الأخطاء والخصوصية

تتضمن مصفوفة القبول رفض الإذن، فشل تسجيل العامل، غياب الاتصال، خطأ مفاتيح الإعداد، 404 للاشتراك، وإعادة إرسال رسالة بعد انتهاء الصلاحية. تحقق من أن حالة قاعدة البيانات تتغير مرة واحدة وأن سجل الأخطاء لا يسجل endpoint أو مفاتيح سرية. اختبر مسح الاشتراك من الواجهة ثم إعادة تحميل الصفحة، وتأكد أن زر الحالة لا يعود إلى «مشترك» اعتماداً على نسخة قديمة مخزنة.

تشرح مواصفة Push API نموذج الأذونات والعمل في Service Worker، بينما يناقش RFC جوانب مثل إساءة الاستخدام والاحتفاظ ببيانات الاشتراك. لا ترسل رسائل متكررة في الاختبار ولا تحول المشروع إلى نظام تسويق. استخدم نصاً واحداً بمعدل منخفض، وأضف سجل موافقة قابل للمراجعة يبين متى طلب الإذن ولماذا.

النطاق والتسليم الأكاديمي

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

يشمل التسليم مخطط حالات، صفحة إعداد محلية، سجل أحداث منقح، اختبارات لمسارات الانتهاء والإلغاء، وشرحاً لما يخزنه التطبيق. ترتبط الفكرة بـمشاريع التخرج وتطوير تطبيقات الويب. يمكن الرجوع إلى مختبر اختلاف إصدار Service Worker لدراسة حالة العامل عند تحديث الملفات، لكن ذلك لا يغني عن تحليل اشتراك الدفع نفسه. النتيجة الجيدة ليست عدد الإشعارات المرسلة، بل القدرة على تفسير حالة كل اشتراك وإزالة غير الصالح بأمان.