Temu duga Frontend: Bagaimanakah Notification.navigate menyokong pautan dalaman (deep link) tolak yang boleh dipercayai?

1. Gesaan dan skop

Pemberitahuan Web Push e-dagang harus membuka butiran pesanan. Aplikasi mungkin ditutup, tetingkap sedia ada mungkin terbuka, atau pengguna mungkin mengaktifkan sesuatu tindakan. Reka bentuk pautan dalaman (deep link) dengan pilihan navigate dan rangkumi penghuraian URL, kebenaran, sandaran (fallback) klik, pembukaan pendua, dan jangka hayat Service Worker.

2. Perkara yang dinilai oleh penemu duga

• Mengetahui bahawa NotificationOptions.navigate ialah URL navigasi dan Notification.navigate mendedahkan URL mutlak yang dihuraikan atau rentetan kosong.
• Membezakan navigasi pemberitahuan lalai, navigasi tindakan, dan pengendalian sandaran (fallback) notificationclick.
• Mengendalikan kebenaran, HTTPS, dasar asal yang sama (same-origin policy), pengalihan terbuka (open redirects), pemberitahuan pendua, dan penggunaan semula tetingkap sedia ada.
• Mengekalkan pemulihan laluan, pengesahan, dan keidempotensian pada lapisan aplikasi dan bukannya menganggap navigasi pelayar sebagai kebenaran (authorization).

3. Soalan untuk dijelaskan terlebih dahulu

1. Adakah kod halaman atau Service Worker memanggil showNotification?
2. Adakah URL luaran dibenarkan, dan bagaimanakah halaman pesanan yang disahkan perlu disambung semula selepas log masuk?
3. Patutkah klik badan dan klik tindakan membuka laluan berbeza atau melakukan operasi berbeza?
4. Apabila tetingkap asal yang sama (same-origin) wujud, patutkah produk memfokuskannya atau membuat tetingkap lain?

4. Jawapan tiga puluh saat

Di bawah HTTPS, saya akan mengarahkan Service Worker mencipta pemberitahuan berterusan yang mana URL navigate melepasi senarai dibenarkan (allowlist) asal yang sama. Badan atau tindakan dengan URL navigasi boleh dikendalikan oleh pelayar; tindakan tanpa URL akan kembali kepada notificationclick, di mana saya memfokuskan tetingkap sedia ada atau membuka laluan pemulihan. Kebenaran, URL tidak sah, dan kegagalan pengesahan masih memerlukan pengendalian aplikasi yang jelas.

5. Penerokaan mendalam langkah demi langkah

Langkah 1: Bina URL pemberitahuan yang disahkan

const target = new URL(`/orders/${orderId}`, self.location.origin);

await self.registration.showNotification("Order shipped", {
  body: "View tracking details",
  tag: `order-${orderId}`,
  navigate: target.href,
  data: { orderId },
});

navigate diselesaikan berbanding URL asas yang digunakan semasa pemberitahuan dicipta. Laluan yang disediakan oleh pelayan mesti melepasi semakan asal yang sama dan senarai dibenarkan laluan; input pengguna yang sewenang-wenangnya tidak boleh dijadikan sasaran pengalihan.

Langkah 2: Asingkan navigasi badan dan tindakan

await self.registration.showNotification("Order needs confirmation", {
  body: "Choose an action",
  navigate: "/orders/123",
  actions: [
    { action: "open", title: "View order", navigate: "/orders/123" },
    { action: "help", title: "Contact support" },
  ],
});

Apabila sesuatu tindakan diaktifkan, navigate miliknya sendiri diutamakan. Tindakan tanpa URL tersebut memasuki notificationclick, di mana tingkah laku khusus aplikasi dijalankan. Laluan badan dan tindakan harus berkongsi senarai dibenarkan dan peraturan pemulihan pengesahan yang sama.

Langkah 3: Kendalikan sandaran klik dan tetingkap sedia ada

self.addEventListener("notificationclick", (event) => {
  event.notification.close();
  if (event.action === "help") {
    event.waitUntil(clients.openWindow("/support"));
    return;
  }
  event.waitUntil(clients.matchAll({ type: "window", includeUncontrolled: true })
    .then((windows) => windows[0]?.focus() ?? clients.openWindow("/orders/123")));
});

