Topik wawancara representatif

Wawancara Frontend: Bagaimana Anda merancang sematan pihak ketiga yang dapat digunakan di bawah partisi penyimpanan dan CHIPS?

FrontendSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Ketika browser mengaktifkan partisi penyimpanan, bagaimana Anda menjaga widget dukungan atau pembayaran pihak ketiga tetap dapat digunakan di seluruh situs tingkat atas? Bandingkan CHIPS, Storage Access API, dan navigasi tingkat atas.

1. Pertanyaan dan Konteks

Anda mengelola widget dukungan yang disematkan oleh beberapa situs merchant. Widget tersebut harus mengingat sesi pengunjung untuk setiap merchant tanpa menautkan pengguna yang sama di seluruh situs tingkat atas yang tidak terkait. Browser dapat mengisolasi cookie, localStorage, cache, dan status jaringan berdasarkan situs tingkat atas dan origin pihak ketiga.

2. Apa yang Sedang Dievaluasi oleh Pewawancara

  • Apakah Anda membedakan origin pihak ketiga bersama dari partisi penyimpanan bersama.
  • Apakah Anda memahami cakupan CHIPS, atribut yang diperlukan, dan semantik isolasi.
  • Apakah Anda merancang persetujuan eksplisit dan jalur fallback untuk status yang benar-benar tidak dipartisi.
  • Apakah privasi, kegunaan, pengalaman login, dan kompatibilitas muncul dalam satu kerangka kerja keputusan.

3. Pertanyaan Klarifikasi Sebelum Anda Menjawab

  1. Apa yang harus dibagikan di seluruh situs tingkat atas, dan apakah identitas bersama benar-benar diperlukan?
  2. Apakah setiap situs memiliki batasan tenant, pengguna, dan sesi masing-masing?
  3. Bisakah pengguna mengklik sekali untuk mengotorisasi, atau haruskah widget dimuat tanpa interaksi?
  4. Browser dan mode penyematan mana yang penting: iframe, popup, atau navigasi tingkat atas?

4. Kerangka Kerja Jawaban 30 Detik

Jawab dengan batasan data, default, pengecualian terotorisasi, fallback, dan verifikasi.

Saya akan membatasi cakupan session key ke situs tingkat atas dan origin widget, lalu menggunakan cookie aman dengan atribut Partitioned sehingga setiap merchant mendapatkan sesi independen. Untuk login lintas situs, saya akan menggunakan navigasi tingkat atas untuk otorisasi eksplisit dan mengembalikan kredensial sekali pakai berumur pendek; jika browser tidak memiliki kapabilitas tersebut, saya akan beralih ke mode anonim dan menjelaskan cara masuk. Saya akan memverifikasi isolasi dengan beberapa situs tingkat atas, pembersihan data situs, dan pengujian akses yang ditolak.

5. Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Tentukan Partition Key dan Kelas Data

Google Privacy Sandbox menjelaskan penyimpanan dan komunikasi pihak ketiga sebagai hal yang diisolasi berdasarkan partisi. MDN menjelaskan partisi status sebagai upaya privasi browser yang mengurangi pelacakan lintas situs. Klasifikasikan data sebagai status sesi lokal merchant, aset yang dapat di-cache secara publik, atau status akun yang benar-benar membutuhkan identitas lintas situs. Kelas pertama tidak boleh melewati pemartisian.

Langkah 2: Gunakan CHIPS untuk Sesi Per-Situs

CHIPS memungkinkan cookie pihak ketiga memilih penyimpanan yang dipartisi. Respons harus menggunakan Partitioned; Secure dan memenuhi persyaratan keamanan cookie browser lainnya. Origin widget yang sama kemudian menerima cookie jar yang berbeda pada merchant A dan merchant B, sehingga konteks dukungan tidak bergabung secara alami di seluruh situs. CHIPS menyediakan status per-situs tingkat atas, bukan login lintas situs bersama.

Langkah 3: Rancang Otorisasi Eksplisit untuk Identitas Lintas Situs

