Gesaan dan konteks yang sesuai
Sambungan ini memproses halaman semasa hanya selepas klik bar alat yang eksplisit, kemudian menghantar medan yang ditapis ke bahagian belakang (backend) yang terkawal. Ia tidak memerlukan imbasan latar belakang untuk setiap tab atau akses kepada kuki laman web sewenang-wenangnya. Cadangkan pemisahan kebenaran Manifest V3, aliran masa jalanan, penurunan prestasi secara anggun (graceful degradation), dan pelan pengesahan keluaran.
Soalan ini menguji sempadan kebenaran sambungan pelayar dan keselamatan produk. Backend tetap bertanggungjawab terhadap pengesahan (authentication), peminimuman data, dan kawalan audit; kebenaran sambungan tidak menggantikannya.
Perkara yang dinilai oleh penemu duga
Penemu duga ingin melihat keupayaan API, hos yang boleh dicapai, dan persetujuan pengguna dianggap sebagai keputusan yang berasingan. Chrome mendokumenkan kebenaran API, kebenaran hos, kebenaran pilihan, dan activeTab secara berasingan; semuanya mempengaruhi API yang tersedia, akses URL, amaran pemasangan, dan tingkah laku kemas kini.
Jawapan yang kukuh bermula dengan keupayaan terkecil, menerangkan sebab tindakan sekali pada halaman semasa tidak sepatutnya meminta <all_urls>, dan merangkumi penolakan, pembatalan, peningkatan taraf, dan telemetri. Sekadar menyatakan "tambah kebenaran" tidak menunjukkan kitaran hayat yang selamat.
Penjelasan untuk ditanya terlebih dahulu
- Adakah "halaman semasa" termasuk halaman khas, bingkai rentas asal (cross-origin frames), URL fail, atau tetingkap inkognito?
- Adakah API memerlukan dokumen penuh atau hanya medan yang dipilih pengguna?
- Adakah sambungan mesti memerhatikan perubahan halaman apabila pengguna belum mengkliknya?
- Pelaksanaan WebExtensions manakah yang mesti disokong?
- Bolehkah dasar perusahaan prapasang kebenaran, dan berapa lamakah medan audit boleh disimpan?
Rangka kerja jawapan 30 saat
"Saya akan membahagikan keupayaan kepada pembacaan halaman semasa, komunikasi backend, dan storan. Untuk tindakan sekali, saya akan menggunakan activeTab dan bukannya akses hos yang luas. Hanya ciri latar belakang rentas halaman yang sebenar yang mewajarkan optional_host_permissions yang tepat, diminta apabila pengguna mencetuskan ciri tersebut. Saya akan mengisytiharkan hanya kebenaran API yang diperlukan, berhenti apabila terdapat penolakan atau pembatalan, dan menyediakan sandaran salin manual. Sebelum peningkatan taraf, saya akan membezakan perbezaan kebenaran dan memantau akses serta aliran data baharu; pemulihan (rollback) akan membuang keupayaan baharu tersebut."
Jawapan mendalam langkah demi langkah
Langkah 1: Memetakan tingkah laku kepada kebenaran
Kebenaran API seperti storage dan scripting menyediakan keupayaan API sambungan; kebenaran hos mentakrifkan julat URL yang boleh berinteraksi dengannya. Manifes harus diterbitkan daripada setiap aliran data, bukan daripada ciri yang mungkin diperlukan kemudian.
Titik permulaan untuk memproses tab tempat pengguna mengklik sahaja ialah:
{
"manifest_version": 3,
"permissions": ["activeTab", "scripting", "storage"],
"optional_host_permissions": ["https://app.example.com/*"]
}Apabila skrip disuntik hanya ke dalam halaman semasa, activeTab memberikan akses sementara selepas tindakan pengguna; menutup atau menavigasi tab akan menamatkannya. Jika produk benar-benar memerlukan pemprosesan latar belakang untuk app.example.com, nilaikan kebenaran hos pilihan yang tepat dan bukannya menetapkan lalai kepada *://*/*.
Langkah 2: Mereka bentuk keizinan progresif
Minta hanya keupayaan teras yang berisiko lebih rendah pada masa pemasangan. Apabila pengguna mengklik "Analisis halaman ini," semak URL terhadap set yang dibenarkan. Jika hos tambahan diperlukan, panggil chrome.permissions.request() dan terangkan tujuan, skop, dan cara keluar daripada ciri tersebut.
const granted = await chrome.permissions.request({
origins: ["https://app.example.com/*"]
});
if (!granted) {
showManualCopyFallback();
return;
}Kejayaan bermakna keupayaan pelayar tersedia; ini tidak memintas pengesahan backend. Jika permintaan gagal, pengguna kemudian membatalkannya, atau dasar menyahdayakannya, kembali ke keadaan tanpa kebenaran tanpa gesaan berulang.
Langkah 3: Membezakan keadaan aktif, diberikan, dan boleh dibatalkan
Chromium membezakan kebenaran yang aktif pada masa ini daripada kebenaran yang diberikan secara historis. chrome.permissions.remove() mengurangkan keupayaan semasa, manakala set pemberian historis mungkin masih merekodkan kebenaran tersebut; permintaan kemudian mungkin tidak memaparkan gesaan yang sama lagi. Keputusan masa jalanan harus menggunakan apa yang tersedia pada masa ini, dan tetapan harus mendedahkan tindakan pembatalan yang jelas.
Sebelum setiap tugasan, panggil chrome.permissions.contains() untuk kebenaran sebenar. Semasa tugasan, dengar permissions.onRemoved; hentikan pembacaan dan pemuatan naik, kosongkan giliran keluar, dan rekodkan peristiwa perubahan kebenaran yang boleh diaudit.
Langkah 4: Mengendalikan penolakan, peningkatan taraf, dan pemulihan (rollback)
Apabila ditolak, bentangkan langkah seterusnya yang bukan teknikal seperti pemilihan manual, salin dan tampal, atau keluar. Jangan kelaskan penolakan sebagai ralat rangkaian atau cuba semula permintaan kebenaran di latar belakang.
Sebelum keluaran, hasilkan diff kebenaran yang meliputi API baharu, corak hos, padanan content-script, dan medan data. Chrome mungkin menyahdayakan sambungan apabila kemas kini meningkatkan keistimewaan dan menunggu persetujuan baharu. Menghapuskan kebenaran juga tidak semestinya memadamkan pemberian historis, jadi ujian pemulihan mesti merangkumi pengguna yang sebelum ini memberikannya dan pengguna yang tidak pernah memberikannya.
Langkah 5: Menjadikan kebenaran sebagai sempadan keselamatan yang boleh diuji
Skrip kandungan memproses input yang dikawal oleh halaman, jadi pengendali mesej harus mengesahkan penghantar, jenis mesej, dan saiz. Backend mesti mengesahkan semula identiti sambungan, identiti pengguna, sumber sasaran, dan senarai dibenarkan (allowlist) medan. Kebenaran hos mengehadkan keupayaan pelayar; ia tidak menjadikan halaman boleh dipercayai atau menghalang sambungan daripada menghantar data yang dibaca ke backend yang salah.
Sebelum pelancaran, bina matriks untuk pemasangan, benarkan, tolak, batal, tamat tempoh activeTab selepas navigasi, permintaan hos pilihan, kemas kini peningkatan kebenaran, pemulihan, penyahdayaan dasar perusahaan, pelayar yang tidak disokong, dan mod luar talian. Telemetri harus merekodkan kunci kebenaran, corak hos, hasil, dan versi, tidak sekali-kali teks halaman.
Contoh jawapan berkualiti tinggi
"Saya akan bermula dengan peta keupayaan dan aliran data. Oleh kerana tindakan bar alat hanya memproses halaman semasa, reka bentuk teras menggunakan activeTab, scripting, dan storage yang diperlukan, tanpa akses semua laman web. Hanya ciri latar belakang untuk app.example.com yang akan menggunakan kebenaran hos pilihan yang tepat, diminta apabila pengguna mencetuskannya. Saya akan menerangkan tujuan dan skop sebelum permintaan, menawarkan pemilihan manual selepas penolakan, dan mengelakkan gelung gesaan.
Sebelum setiap tugasan, saya akan menyemak kebenaran semasa dan mendengar pembatalan. Jika akses hilang, hentikan pembacaan, kosongkan giliran keluar, dan minta backend mengesahkan semula identiti dan sumber. Sebelum kemas kini, buat diff perubahan API, hos, dan skrip kandungan, kemudian uji penyahdayaan, persetujuan baharu, dan pemulihan. Akhir sekali, gunakan matriks kebenaran dan telemetri tanpa nama untuk mengesahkan tiada imbasan latar belakang, tiada suntikan rentas hos, tiada teks halaman dalam log, dan penurunan prestasi yang selamat untuk penolakan dan pembatalan."
Kesilapan biasa
- Meminta
<all_urls>secara lalai → meluaskan pendedahan pembacaan dan suntikan serta meningkatkan amaran → bermula denganactiveTab, kemudian nilai hos yang tepat untuk ciri berterusan. - Menganggap
optional_host_permissionssebagai persetujuan automatik → pengisytiharan bukan kelulusan pengguna → minta semasa ciri digunakan dan kendalikan penolakan. - Menyemak kebenaran hanya semasa pemasangan → pengguna boleh membatalkannya kemudian → semak sebelum kerja dan dengar penyingkiran.
- Menyemak perubahan kod sahaja semasa peningkatan taraf → kebenaran baharu boleh menyahdayakan sambungan → bandingkan set kebenaran dan uji pemberian sebelumnya.
- Menganggap kebenaran pelayar sebagai kebenaran backend → data masih boleh sampai ke akaun yang salah → sahkan semula identiti, sumber, dan medan pada bahagian pelayan.
- Memenuhi salinan keizinan dengan nama API → pengguna tidak dapat membentuk model risiko yang berguna → terangkan tujuan, skop, dan cara keluar.
Soalan susulan dan jawapan
Soalan susulan 1: Mengapa tidak meminta <all_urls> secara langsung?
Tindakan sekali pada halaman semasa tidak memerlukan akses latar belakang ke setiap laman web. activeTab memberikan keupayaan sementara selepas tindakan pengguna dan mengurangkan pendedahan jangka panjang; hanya keperluan rentas halaman berterusan yang jelas yang mewajarkan akses hos yang tepat.
Soalan susulan 2: Bagaimana dengan data yang telah dimuat naik apabila pengguna membatalkan akses?
Pembatalan menghalang akses pelayar kemudian tetapi tidak boleh menarik balik data yang telah meninggalkan peranti. Gunakan medan minimum, pengekalan singkat, dan kawalan pemadaman pada backend; kosongkan giliran keluar tempatan dan beritahu pengguna pemprosesan yang telah berlaku.
Soalan susulan 3: Mengapa perlu mengesahkan semula pada backend selepas kebenaran pilihan berjaya?
Kebenaran pelayar menyatakan bahawa sambungan boleh membaca halaman, bukan bahawa pengguna boleh mengakses sumber perniagaan. Backend mesti mengesahkan sesi, versi sambungan, sumber sasaran, dan senarai dibenarkan medan serta menolak permintaan yang lapuk atau tidak normal.
Soalan susulan 4: Bolehkah tingkah laku kebenaran Chrome dan Firefox dianggap sama?
Tidak. Walaupun berkongsi konsep WebExtensions, gesaan, corak padanan, dan sempadan masa jalanan mungkin berbeza. Uji pemasangan, permintaan, pembatalan, navigasi, dan peningkatan taraf pada setiap pelayar sasaran dan simpan perbezaan tersebut dalam matriks keserasian.