前端工程

Article

漸進式網路應用程式-推播通知篇

從權限請求、VAPID、PushSubscription 到 Service Worker,整理 PWA Web Push 的訂閱與發送流程。

概述:

各位未來的前端棟樑你們好,歡迎來到 PWA 系列( 沒錯! 又是我 ),此篇在介紹如何幫自己的 PWA 功能網站添加「推播功能」,那就讓我們開始開始內捲吧 ! 補充介紹:


流程介紹:

PWA 推播通知是一種讓網頁應用程式能夠向用戶發送即時訊息的技術,即使瀏覽器關閉或用戶不在該網站上也能收到通知 (廢話)。 話不多說,我們直接從上帝視角 ✞ 看看當用戶接收到推播通知時中間發生了甚麼吧!

訂閱流程

  1. 向用戶索取推播權限
  2. 生成 VAPID 公鑰
  3. 使用訂閱推播 API 將 VAPID 給瀏覽器,瀏覽器返回 PushSubscription 訂閱物件
  4. PushSubscription 訂閱物件發送給後端
  5. 後端將該物件存儲 文章示意圖

推播流程

  1. 往後端打推播 API 端點
  2. 往資料庫取得剛剛存儲的 PushSubscription 物件
  3. 透過 Web push protocol (白話點就是透過套件像 web-push) 往瀏覽器的推播服務發送推播內容
  4. 瀏覽器的推播服務解析並確保內容正常
  5. 瀏覽器的推播服務在向該網站推送消息
  6. 該網站的 Service worker 監聽到推播事件,再向用戶推送消息 文章示意圖 參考來源:web.dev 推送功能的運作方式

補充介紹

  • PushSubscription : 來自 Push API 的 pushManager.subscribe 方法,生成後會伴隨著公鑰用於推送通知之間的加密工作,且包含向該使用者傳送推播訊息所需的所有資訊。您可以將這個 ID 視為使用者裝置的 ID。 參考來源 : MDN PushSubscription https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription - endpoint : 瀏覽器自己的瀏覽器的推播服務。- p256dh : 客戶端生成的公鑰,用於加密推播內容,確保只有訂閱者的瀏覽器能解密訊息。- auth : 認證簽章,用於驗證訊息確實來自授權的伺服器,確保內文沒被竄改。
  • VAPID 公鑰 : 用戶訂閱推播時要向瀏覽器提供的公鑰,伺服器專屬的公鑰(比喻像是身份證名)。可讓推播服務得知哪個應用程式伺服器訂閱了使用者,並確保是同一個伺服器觸發傳送推播訊息給該使用者,讓推播服務知道「只接受來自擁有對應私鑰的伺服器的推播」。[ 參考來源 : Mozila Blog : Sending VAPID identified WebPush Notifications via Mozilla’s Push Service https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/
  • 瀏覽器的推播服務 : 每個瀏覽器都可以使用任何推播服務。這並非問題,因為每個推播服務都會預期相同的 API 呼叫。也就是說,各家瀏覽器會使用自己的推播服務,但都會符合 W3C 推播協定,所以開發者無須關注推播服務是誰。

使用教學:

前端篇

Step 1 在 Service worker 先撰寫好推播邏輯 (因為 Push API 只作用於該內部。想想看,如果推播事件放在 Main thread 會發生什麼事情 :) )。

補充

Step 2 使用瀏覽器的Notification.requestPermission向用戶索取推播權限。權限請求與訂閱都應由使用者操作觸發,例如點擊「開啟通知」按鈕;不要在頁面載入時直接執行。

notifications.js

Step 3 開始生成訂閱物件

subscribePush.js

Step 4 發送訂閱物件至後端。

subscribePush.js

後端篇

後端範例使用 Expressweb-push 套件。

支援度:

Notification API : https://caniuse.com/notifications Push API : https://caniuse.com/?search=Push