Jika produk benar-benar membutuhkan satu akun yang terlihat di beberapa situs, gunakan navigasi tingkat atas atau Storage Access API sebagai jalur pengecualian. Storage Access API memungkinkan konten pihak ketiga meminta status yang biasanya tidak dipartisi dan tidak dapat diakses; jelaskan mengapa akses diperlukan, mintalah pada waktu yang tepat, dan sediakan jalur penolakan yang berguna. Ikat otorisasi ke situs tingkat atas yang meminta, buat berumur pendek, dan dapat dicabut.

Langkah 4: Bangun Matriks Kompatibilitas dan Privasi

Uji browser yang mendukung CHIPS, browser tanpa dukungan cookie yang dipartisi, akses penyimpanan yang ditolak, pembersihan data situs, beberapa situs tingkat atas yang dibuka sekaligus, dan penggantian iframe atau navigasi yang diikuti dengan pemuatan ulang. Pastikan isolasi cookie, pemulihan sesi, prompt berulang, dan apakah mode stateless masih menyelesaikan tindakan inti.

6. Contoh Jawaban Berkualitas Tinggi

Pertama-tama saya akan mengklarifikasi apakah widget dukungan benar-benar perlu mengidentifikasi pengguna yang sama di seluruh merchant. Jawaban default saya adalah tidak: sesi setiap merchant harus independen karena penautan lintas situs menciptakan risiko privasi dan kepatuhan.

>

Pada jalur default, server widget menetapkan cookie Partitioned; Secure. Browser membentuk partisi penyimpanan independen dari situs tingkat atas dan origin widget, sehingga sesi pada merchant A tidak ada pada merchant B. Skrip dan gambar statis dapat menggunakan caching biasa, tetapi identitas tidak ditempatkan dalam status yang dapat dibaca di seluruh situs.

>

Untuk kasus akun terpadu yang sesungguhnya, saya menyediakan tombol Masuk. Tombol ini menavigasi ke halaman tingkat atas akun, menyelesaikan autentikasi, dan mengembalikan kode sekali pakai berumur pendek ke merchant asli. Jika didukung, widget dapat meminta akses yang tidak dipartisi melalui Storage Access API setelah interaksi pengguna. Jika akses ditolak atau tidak didukung, widget akan beralih ke sesi per-situs anonim dan login tingkat atas. Saya akan menguji dua situs tingkat atas, pembersihan data situs tunggal, dan otorisasi yang ditolak untuk membuktikan tidak ada percampuran akun atau perulangan prompt berulang, sambil melacak rasio hit partisi dan tingkat kegagalan login.

7. Pola Kegagalan Umum

  • Memperlakukan CHIPS sebagai cookie lintas situs bersama alih-alih status yang dipartisi.
  • Memindahkan semua status ke akses yang tidak dipartisi, memperluas permukaan pelacakan dan kegagalan.
  • Hanya membahas Chrome dan melewatkan Firefox, Safari, atau kegagalan deteksi kapabilitas.
  • Meminta akses secara diam-diam saat pemuatan iframe tanpa tindakan pengguna, penjelasan, atau fallback penolakan.
  • Menempatkan token berumur panjang langsung di URL kembali, mengeksposnya ke log, riwayat, atau perujuk (referrer).

8. Pertanyaan Lanjutan dan Tanggapan

Lanjutan 1: Mengapa tidak menaruh ID pengguna di URL situs tingkat atas?

URL dapat masuk ke dalam log, riwayat, sistem analitik, dan perujuk. Gunakan kode sekali pakai berumur pendek dan tukarkan di sisi server untuk sesi yang dibatasi.

Lanjutan 2: Kapan cookie CHIPS dapat membuat pengguna tampak keluar (signed out)?

Kunjungan pertama ke situs tingkat atas baru memiliki cookie baru yang dipartisi. Itu adalah isolasi yang disengaja. Sediakan alur masuk tingkat atas yang jelas alih-alih mencoba membaca cookie situs lain.

Lanjutan 3: Bagaimana Anda mempertahankan fungsionalitas inti ketika Storage Access API ditolak?

Perlakukan identitas lintas situs sebagai peningkatan (enhancement). Dukungan anonim, konten bantuan, dan sesi merchant lokal tetap berfungsi; arahkan pengguna ke login tingkat atas hanya ketika data riwayat akun diperlukan.

Sumber publik

Pertanyaan terkait