Kod pengeluaran harus mengesahkan URL tetingkap, menunggu kawalan Service Worker, dan menghantar data yang dipercayai dan bukannya mengekod keras pesanan. Pelayar mungkin menggunakan semula atau membuat tetingkap peringkat atas, jadi pemulihan aplikasi mesti menyokong kedua-dua hasil.

Langkah 4: Kebenaran, protokol, dan keselamatan

Pemberitahuan memerlukan kebenaran pengguna, dan pemberitahuan berterusan memerlukan Service Worker; API ini bergantung pada konteks selamat (secure context). Kebenaran bukanlah kebenaran perniagaan (business authorization): API pesanan mesti mengesahkan semula selepas halaman dibuka. Hadkan navigasi kepada asal yang sama atau asal luaran yang dipercayai secara jelas untuk mengelakkan pengalihan terbuka dan pautan pancingan data (phishing).

Langkah 5: Pulihkan keadaan secara idempoten

Selepas membuka, baca laluan dan data.orderId, tunjukkan keadaan memuatkan, kemudian ambil pesanan dan sahkan identiti. Pemberitahuan dengan tag yang sama harus digabungkan atau dikemas kini mengikut dasar produk. Perubahan laluan, pemulihan fokus, dan analitik mestilah idempoten supaya satu klik tidak dapat membuat permintaan pendua atau peralihan keadaan.

6. Model jawapan berkualiti tinggi

Saya akan membiarkan Service Worker mencipta hanya URL navigate asal yang sama yang disenarai dibenarkan dan menetapkan tag yang stabil. Klik badan mengikut navigasi pelayar, manakala URL tindakan diutamakan; tindakan tanpa URL menggunakan notificationclick untuk memfokuskan tetingkap sedia ada atau membuka sandaran. Halaman mengesahkan semula, membaca parameter pesanan, dan memulihkan keadaan secara idempoten. Kebenaran, HTTPS, pengalihan terbuka, dan URL luaran ialah semakan berasingan; navigasi pemberitahuan tidak pernah menjadi pengesahan (authorization).

7. Kesilapan biasa

• Meletakkan input pengguna terus ke dalam navigate → open redirect → kuat kuasakan senarai dibenarkan asal yang sama dan laluan.
• Menganggap setiap klik sampai ke kod tersuai → navigasi badan mungkin dikendalikan oleh pelayar → bergantung pada notificationclick hanya untuk tindakan tanpa URL.
• Memperlakukan kebenaran pemberitahuan sebagai pengesahan pesanan → pendedahan data → sahkan semula dalam halaman dan API.
• Sentiasa memanggil openWindow → tetingkap dan permintaan pendua → padankan tetingkap asal yang sama dan jadikan pemulihan bersifat idempoten.
• Mengabaikan jangka hayat Service Worker → kerja tak segerak (async) terganggu → simpan janji penyelesaian (completion promises) di dalam event.waitUntil.

8. Soalan susulan

Soalan susulan 1: Apakah yang dikembalikan oleh Notification.navigate?

Ia adalah rentetan baca sahaja yang mengandungi URL navigasi mutlak tersiri pemberitahuan, atau rentetan kosong apabila tiada URL sah ditetapkan.

Soalan susulan 2: Apakah yang berlaku apabila tindakan tidak mempunyai navigate?

Tindakan itu tidak bernavigasi secara automatik. Pengaktifannya boleh dikendalikan oleh notificationclick dalam Service Worker.

Soalan susulan 3: Mengapa perlu mengesahkan semula dalam halaman?

URL dan data hanyalah petunjuk navigasi, bukan kebenaran identiti atau sumber. API pesanan mesti menyemak semula sesi semasa dan kebenaran bahagian pelayan.

Soalan susulan 4: Bagaimanakah anda menguji tingkah laku merentas tetingkap (cross-window)?

Rangkumi tiada tetingkap, tetingkap asal yang sama sedia ada, tetingkap tidak terkawal, klik badan dan tindakan, kebenaran ditolak, dan URL tidak sah; pastikan pemulihan aplikasi hanya membuat satu permintaan.