Gesaan dan Konteks Berkenaan
Laman web offline-first mesti mengesan perubahan kuki log masuk dalam Service Worker dan mengemas kini dasar cachenya. Reka pendekatan Cookie Store API yang merangkumi skop langganan, semantik peristiwa, race condition, dan sandaran untuk pelayar yang tidak disokong.
Cookie Store API menyediakan operasi baca dan tulis kuki secara tak segerak dan membolehkan Service Worker melanggan perubahan kuki yang sepadan. Ia merupakan alternatif kepada document.cookie yang menyekat (blocking), tetapi ia tidak mengubah kekangan same-origin, path, Secure, HttpOnly, atau SameSite.
Perkara yang Dinilai oleh Penemu Duga
Kupas perbezaan antara API halaman dan API langganan Service Worker, hakikat bahawa cookiechange hanya melibatkan perubahan yang kelihatan pada skrip, penapisan nama dan URL, langganan pendua, race condition bagi peristiwa, dan sebab kuki bukan pangkalan data rentas konteks yang boleh dipercayai.
Soalan Penjelasan
Sahkan sama ada kuki tersebut adalah HttpOnly, sama ada skopnya merentasi path yang berbeza, sama ada halaman dan Service Worker adalah same-origin, dan pelayar mana yang mesti disokong. Tanya sama ada log masuk, log keluar, dan muat semula boleh berlumba (race), sama ada perubahan cache mesti serta-merta, dan berapa lama keadaan sesi lapuk (stale) boleh diterima semasa luar talian.
Rangka Jawapan 30 Saat
“Saya akan melanggan nama kuki dan URL yang diperlukan dalam Service Worker, kemudian membaca semula hanya kuki yang berkaitan selepas cookiechange dan memajukan mesin keadaan sesi idempoten atau versi cache monotonik. Cookie Store adalah tak segerak, peristiwa hanya merangkumi perubahan yang kelihatan pada skrip, dan ia tidak menyediakan transaksi atau susunan global, jadi pengendali mesti menyahduplikasi dan membaca semula keadaan semasa. Pelayar yang tidak disokong mengekalkan semakan kuki bahagian pelayan dan penyegerakan halaman yang eksplisit; cache lapuk tidak sekali-kali menjadi bukti pengesahan.”
Perbincangan Terperinci Langkah demi Langkah
Langkah 1: Tentukan sempadan API
Halaman boleh membaca dan menulis secara tak segerak melalui window.cookieStore; Service Worker menguruskan langganan melalui registration.cookies dan menerima cookiechange. Kedua-duanya kekal tertakluk kepada dasar kuki dan tidak boleh membaca nilai HttpOnly.
Langkah 2: Cipta langganan terkecil
Langgan hanya nama kuki yang diperlukan dan hadkan URL apabila perlu. Kuki dengan nama yang sama pada path yang berbeza boleh wujud bersama, jadi pengendali mesti menggunakan maklumat peristiwa dan URL semasa untuk mengenal pasti sasaran daripada hanya meneka berdasarkan nama sahaja.
self.addEventListener("activate", (event) => {
event.waitUntil(
self.registration.cookies.subscribe([
{ name: "session", url: self.registration.scope },
]),
);
});Langkah 3: Anggap peristiwa sebagai pemberitahuan, bukan snapshot
Peristiwa menerangkan perubahan kuki, tetapi perubahan lain mungkin berlaku sebelum pengendalian tak segerak dijalankan. Baca semula keadaan semasa dengan get() atau getAll(), dan pastikan pemprosesan adalah idempoten. Jangan anggap objek peristiwa sebagai log transaksi atau kebenaran muktamad.
Langkah 4: Asingkan perubahan yang kelihatan pada skrip dan HttpOnly
Spesifikasi hanya memerlukan pemberitahuan untuk perubahan kuki yang kelihatan pada skrip. Pelayan boleh menetapkan atau memadam kuki HttpOnly tanpa mendedahkan nilainya kepada Service Worker. Kesimpulan pengesahan masih datang daripada respons pelayan, bukan daripada ketiadaan peristiwa.
Langkah 5: Modelkan sesi secara eksplisit
Gunakan keadaan seperti unknown, verified, logged out, dan expired, serta majukannya daripada versi respons, masa tamat tempoh, atau hasil pengesahan semula. Perubahan kuki mencetuskan semakan; ia sendiri tidak membuktikan log masuk atau log keluar.
Langkah 6: Kendalikan race condition merentasi tab
Beberapa halaman boleh memuat semula atau memadam kuki secara serentak. Gabungkan (coalesce) ledakan peristiwa yang singkat, gunakan satu kemas kini cache daripada bacaan terkini, dan gunakan versi sesi supaya peristiwa lama tidak boleh menulis ganti keadaan yang lebih baharu. Pemadaman cache dan precaching juga harus bersifat idempoten.
Langkah 7: Reka sandaran pelayar yang tidak disokong
Apabila Cookie Store tidak tersedia, lakukan penyegerakan eksplisit selepas navigasi penting atau respons rangkaian sementara pelayan kekal berwibawa (authoritative). Jangan lakukan pengundian (polling) document.cookie untuk nilai HttpOnly atau melonggarkan pengesahan cache disebabkan ketiadaan API tersebut.
Langkah 8: Minimalkan pendedahan privasi dan keselamatan
Langgan hanya nama dan URL yang diperlukan untuk perniagaan. Jangan sekali-kali menulis nilai kuki ke dalam log, Cache Storage, atau postMessage. Kekalkan tetapan Secure, HttpOnly, SameSite, Path, dan masa tamat tempoh yang munasabah, serta kosongkan cache klien semasa log keluar.
Contoh Jawapan Berkualiti Tinggi
Saya akan menggunakan Cookie Store sebagai pemberitahu perubahan, bukan pangkalan data pengesahan. Semasa pengaktifan Service Worker, cipta langganan idempoten untuk nama dan skop yang tepat. Pada cookiechange, baca semula keadaan semasa yang kelihatan pada skrip, majukan mesin keadaan sesi idempoten, dan kemas kini atau kosongkan cache menggunakan versi sesi. Nilai HttpOnly kekal disahkan oleh pelayan, dan ketiadaan peristiwa tidak sekali-kali membuktikan bahawa sesi tidak berubah. Gabungkan muat semula serentak daripada pelbagai tab supaya pemberitahuan lama tidak boleh menulis ganti keadaan yang lebih baharu. Bagi pelayar yang tidak disokong, kekalkan pengesahan pelayan pada permintaan kritikal dan gunakan penyegerakan halaman yang eksplisit, jangan sekali-kali menggunakan pengundian document.cookie sebagai pengganti perlindungan HttpOnly. Skopkan langganan dan operasi cache, serta uji log keluar, tamat tempoh, penggunaan luar talian, dan kemas kini Service Worker.
Kesilapan Biasa
Menganggap cookiechange sebagai log audit yang lengkap
Ia hanyalah pemberitahuan, bukan jujukan transaksi rentas proses. Pengendali mesti membaca semula keadaan semasa dan bertolak ansur dengan kerja pendua.
Menganggap Service Worker boleh membaca kuki HttpOnly
HttpOnly masih menyekat pembacaan skrip. Service Worker boleh meminta pelayan untuk mengesahkan sesi melalui permintaan, tetapi Cookie Store tidak mendedahkan nilai rahsia tersebut.
Membiarkan sebarang perubahan kuki menentukan pengesahan cache
Perubahan boleh datang daripada muat semula, tamat tempoh, atau path lain. Tunggu pengesahan pelayan dan keadaan versi sebelum mengubah cache yang sensitif terhadap pengesahan.
Soalan Susulan dan Maklum Balas
Bagaimanakah anda mengelak daripada memadam kuki bernama sama yang salah pada path lain?
Kekalkan skop URL semasa melanggan dan membaca, dan padam dengan nama, URL, Path, serta atribut lain yang tepat. Jika sasaran tidak dapat dikenal pasti, biarkan respons pelayan melakukan pembersihan daripada mengeluarkan pemadaman yang meluas.
Bolehkah kemas kini Service Worker kehilangan langganan?
Semasa fasa activate pekerja baharu, pastikan langganan wujud secara idempoten dan baca semula keadaan kuki semasa untuk membina semula cache. Jangan bergantung pada memori pekerja lama; permulaan mesti dijalankan selepas kemas kini.
Bagaimana jika kuki tamat tempoh di luar talian dan tiada rangkaian?
Tandakan keadaan tempatan sebagai unverified dan hadkan keupayaan luar talian; mod luar talian tidak boleh melanjutkan sesi pelayan. Sahkan semula terlebih dahulu apabila sambungan pulih, kemudian pulihkan, kosongkan, atau turunkan taraf cache.