Bagaimanakah anda akan menggunakan CHIPS untuk mengasingkan sesi bagi widget rentas tapak yang terbenam?

Soalan dan senario

Widget ini dihidangkan oleh support.example dan dibenamkan oleh tapak peringkat atas seperti shop-a.example dan shop-b.example. Ia harus mengekalkan sesi merentasi halaman produk, pembayaran (checkout) dan bantuan di bawah shop-a.example, manakala shop-b.example menerima keadaan yang diasingkan. Reka bentuk mesti mengambil kira kuki pihak ketiga yang disekat, pelayar lama, log keluar, penyerahan ejen dan berbilang tab.

Perkara yang diuji oleh penemu duga

• Adakah calon memahami bahawa CHIPS menguncikan kuki mengikut kedua-dua tapak peringkat atas dan asal terbenam?
• Bolehkah mereka membezakan keadaan berterusan bagi setiap tapak daripada keadaan pihak ketiga tidak terpisah yang memerlukan kebenaran pengguna?
• Bolehkah mereka menghubungkan reka bentuk kuki, sesi pelayan, CSRF, perlindungan ulang tayang (replay protection) dan log keluar ke dalam satu aliran data?
• Adakah mereka merangkumi pengesanan keupayaan, sandaran legasi, kunci cache dan kebolehcerapan?

Soalan penjelasan untuk ditanya terlebih dahulu

Sahkan HTTPS, sama ada widget mesti mengenal pasti seseorang merentasi tapak peringkat atas, sama ada subdomain berkongsi sesi dan sama ada halaman log masuk peringkat atas boleh diterima. Jelaskan sensitiviti data, jangka hayat sesi, tolakan pelayan (server push) dan pelayar sasaran. Jika perniagaan benar-benar memerlukan identiti rentas tapak, CHIPS sahaja bukanlah mekanismenya; gunakan log masuk atau pengesahan eksplisit.

Rangka jawapan 30 saat

Saya akan mentakrifkan sesi sebagai kepunyaan satu tapak peringkat atas. Widget menetapkan kuki selamat dengan Partitioned, dan pelayan menyelesaikan keadaan menggunakan tapak peringkat atas dan sesi widget; subdomain satu tapak berkongsi pemisahan tersebut, manakala tapak lain mendapat pemisahan yang berbeza. Kuki tersebut bukan kelayakan identiti rentas tapak. Log masuk rentas tapak menggunakan aliran pengesahan peringkat atas. Apabila CHIPS tidak tersedia, jalankan tanpa keadaan berterusan atau minta pengguna memberi kebenaran secara eksplisit. Sahkan log keluar, CSRF, pengasingan cache dan tingkah laku berbilang tab dari hujung ke hujung.

Perbincangan terperinci langkah demi langkah

1. Tentukan sempadan kepercayaan. Anggap tapak pembenam sebagai konteks pemisahan, bukan sebagai keputusan pengesahan yang diperoleh daripada rentetan Origin. Simpan senarai izin dan sahkan asal mesej, penyewa (tenant) dan keadaan sesi.
2. Tetapkan kuki terpisah. Gunakan Secure, nilai SameSite yang sesuai dan Partitioned; utamakan awalan __Host apabila mengikat kepada hos semasa. Kunci kuki logik merangkumi asal terbenam dan tapak peringkat atas, jadi widget yang sama tidak boleh membaca satu kuki merentasi dua tapak peringkat atas.
3. Reka bentuk sesi pelayan. Simpan hanya pengecam legap (opaque identifier) rawak dalam kuki. Sesi pelayan merekodkan penyewa, tapak peringkat atas, masa penciptaan, tamat tempoh dan versi pembatalan. Semak semula ikatan pada setiap permintaan dan bukannya mempercayai pemisahan pelayar semata-mata.
4. Kendalikan subdomain dan cache. Subdomain boleh menggunakan semula satu pemisahan peringkat atas, tetapi kunci cache HTML, skrip dan API mesti menyertakan variasi penyewa atau sesi. Gunakan pembenaman cache peribadi atau dasar Vary yang eksplisit untuk respons diperibadikan; jangan biarkan CDN menghidangkan keadaan satu tapak kepada tapak lain.
5. Reka bentuk log masuk dan pengesahan. Apabila individu yang sama mesti dicam, buka halaman log masuk peringkat atas dan kembalikan kod pengesahan sekali guna yang berjangka hayat pendek. Jangan sekali-kali meletakkan token berjangka hayat panjang dalam URL, postMessage atau kuki tidak terpisah.
6. Sediakan sandaran dan kebolehcerapan. Jalankan dalam mod tanpa sesi atau minta pengesahan eksplisit apabila sokongan tiada; jangan pulihkan kuki pihak ketiga global secara senyap. Jejaki kadar capaian kuki pemisahan, kejayaan pengesahan dan sebab penciptaan atau pembatalan sesi tanpa mencatat nilai kuki atau token dalam log.

