Temu duga Frontend: Bagaimanakah anda mereka bentuk log masuk terbenam dengan Storage Access API?

Gesaan dan penetapan

Satu penyedia identiti dibenamkan dalam iframe pada banyak laman pelanggan. Pengguna yang telah log masuk sepatutnya melihat maklumat akaun, tetapi pelayar mungkin menyekat atau mempartisi kuki pihak ketiga. Reka bentuk aliran menggunakan Storage Access API tanpa menjadikan setiap pembenaman sebagai saluran penjejakan senyap.

Andaikan iframe boleh menavigasi ke halaman pihak pertamanya sendiri, laman peringkat atas mengawal kebenaran iframe dan pengguna mungkin menolak prom. Jawapan mesti merangkumi persetujuan, CSRF, fallback dan log keluar.

Perkara yang diuji oleh penemu duga

• Sama ada anda mengetahui bahawa akses storan dihadkan oleh kebenaran dan terhad pada bingkai (frame-scoped), bukannya suis kuki universal.
• Sama ada anda memerlukan pengaktifan pengguna dan sebab produk yang jelas sebelum meminta akses.
• Sama ada anda memisahkan keadaan butstrap terpartisi daripada keadaan sesi tanpa sekatan.
• Sama ada penolakan meninggalkan laluan berfungsi sama ada dalam keadaan log keluar atau berasaskan pengalihan.

Soalan penjelasan sebelum menjawab

1. Adakah widget memerlukan kesinambungan sesi rentas laman, atau bolehkah pengalihan mengembalikan kod kebenaran? Pengalihan mungkin mengelakkan permintaan akses kuki terbenam.
2. Adakah pengguna pernah melawat penyedia identiti sebagai pihak pertama dan menetapkan kukinya? Sesetengah pelayar memerlukan hubungan tersebut sebelum memberikan akses.
3. Apakah asal (origin) peringkat atas yang boleh membenamkan bingkai tersebut? Ini menentukan senarai izin (allowlist) Permissions-Policy.
4. Apakah data yang dipaparkan sebelum persetujuan diberikan? Paparan pra-akses tidak boleh membocorkan identiti akaun.

Rangka kerja jawapan 30 saat

"Saya menganggap Storage Access API sebagai keupayaan yang dimediasi oleh pengguna, bukan sebagai togol kuki fallback. Iframe bermula dengan keadaan terpartisi atau legap, meminta akses hanya selepas klik yang menerangkan manfaatnya dengan jelas, dan menyemak promise yang dikembalikan. Laman peringkat atas menghantar senarai izin Permissions-Policy yang terhad. Sekiranya ditolak, saya menggunakan pengalihan pihak pertama atau pengalaman log keluar. Setiap permintaan yang mengubah keadaan masih mempunyai perlindungan CSRF, dan widget boleh membatalkan sesinya serta kembali kepada keadaan neutral yang sama."

Perbincangan mendalam langkah demi langkah

1. Asingkan keadaan dan model ancaman

Sebelum akses, iframe mungkin mempunyai storan terpartisi atau tiada kuki langsung. Ia tidak boleh membuat kesimpulan tentang identiti pengguna daripada keadaan tersebut. Selepas requestStorageAccess() berjaya, dokumen terbenam boleh mengakses kuki pihak pertama tanpa sekatan mengikut dasar pelayar.

Keupayaan ini terhad kepada dokumen dan konteks pembenaman. Ia bukan bukti bahawa laman peringkat atas dipercayai, dan bukan juga pengganti untuk semakan asal, pertahanan CSRF, rekod persetujuan dan semantik log keluar.

2. Kawal permintaan di sebalik niat pengguna

Paparkan widget neutral dalam keadaan log keluar. Butang seperti "Log masuk untuk melihat butiran akaun" menghasilkan pengaktifan pengguna. Dalam pengendali tersebut, panggil API dan kendalikan penolakan sebagai cabang yang dijangkakan. Jangan minta akses semasa pemuatan halaman atau menggunakan bingkai tersembunyi untuk mereka-reka pengaktifan.

Aplikasi harus menerangkan data mana yang akan tersedia dan mengingati keputusan tersebut hanya setakat yang dibenarkan oleh dasar pelayar. Sesuatu permintaan boleh ditolak kerana pelayar menyekat kuki pihak ketiga, pengguna belum berinteraksi dengan laman tersebut sebagai pihak pertama, bingkai tidak mempunyai kebenaran dasar, atau konteks tidak layak.

3. Konfigurasikan sempadan pembenaman

Respons peringkat atas memiliki dasar tersebut. Benarkan hanya asal identiti dan hanya pada laluan yang membenamkan widget:

Permissions-Policy: storage-access=(self "https://id.example")

Iframe mesti disediakan dengan asal dan tetapan kotak pasir (sandbox) yang dijangkakan. Bingkai dalam kotak pasir memerlukan keupayaan same-origin yang sesuai, dan ketidakpadanan asal mesti ditutup demi keselamatan (fail closed). Anggap dasar tersebut sebagai senarai izin, bukan sebagai cara untuk memberikan akses kepada setiap pihak ketiga.

4. Wujudkan aliran pihak pertama dan terbenam

