Petunjuk dan Konteks yang Berlaku
Situs offline-first harus mendeteksi perubahan cookie login di Service Worker dan memperbarui kebijakan cache-nya. Rancang pendekatan Cookie Store API yang mencakup scope langganan, semantik event, race condition, dan fallback untuk browser yang tidak didukung.
Cookie Store API menyediakan operasi baca dan tulis cookie secara asinkron serta memungkinkan Service Worker berlangganan perubahan cookie yang cocok. Ini adalah alternatif dari document.cookie yang bersifat memblokir (blocking), tetapi tidak mengubah batasan same-origin, path, Secure, HttpOnly, atau SameSite.
Hal yang Dievaluasi Pewawancara
Cakup perbedaan antara API halaman dan API langganan Service Worker, fakta bahwa cookiechange berkaitan dengan perubahan yang terlihat oleh skrip, pemfilteran nama dan URL, langganan duplikat, race condition pada event, dan mengapa cookie bukanlah basis data lintas-konteks yang andal.
Pertanyaan Klarifikasi
Konfirmasikan apakah cookie bersifat HttpOnly, apakah scope-nya melintasi berbagai path, apakah halaman dan Service Worker memiliki asal yang sama (same-origin), dan browser mana saja yang harus didukung. Tanyakan apakah login, logout, dan refresh dapat mengalami race condition, apakah perubahan cache harus instan, dan berapa lama status sesi usang (stale) dapat diterima saat offline.
Kerangka Jawaban 30 Detik
“Saya akan berlangganan nama cookie dan URL yang diperlukan di Service Worker, lalu membaca ulang hanya cookie yang relevan setelah cookiechange dan memajukan state machine sesi yang idempoten atau versi cache monotonik. Cookie Store bersifat asinkron, event hanya mencakup perubahan yang terlihat oleh skrip, dan tidak menyediakan transaksi atau urutan global, sehingga handler harus melakukan deduplikasi dan membaca ulang status saat ini. Browser yang tidak didukung tetap mempertahankan pemeriksaan cookie sisi server dan sinkronisasi halaman secara eksplisit; cache yang usang tidak pernah menjadi bukti autentikasi.”
Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Tentukan batasan API
Halaman dapat membaca dan menulis secara asinkron melalui window.cookieStore; Service Worker mengelola langganan melalui registration.cookies dan menerima cookiechange. Keduanya tetap tunduk pada kebijakan cookie dan tidak dapat membaca nilai HttpOnly.
Langkah 2: Buat langganan sekecil mungkin
Berlanggananlah hanya pada nama cookie yang diperlukan dan batasi URL jika perlu. Cookie dengan nama yang sama pada path yang berbeda dapat hidup berdampingan, sehingga handler harus menggunakan informasi event dan URL saat ini untuk mengidentifikasi target, alih-alih menebak hanya dari namanya saja.
self.addEventListener("activate", (event) => {
event.waitUntil(
self.registration.cookies.subscribe([
{ name: "session", url: self.registration.scope },
]),
);
});Langkah 3: Perlakukan event sebagai notifikasi, bukan snapshot
Event mendeskripsikan perubahan cookie, tetapi perubahan lain dapat terjadi sebelum penanganan asinkron dijalankan. Baca ulang status saat ini dengan get() atau getAll(), dan buat pemrosesan bersifat idempoten. Jangan memperlakukan objek event sebagai log transaksi atau kebenaran mutlak.
Langkah 4: Pisahkan perubahan yang terlihat oleh skrip dan HttpOnly
Spesifikasi hanya mewajibkan notifikasi untuk perubahan cookie yang terlihat oleh skrip. Server dapat menyetel atau menghapus cookie HttpOnly tanpa mengekspos nilainya ke Service Worker. Kesimpulan autentikasi tetap berasal dari respons server, bukan dari ketiadaan event.
Langkah 5: Modelkan sesi secara eksplisit
Gunakan status seperti unknown, verified, logged out, dan expired, lalu perbarui status tersebut berdasarkan versi respons, waktu kedaluwarsa, atau hasil revalidasi. Perubahan cookie memicu pemeriksaan; perubahan itu sendiri tidak membuktikan login atau logout.
Langkah 6: Tangani race condition di seluruh tab
Beberapa halaman dapat me-refresh atau menghapus cookie secara bersamaan. Gabungkan (coalesce) lonjakan event yang berdekatan, terapkan satu pembaruan cache dari pembacaan terbaru, dan gunakan versi sesi agar event lama tidak dapat menimpa status yang lebih baru. Penghapusan cache dan precaching juga harus bersifat idempoten.
Langkah 7: Rancang fallback untuk browser yang tidak didukung
Ketika Cookie Store tidak tersedia, lakukan sinkronisasi eksplisit setelah navigasi penting atau respons jaringan sementara server tetap menjadi sumber otoritatif. Jangan melakukan polling document.cookie untuk mencari nilai HttpOnly atau melonggarkan autentikasi cache hanya karena API tersebut tidak ada.
Langkah 8: Minimalkan eksposur privasi dan keamanan
Berlanggananlah hanya pada nama dan URL yang dibutuhkan secara bisnis. Jangan pernah menuliskan nilai cookie ke log, Cache Storage, atau postMessage. Pertahankan pengaturan Secure, HttpOnly, SameSite, Path, serta masa kedaluwarsa yang wajar, dan bersihkan cache klien saat logout.
Contoh Jawaban Berkualitas Tinggi
Saya akan menggunakan Cookie Store sebagai pemberi notifikasi perubahan, bukan basis data autentikasi. Selama aktivasi Service Worker, buat langganan idempoten untuk nama dan scope yang tepat. Pada cookiechange, baca ulang status saat ini yang terlihat oleh skrip, jalankan state machine sesi yang idempoten, dan perbarui atau bersihkan cache menggunakan versi sesi. Nilai HttpOnly tetap divalidasi oleh server, dan ketiadaan event tidak pernah membuktikan bahwa sesi tidak berubah. Gabungkan refresh bersamaan dari beberapa tab sehingga notifikasi lama tidak dapat menimpa status yang lebih baru. Untuk browser yang tidak didukung, pertahankan validasi server pada permintaan kritis dan gunakan sinkronisasi halaman eksplisit, jangan pernah menggunakan polling document.cookie sebagai pengganti perlindungan HttpOnly. Batasi scope langganan dan operasi cache, serta uji skenario logout, kedaluwarsa, penggunaan offline, dan pembaruan Service Worker.
Kesalahan Umum
Memperlakukan cookiechange sebagai audit log lengkap
Ini adalah notifikasi, bukan urutan transaksi lintas-proses. Handler harus membaca ulang status saat ini dan menoleransi pekerjaan duplikat.
Mengasumsikan Service Worker dapat membaca cookie HttpOnly
HttpOnly tetap memblokir pembacaan oleh skrip. Service Worker dapat meminta server untuk memvalidasi sesi melalui permintaan (request), tetapi Cookie Store tidak akan mengungkap nilai rahasia tersebut.
Membiarkan perubahan cookie apa pun menentukan autentikasi cache
Perubahan dapat berasal dari refresh, kedaluwarsa, atau path lain. Tunggu validasi server dan status versi sebelum mengubah cache yang sensitif terhadap autentikasi.
Pertanyaan Lanjutan dan Tanggapan
Bagaimana cara menghindari penghapusan cookie bernama sama yang salah pada path lain?
Pertahankan scope URL saat berlangganan dan membaca, lalu hapus dengan menyertakan nama, URL, Path, dan atribut lainnya secara tepat. Jika target tidak dapat diidentifikasi, biarkan respons server yang melakukan pembersihan alih-alih melakukan penghapusan secara luas.
Bisakah pembaruan Service Worker menghilangkan langganan?
Selama fase activate dari worker baru, pastikan keberadaan langganan secara idempoten dan baca ulang status cookie saat ini untuk membangun kembali cache. Jangan mengandalkan memori worker lama; inisialisasi harus berjalan setelah pembaruan.
Bagaimana jika cookie kedaluwarsa saat offline dan tidak ada jaringan?
Tandai status lokal sebagai unverified dan batasi kemampuan offline; mode offline tidak dapat memperpanjang sesi server. Lakukan revalidasi terlebih dahulu saat konektivitas kembali, lalu pulihkan, bersihkan, atau turunkan versi cache.