Elie Habib e1c3b28180 feat(notifications): Phase 6 — web-push channel for PWA notifications (#3173) ...

* feat(notifications): Phase 6 — web-push channel for PWA notifications

Adds a web_push notification channel so PWA users receive native
notifications when this tab is closed. Deep-links click to the
brief magazine URL for brief_ready events, to the event link for
everything else.

Schema / API:
- channelTypeValidator gains 'web_push' literal
- notificationChannels union adds { endpoint, p256dh, auth,
  userAgent? } variant (standard PushSubscription identity triple +
  cosmetic UA for the settings UI)
- new setWebPushChannelForUser internal mutation upserts the row
- /relay/deactivate allow-list extended to accept 'web_push'
- api/notification-channels: 'set-web-push' action validates the
  triple, rejects non-https, truncates UA to 200 chars

Client (src/services/push-notifications.ts + src/config/push.ts):
- isWebPushSupported guards Tauri webview + iOS Safari
- subscribeToPush: permission + pushManager.subscribe + POST triple
- unsubscribeFromPush: pushManager.unsubscribe + DELETE row
- VAPID_PUBLIC_KEY constant (with VITE_VAPID_PUBLIC_KEY env override)
- base64 <-> Uint8Array helpers (VAPID key encoding)

Service worker (public/push-handler.js):
- Imported into VitePWA's generated sw.js via workbox.importScripts
- push event: renders notification; requireInteraction=true for
  brief_ready so a lock-screen swipe does not dismiss the CTA
- notificationclick: focuses+navigates existing same-origin client
  when present, otherwise opens a new window
- Malformed JSON falls back to raw text body, missing data falls
  back to a minimal WorldMonitor default

Relay (scripts/notification-relay.cjs):
- sendWebPush() with lazy-loaded web-push dep. 404/410 triggers
  deactivateChannel('web_push'). Missing VAPID env vars logs once
  and skips — other channels keep delivering.
- processEvent dispatch loop + drainHeldForUser both gain web_push
  branches

Settings UI (src/services/notifications-settings.ts):
- New 'Browser Push' tile with bell icon
- Enable button lazy-imports push-notifications, calls subscribe,
  renders 'Not supported' on Tauri/in-app webviews
- Remove button routes web_push specifically through
  unsubscribeFromPush so the browser side is cleaned up too

Env vars required on Railway services:
  VAPID_PUBLIC_KEY   public key
  VAPID_PRIVATE_KEY  private key
  VAPID_SUBJECT      mailto:support@worldmonitor.app (optional)

Public key is also committed as the default in src/config/push.ts
so the client bundle works without a build-time override.

Tests: 11 new cases in tests/brief-web-push.test.mjs
- base64 <-> Uint8Array round-trip + null guards
- VAPID default fallback when env absent
- SW push event rendering, requireInteraction gating, malformed JSON
  + no-data fallbacks
- SW notificationclick: openWindow vs focus+navigate, default url

154/154 tests pass. Both tsconfigs typecheck clean.

* fix(brief): address PR #3173 review findings + drop hardcoded VAPID

P1 (security): VAPID private key leaked in PR description.
Rotated the keypair. Old pair permanently invalidated. Structural fix:

  Removed DEFAULT_VAPID_PUBLIC_KEY entirely. Hardcoding the public
  key in src/config/push.ts gave rotations two sources of truth
  (code vs env) — exactly the friction that caused me to paste the
  private key in a PR description in the first place. VAPID_PUBLIC_KEY
  now comes SOLELY from VITE_VAPID_PUBLIC_KEY at build time.
  isWebPushConfigured() gates the subscribe flow so builds without
  the env var surface as 'Not supported' rather than crashing
  pushManager.subscribe.

  Operator setup (one-time):
    Vercel build:      VITE_VAPID_PUBLIC_KEY=<public>
    Railway services:  VAPID_PUBLIC_KEY=<public>
                       VAPID_PRIVATE_KEY=<private>
                       VAPID_SUBJECT=mailto:support@worldmonitor.app

  Rotation: update env on both sides, redeploy. No code change, no
  PR body — no chance of leaking a key in a commit.

P2: single-device fan-out — setWebPushChannelForUser replaces the
previous subscription silently. Per-device fan-out is a schema change
deferred to follow-up. Fix for now: surface the replacement in
settings UI copy ('Enabling here replaces any previously registered
browser.') so users who expect multi-device see the warning.

P2: 24h push TTL floods offline devices on reconnect. Event-type-aware:
  brief_ready:       12h  (daily editorial — still interesting)
  quiet_hours_batch:  6h  (by definition queued-on-wake)
  everything else:   30m  (transient alerts: noise after 30min)

REGRESSION test: VAPID_PUBLIC_KEY must be '' when env var is unset.
If a committed default is reintroduced, the test fails loudly.

11/11 web-push tests pass. Both tsconfigs typecheck clean.

* fix(notifications): deliver channel_welcome push for web_push connects (#3173 P2)

The settings UI queues a channel_welcome event on first web_push
subscribe (api/notification-channels.ts:240 via publishWelcome), but
processWelcome() in the relay only branched on slack/discord/email —
no web_push arm. The welcome event was consumed off the queue and
then silently dropped, leaving first-time subscribers with no
'connection confirmed' signal.

Fix: add a web_push branch to processWelcome. Calls sendWebPush with
eventType='channel_welcome' which maps to the 30-minute TTL tier in
the push-delivery switch — a welcome that arrives >30 min after
subscribe is noise, not confirmation.

Short body (under 80 chars) so Chrome/Firefox/Safari notification
shelves don't clip past ellipsis.

11/11 web-push tests pass.

* fix(notifications): address two P1 review findings on #3173

P1-A: SSRF via user-supplied web_push endpoint.
The set-web-push edge handler accepted any https:// URL and wrote
it to Convex. The relay's sendWebPush() later POSTs to whatever
endpoint sits in that row, giving any Pro user a server-side-request
primitive bounded only by the relay's network egress.

Fix: isAllowedPushEndpointHost() allow-list in api/notification-
channels.ts. Only the four known browser push-service hosts pass:

  fcm.googleapis.com                (Chrome / Edge / Brave)
  updates.push.services.mozilla.com (Firefox)
  web.push.apple.com                (Safari, macOS 13+)
  *.notify.windows.com              (Windows Notification Service)

Fail-closed: unknown hosts rejected with 400 before the row ever
reaches Convex. If a future browser ships a new push service we'll
need to widen this list (guarded by the SSRF regression tests).

P1-B: cross-account endpoint reuse on shared devices.
The browser's PushSubscription is bound to the origin, NOT to the
Clerk session. User A subscribes on device X, signs out, user B
signs in on X and subscribes — the browser hands out the SAME
endpoint/p256dh/auth triple. The previous setWebPushChannelForUser
upsert keyed only by (userId, channelType), so BOTH rows now carry
the same endpoint. Every push the relay fans out for user A also
lands on device X which is now showing user B's session.

Fix: setWebPushChannelForUser scans all web_push rows and deletes
any that match the new endpoint BEFORE upserting. Effectively
transfers ownership of the subscription to the current caller.
The previous user will need to re-subscribe on that device if they
sign in again.

No endpoint-based index on notificationChannels — the scan happens
at <10k rows and is well-bounded to the one write-path per user
per connect. If volume grows, add an  + migration.

Regression tests (tests/brief-web-push.test.mjs, 3 new cases):
  - allow-list defines all four browser hosts + fail-closed return
  - allow-list is invoked BEFORE convexRelay() in the handler
  - setWebPushChannelForUser compares + deletes rows by endpoint

14/14 web-push tests pass. Both tsconfigs typecheck clean.

2026-04-18 20:27:08 +04:00

17 KiB

Raw Permalink Blame History

View Raw