Jika pelayar memerlukan interaksi pihak pertama, widget akan membuka halaman pihak pertama pada asal identiti. Pengguna log masuk di sana, penyedia identiti menetapkan kuki pihak pertamanya, dan hasil jangka pendek yang terikat pada asal dikembalikan kepada pembenaman. Hasil tersebut tidak boleh menjadi token pembawa (bearer token) yang boleh diguna semula dalam URL.

Kembali ke iframe, minta akses storan selepas gerak isyarat pengguna, kemudian baca sesi melalui asal identiti. Pelayan masih menyemak asal peringkat atas, keadaan sesi dan token CSRF. Pemberian akses yang berjaya tidak memintas kebenaran akaun.

5. Reka bentuk penolakan, log keluar dan pengukuran

Apabila akses ditolak, pastikan widget kekal berguna: paparkan pautan log masuk, gunakan aliran pengalihan dan kembali, atau tawarkan halaman akaun pihak pertama. Jangan ulang prom secara berterusan. Log keluar mengosongkan sesi identiti dan menetapkan semula iframe kepada keadaan neutralnya; ia juga harus membatalkan sebarang paparan akaun yang dicache.

Ukur kejayaan pemberian akses, sebab penolakan jika tersedia, penyempurnaan pengalihan dan ralat paparan akaun mengikut pelayar dan asal pembenaman. Jangan sekali-kali merekod nilai kuki atau data akaun ke dalam log. Produk sepatutnya boleh membuang laluan API kemudian hari tanpa kehilangan aliran pengalihan.

Contoh jawapan berkualiti tinggi

Saya akan bermula dengan iframe tanpa nama yang hanya memaparkan elemen untuk log masuk. Selepas klik pengguna, ia meminta akses storan dan mengendalikan penolakan secara eksplisit. Halaman pembenam menghantar senarai izin Permissions-Policy yang terhad untuk asal identiti. Jika pelayar memerlukan interaksi pihak pertama, saya mengalihkan ke laman identiti, mewujudkan sesinya di sana, dan mengembalikan hasil yang terikat pada asal tanpa meletakkan token pembawa dalam URL.

Selepas akses diberikan, iframe membaca sesi pihak pertama, tetapi semakan asal, perlindungan CSRF, kebenaran dan log keluar masih terpakai. Jika akses ditolak, produk menggunakan log masuk pengalihan atau paparan log keluar dan tidak sekali-kali mengulang prom. Saya mengukur pemberian akses, penolakan, penyempurnaan pengalihan dan kegagalan mengikut pelayar dan asal, sambil mengekalkan fungsi fallback.

Kesilapan biasa

• Kesilapan: Memanggil API semasa pemuatan halaman → Sebab ia gagal: pelayar memerlukan niat pengguna dan pengguna tidak dapat memahami prom yang tiba-tiba → Penyelesaian: minta hanya selepas pengaktifan yang memberi penjelasan.
• Kesilapan: Menganggap kejayaan sebagai kebenaran kuki global → Sebab ia gagal: akses adalah terhad mengikut skop serta bergantung pada dasar dan pelayar → Penyelesaian: semak promise bagi setiap konteks terbenam.
• Kesilapan: Membenarkan setiap asal dalam Permissions-Policy → Sebab ia gagal: ini membesarkan permukaan penjejakan dan akses data → Penyelesaian: masukkan asal identiti ke dalam senarai izin pada laluan tertentu sahaja.
• Kesilapan: Meletakkan token sesi dalam URL pengalihan → Sebab ia gagal: URL bocor melalui sejarah, log dan perujuk (referrer) → Penyelesaian: gunakan hasil jangka pendek, sekali guna dan terikat pada asal.
• Kesilapan: Mengulang prom selepas penolakan → Sebab ia gagal: ini mewujudkan gelung yang menjengkelkan pengguna dan masih tidak dapat memaksa kebenaran → Penyelesaian: beralih kepada pengalihan atau fallback log keluar.

Soalan susulan dan respons

Bolehkah kuki terpartisi menggantikan Storage Access API?

Ia boleh menyokong sesi butstrap khusus untuk pembenaman, tetapi ia tidak menyediakan kesinambungan rentas laman yang sama seperti sesi pihak pertama tanpa sekatan. Pilih keadaan terpartisi apabila pengasingan boleh diterima; gunakan log masuk pengalihan apabila kesinambungan adalah penting dan permintaan akses tidak diingini.

Bagaimana jika iframe berada dalam kotak pasir (sandboxed)?

Sahkan bahawa kotak pasir mengekalkan asal dan keupayaan yang diperlukan oleh aliran tersebut. Jika ia menjadikan asal legap atau menyekat API, tutup demi keselamatan (fail closed) dan gunakan pengalihan pihak pertama. Jangan melemahkan kotak pasir secara menyeluruh semata-mata untuk membolehkan satu pembenaman berfungsi.

Adakah akses storan yang diberikan menghapuskan risiko CSRF?

Tidak. Iframe boleh menghantar kuki selepas akses diberikan, jadi titik akhir yang mengubah keadaan masih memerlukan pertahanan CSRF, pengesahan asal, tetapan kuki SameSite jika berkenaan dan kebenaran. Kebenaran storan hanya mengubah kebolehcapaian, bukannya niat permintaan.