في الآونة الأخيرة، كنت أعمل على حزمة webpush جديدة تم إنشاؤها من الألف إلى الياء باستخدام واجهات برمجة تطبيقات الويب فقط. وهذا يجعل من الممكن (نظريًا، على الأقل) إرسال رسائل Web Push مباشرة من متصفحك.
تهدف هذه التدوينة إلى شرح ما هو بروتوكول Web Push وكيف يعمل
(RFC 8291) وكيفية إرسال رسائل Web Push باستخدام مكتبتي.
بروتوكول Web Push هو بروتوكول وسيط يسمح للتطبيق بإرسال رسائل إلى وكيل المستخدم (المتصفح عادة).
إنه مشابه للأحداث المرسلة من الخادم (SSE) بمعنى أنه يتم دفع الرسائل إلى وكيل المستخدم ولكنها تخدم غرضًا مختلفًا. لا تتطلب رسائل الدفع عبر الويب أن تحتوي مواقع الويب على علامة تبويب مفتوحة كعاملين في الخدمة
يمكن الاستماع إلى رسائل الدفع. يعمل في الخلفية.
يتضمن بروتوكول دفع الويب ثلاثة جهات فاعلة:
إليك نظرة عامة على التفاعلات بينهما:
------- -------------- ------------- | UA | | Push Service | | Application | ------- -------------- ------------- | | | | Setup | | || | | Provide Subscription | |-------------------------------------------->| | | | : : : | | Push Message | | Push Message |خدمة الدفع الوسيطة مطلوبة لأسباب متعددة.
أولاً، يعمل على تقليل عرض النطاق الترددي واستخدام البطارية حيث يحتفظ وكلاء المستخدم باتصال واحد فقط لجميع مواقع الويب بدلاً من اتصال واحد لكل موقع ويب.
كما أنه يعمل على تحسين قابلية التوسع والموثوقية حيث تم تصميم خدمات الدفع للمتصفحات الرئيسية للتعامل مع ملايين المستخدمين. نظرًا لأنه يجب الاحتفاظ برسائل الدفع إذا كان وكيل المستخدم غير متصل بالإنترنت، فإن إنشاء خدمة الدفع يتطلب الكثير من الهندسة وبنية تحتية مرنة ومتكررة
أخيرًا، غالبًا ما يكون إنشاء خدمة دفع مخصصة ونشرها وصيانتها أمرًا معقدًا للغاية ويستهلك الكثير من الموارد بالنسبة لشركات الويب الصغيرة. وهذا من شأنه أن يمنح الشركات الكبرى ميزة تنافسية غير عادلة، حيث سيكون لديها الموارد اللازمة لتطوير وتحسين خدمات الدفع الخاصة بها.
إذا كنت مستخدمًا مهتمًا بالخصوصية مثلي، وترى خدمة وسيطةتلقي جميع الرسائل يرفع الأعلام الحمراء. لمعالجة هذه المشكلة، دفع الويب
يثبت
يتم تأمين الرسائل من خلال ترميز المحتوى المشفر عبر HTTP (راجع
حزمة http-ece)، مع التأكد من أن
تظل المعلومات الحساسة محمية وغير قابلة للقراءة لأي طرف ثالث
الخدمات في العبور.
ربما لاحظت أن سهم الإعداد يختلف عن الأسهم الأخرى في الرسم البياني ASCII أعلاه. وذلك لأن مرحلة الإعداد تعتمد على التنفيذ. تطبق جميع المتصفحات الرئيسية جافا سكريبت
دفع واجهة برمجة التطبيقات في
تحتوي الاشتراكات دائمًا على نقطة نهاية URL فريدة مرتبطة باشتراك الدفع ومفتاح عام يستخدم لتشفير الرسائل.
طريق مختلف. طريقة PushManager.subscribe() التي تُرجع معيارًا
تم الكشف عن PushSubscription.
عند إنشاء اشتراك، قد يتم توفير applicationServerKey اختياري لتحديد رسائل دفع خادم التطبيق. هذه هي طريقة مصادقة تعريف خادم التطبيق الطوعي (VAPID)
(RFC 8292). تُستخدم مفاتيح VAPID للتخفيف من هجمات DDOS على خدمات الدفع. كما تعمل إضافة المصادقة بين خادم التطبيق وخدمة الدفع على تقليل مخاطر تسرب نقطة نهاية الاشتراك. لهذه الأسباب، فهي إلزامية في فايرفوكس.
تقديم الاشتراك
الخطوة الثانية هي إرسال الاشتراك إلى خادم التطبيقات حتى يتمكن من البدء في إرسال الرسائل.
سيقوم خادم التطبيقات عادةً بتخزين الاشتراك في قاعدة بيانات لإعادة استخدامه لاحقًا.
رسالة دفع
أخيرًا، لإرسال رسالة، يرسل خادم التطبيقات طلب HTTP مشفرًا مع نظام مصادقة بسيط إذا تم توفير applicationServerKey لإنشاء الاشتراك.
إذا كان وكيل المستخدم متصلاً بالإنترنت عند استلام الرسالة عن طريق خدمة الدفع، فهو
إعادة توجيه. بخلاف ذلك، يتم تخزينه حتى يصبح وكيل المستخدم متصلاً بالإنترنت أو تنتهي صلاحية الرسالة.
عندما يتلقى وكيل المستخدم رسالة، فإنه ينفذ معالج حدث الدفع الذي يستخدم في الغالب لعرض إشعار وهذا كل شيء.
إعداد خادم التطبيقات باستخدام webpush
أولاً يجب عليك إنشاء مفاتيح VAPID لأن بعض المتصفحات تجعلها إلزامية:
$ تشغيل دينو https://raw.githubusercontent.com/negrel/webpush/master/cmd/generate-vapid-keys.ts
$ deno run https://raw.githubusercontent.com/negrel/webpush/master/cmd/generate-vapid-keys.tsانسخ الإخراج واحفظه في ملف، ولن تحتاج إلى إنشاء مفاتيح VAPID مرة أخرى.في كود خادم التطبيق الخاص بك، يمكنك تحميلها على النحو التالي:
استيراد * كـ webpush من "jsr:@negrel/webpush"; // قراءة ملف VAPID الذي تم إنشاؤه. const vapidKeysJson = Deno.readTextFileSync("./path/to/vapid.json"); // استيراد مفاتيح VAPID. webpush.importVapidKeys(JSON.parse(vapidKeysJson));
$ deno run https://raw.githubusercontent.com/negrel/webpush/master/cmd/generate-vapid-keys.tsبعد ذلك، ستحتاج إلى إنشاء مثيل كائن ApplicationServer.// يتم استخدام adminEmail بواسطة مشرف خدمات Push للاتصال بك في حالة وجوده هناك // هناك مشكلة في خادم التطبيق الخاص بك. const adminEmail = "[email protected]"; // إنشاء كائن خادم التطبيق. const appServer = انتظار webpush.ApplicationServer.new({ معلومات الاتصال: "mailto:" adminEmail، مفاتيح فارغة, });
$ deno run https://raw.githubusercontent.com/negrel/webpush/master/cmd/generate-vapid-keys.tsثم لإرسال رسائل الدفع، ما عليك سوى إنشاء PushSubscriber والاتصال بـطريقة PushMessage ()/pushTextMessage () على النحو التالي:
المشتركون الثابتون = []; // معالج HTTP لوكيل المستخدم الذي يرسل اشتراكه. وظيفة الاشتراكHandler(req) { // استخراج الاشتراك المرسل بواسطة وكيل المستخدم. الاشتراك الثابت = انتظار req.json(); // اشتراك المتجر في ديسيبل. // ... // إنشاء كائن مشترك. const sub = appServer.subscribe(subscription); // تخزين المشترك في الذاكرة. المشتركين.push(sub); } // طريقة مساعدة لإرسال رسالة إلى جميع المشتركين. وظيفة البث (رسالة) { لـ (الاشتراكات الفرعية الثابتة) { sub.pushTextMessage(msg, {}); } }
$ deno run https://raw.githubusercontent.com/negrel/webpush/master/cmd/generate-vapid-keys.tsهذا كل شيء، إرسال رسائل الدفع إلى المشتركين لديك!يحتوي مستودع webpush على مثال تفاعلي برمز مشابه يمكنك تشغيله محليًا. ويحتوي أيضًا على كود جافا سكريبت من جانب العميل، لذا تأكد من التحقق منه!
تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.
Copyright© 2022 湘ICP备2022001581号-3