Contoh jawapan berkualiti tinggi

Saya akan menggunakan CHIPS untuk sempadan pengekalan keadaan widget dalam satu tapak peringkat atas. support.example menetapkan kuki dengan Secure, SameSite=None dan Partitioned; ia hanya menyimpan pengecam sesi legap. Sesi pelayan mengikat penyewa, tapak peringkat atas, tamat tempoh dan versi pembatalan. Subdomain di bawah shop-a.example menggunakan semula satu pemisahan, manakala shop-b.example secara semula jadi menerima keadaan yang lain.

Identiti rentas tapak tidak bergantung pada kuki tersebut. Widget membuka halaman peringkat atas untuk log masuk, memperoleh kod pengesahan sekali guna selepas tindakan pengguna, dan menukarnya untuk sesi berjangka hayat pendek dalam pemisahan semasa melalui saluran mesej yang disahkan. Jika pelayar lama atau dasar menyekat kuki terpisah, widget menawarkan pengalaman tanpa sesi atau pengesahan eksplisit dan bukannya beralih kepada kuki pihak ketiga global. Uji dua tapak peringkat atas, subdomain, log keluar, tamat tempoh, tab serentak, caching, CSRF, mesej palsu dan tetapan privasi. Rujukan utama ialah dokumentasi CHIPS dan Storage Access API MDN serta penjelasan CHIPS Privacy Sandbox.

Kesilapan biasa

• Menganggap kuki Partitioned sebagai kelayakan daftar masuk tunggal rentas tapak, lalu menjejaskan pengasingan.
• Mengesahkan daripada Origin sahaja sambil mengabaikan pengikatan penyewa, pembatalan, CSRF dan ulang tayang.
• Menggunakan kuki pihak ketiga tidak terpisah secara senyap apabila CHIPS tidak tersedia, menyebabkan kebocoran atau sekatan.
• Meninggalkan variasi cache CDN, Service Worker atau proksi dan menghidangkan respons diperibadikan satu tapak kepada tapak lain.
• Meletakkan token berjangka hayat panjang dalam URL, postMessage atau kuki yang boleh dibaca frontend.

Soalan susulan dan jawapan

Bilakah anda akan menggunakan CHIPS berbanding Storage Access API?

Gunakan CHIPS untuk keadaan terbenam bebas bagi setiap tapak peringkat atas. Gunakan Storage Access API apabila terdapat keperluan yang wajar untuk keadaan pihak ketiga tidak terpisah dan pengguna boleh memberikan kebenaran, seperti log masuk eksplisit. Sempadan privasi kedua-duanya berbeza, jadi satu bukanlah pengganti senyap untuk yang lain.

Bagaimanakah anda membuktikan dua tapak peringkat atas tidak boleh berkongsi sesi?

Benamkan widget dalam kedua-dua tapak dalam pelayar yang sama dan rekodkan pengecam sesi, pengikatan penyewa pelayan dan capaian cache. Mengosongkan kuki satu tapak, log keluar, membuka tab baharu dan menukar subdomain tidak boleh mengubah keadaan tapak yang lain.

Bagaimana jika produk berkeras untuk mengecam satu individu merentasi tapak?

Tingkatkan keperluan kepada pengesahan identiti eksplisit: log masuk peringkat atas, kod sekali guna berjangka hayat pendek, pertukaran pelayan dan sesi yang boleh dibatalkan. Rekodkan persetujuan dan kegagalan dan bukannya mencipta saluran penjejakan rentas tapak yang tersembunyi.