Temu Duga Frontend: Bagaimana Anda Memilih Antara Cookies, localStorage, sessionStorage, dan IndexedDB?

Soalan dan Kes Penggunaan

Sebuah aplikasi web pengurusan projek berbilang penyewa menyokong kedua-dua rendering bahagian pelayan (SSR) dan penyuntingan luar talian. Ia mempunyai empat jenis keadaan (state): pelayan mesti mengenali sesi log masuk merentas tab; keutamaan tema dan bahasa harus kekal untuk lawatan kemudian; draf borang berbilang langkah hanya milik tab semasa dan boleh hilang apabila tab tersebut ditutup; dan sehingga 10,000 rekod tugasan berstruktur dengan lampiran imej mesti menyokong pertanyaan luar talian, penyuntingan, dan penyegerakan selepas menyambung semula.

Peruntukkan data ini kepada cookies, localStorage, sessionStorage, dan IndexedDB. Terangkan bagaimana reka bentuk ini mengendalikan XSS dan CSRF, pengasingan asal (origin isolation), render SSR pertama yang konsisten, tab serentak, kuota dan pengusiran (eviction), peningkatan versi pangkalan data, log keluar dan pembersihan tempatan, serta penyegerakan luar talian.

Angka 10,000 rekod ialah kekangan senario yang memaksa perbincangan tentang pertanyaan berstruktur, capaian tak segerak (asynchronous access), dan protokol penyegerakan. Ia bukan jaminan kapasiti pelayar. Kemahiran teras adalah membuat keputusan ketahanan (persistence) frontend daripada semantik platform Web, jadi kategorinya ialah frontend.

Perkara yang Dinilai oleh Penemu Duga

Pertama, adakah calon bertanya siapa yang membaca data, berapa lama ia hidup, apakah bentuknya, apakah kos pendedahannya, dan sistem mana yang berwibawa sebelum memilih API? Jadual kapasiti yang dihafal tidak dapat menjelaskan SSR, pengesahan, atau konsistensi luar talian.

Kedua, bolehkah calon memisahkan ketahanan daripada keselamatan? Ketahanan tidak menjadikan localStorage sesuai untuk pengecam sesi. Skrip asal yang sama (same-origin scripts) boleh membaca dan mengubahnya, jadi muatan XSS boleh mencuri atau mengusik datanya. Kuki HttpOnly menghalang JavaScript daripada membaca pengecam sesi, tetapi ia tidak menghalang kod yang sudah berjalan dalam halaman daripada mengeluarkan permintaan yang disahkan.

Ketiga, adakah calon memahami kedua-dua sisi tingkah laku kuki? Pelayar menghantar kuki yang sepadan bersama permintaan, yang membantu rendering pelayan dan pengesahan. Penghantaran automatik yang sama ini memerlukan pertahanan CSRF. SameSite ialah satu bentuk pertahanan, bukan pengganti untuk pemeriksaan asal (origin checks), token CSRF, atau pengesahan semula untuk tindakan sensitif.

Keempat, bolehkah calon menganggap IndexedDB sebagai replika tempatan yang boleh gagal? Ia menyokong objek berstruktur tak segerak, indeks, dan blob, tetapi ia tidak menyegerak dengan pelayan secara automatik. Aplikasi bertanggungjawab ke atas kegagalan kuota, pengusiran, pembersihan, peningkatan yang disekat, dan konflik keserentakan.

Kelima, bolehkah calon menyediakan matriks kegagalan yang boleh dilaksanakan dan bukannya menganggap "ia kekal selepas muat semula" sebagai satu-satunya ujian?

Soalan Penjelasan Sebelum Menjawab

• Nilai manakah yang diperlukan pelayan untuk render pertama? Jika SSR mesti menghasilkan HTML untuk status log masuk, bahasa, atau tema yang betul, nilai-nilai tersebut memerlukan sumber yang boleh dibaca pelayan, atau produk mesti menerima perubahan selepas pemasangan klien (client mounting).
• Apakah model pengesahan yang digunakan? Jawapan ini mengandaikan sesi bahagian pelayan. Reka bentuk token API tulen juga memerlukan pengeluaran eksplisit, penggiliran, pembatalan, dan peraturan permintaan rentas tapak.
• Patutkah draf benar-benar berskop tab? Jika pengguna mengharapkan pemulihan selepas menutup tab atau penyambungan semula pada peranti lain, sessionStorage tidak lagi memenuhi keperluan; gunakan IndexedDB atau pelayan.
• Adakah data luar talian mengandungi maklumat sensitif? Peranti yang dikongsi, XSS, profil pelayar, dan sandaran tempatan mengubah perkara yang boleh ditulis ke cakera.
• Bagaimanakah 10,000 rekod ditanya dan dikemas kini? Pertanyaan mengikut projek, masa kemas kini, atau status penyegerakan menjadikan indeks dan transaksi lebih penting daripada capaian kunci-nilai mudah.
• Adakah pelayan merupakan punca kebenaran muktamad? Senario ini mengandaikan pelayan yang berwibawa dan salinan tempatan yang boleh dibina semula. Data yang dicipta di luar talian yang tidak boleh diganti memerlukan ketahanan, eksport, dan kawalan konflik yang lebih kukuh.
• Apakah yang dikira sebagai konflik? Penyuntingan peranti serentak mungkin menggunakan penolakan versi, penggabungan medan, atau keutamaan perniagaan. API storan tidak boleh memilih dasar tersebut untuk produk.
• Adakah log keluar mesti membuang data setiap penyewa? Apabila berbilang akaun berkongsi pelayar, pembersihan memerlukan ruang nama pengguna dan penyewa supaya pengguna seterusnya tidak dapat melihat replika pengguna sebelumnya.

Rangka Kerja Jawapan 30 Saat

"Saya memetakan data mengikut pembaca, jangka hayat, bentuk, kepekaan, dan punca kebenaran. Pengesahan menggunakan sesi pelayan dan kuki __Host- dengan Secure, HttpOnly, dan nilai SameSite yang sesuai, ditambah pertahanan CSRF. Keutamaan kecil yang tidak sensitif menggunakan localStorage, dengan nilai awal yang boleh dibaca pelayan apabila SSR memerlukannya. Draf tab tunggal pakai buang menggunakan sessionStorage. Rekod berstruktur dan imej menggunakan IndexedDB dengan indeks, transaksi, skema berversi, dan peti keluar (outbox). Pelayan kekal berwibawa; penyegerakan menggunakan versi dan kunci keidempotanan serta menyelesaikan konflik secara eksplisit. Anggap storan tempatan boleh dikosongkan dan boleh gagal akibat kuota, kemudian uji XSS, CSRF, berbilang tab, pengusiran, peningkatan yang disekat, penyambungan semula, dan pembersihan log keluar."

Perincian Langkah demi Langkah

Langkah 1: Bina matriks keputusan dengan lima soalan

Untuk setiap nilai, tanya lima soalan: adakah pembacanya ialah pelayan, tab semasa, atau setiap halaman asal yang sama; adakah jangka hayatnya satu render, satu tab, satu sesi pelayar, atau berbilang sesi; adakah data tersebut rentetan kecil, objek berstruktur, atau blob; sejauh manakah kemudaratan akibat pendedahan dan pengubahan; dan adakah pelayan atau peranti tempatan yang berwibawa?

Itu menghasilkan peruntukan awal untuk senario ini:

Login session       -> Server session + random identifier in an HttpOnly cookie
Theme and language  -> localStorage; add a server-readable initial value when SSR requires it
Single-tab draft    -> sessionStorage
Offline data/images -> IndexedDB + an application-level synchronization protocol

Ini bukan kedudukan mengikut kapasiti. Keupayaan penentu kuki di sini adalah mencapai pelayan bersama permintaan. Sempadan penentu sessionStorage ialah konteks penyemakan imbas peringkat teratas (top-level browsing context). IndexedDB menyediakan transaksi tak segerak, objek berstruktur, dan indeks.

Langkah 2: Jadikan pelayan berwibawa untuk pengesahan

Pelayar hanya menyimpan pengecam sesi berentropi tinggi dan berjangka hayat pendek. Keizinan sebenar, tamat tempoh, dan pembatalan berada pada pelayan. Tetapkan Secure, HttpOnly, nilai SameSite yang sesuai, dan sebaik-baiknya gunakan kuki __Host- tanpa Domain dan dengan laluan punca (root path). Log keluar, perubahan kata laluan, dan peristiwa risiko membatalkan sesi pelayan; memadamkan nilai pelayar sahaja tidak mencukupi.

HttpOnly mengurangkan capaian skrip terus kepada pengecam sesi, tetapi XSS asal yang sama masih boleh mengeluarkan tindakan yang disahkan daripada halaman aktif. Pengekodan output, CSP, dan pertahanan XSS yang lain tetap diperlukan, dan operasi berisiko tinggi boleh memerlukan pengesahan semula. Kerana kuki yang sepadan dihantar secara automatik, permintaan yang mengubah keadaan juga harus mengesahkan asal dan menggunakan token CSRF. SameSite tidak seharusnya menjadi satu-satunya kawalan.

Meletakkan pengecam sesi dalam localStorage menjadikannya boleh dibaca oleh mana-mana skrip asal yang sama yang berjaya dijalankan. Penyulitan bahagian klien bukan penyelesaian automatik: jika JavaScript halaman boleh memperoleh kunci penyahsulitan atau memanggil laluan penyahsulitan, XSS asal yang sama biasanya boleh melakukannya juga.

Langkah 3: Gunakan localStorage untuk keutamaan kecil dan tidak sensitif

localStorage berskop asal, menyimpan kunci dan nilai rentetan, kekal merentas sesi pelayar, dan mendedahkan operasi segerak. Keutamaan kecil seperti tema, bahasa, atau ketumpatan jadual adalah sesuai. Ia bukan kekal abadi: mengosongkan data tapak, menamatkan sesi penyemakan imbas peribadi, atau dasar pelayar boleh membuangnya.

Pelayan tidak boleh membaca localStorage secara terus. Jika bingkai SSR pertama mesti menggunakan bahasa atau tema yang betul, selaraskan keutamaan yang telah disahkan ke kuki yang boleh dibaca pelayan atau profil pengguna dan tentukan salinan mana yang menang. Jika nilai tersebut adalah klien sahaja, keluarkan lalai yang stabil dan tukar selepas pemasangan supaya HTML pelayan dan render klien pertama tidak bercanggah.

Elakkan menyimpan tatasusunan rekod yang besar dalam localStorage dan menghurai keseluruhan nilai JSON berulang kali. Pensirilan segerak dan capaian benang utama (main-thread) meningkat mengikut saiz set data, manakala model ini tidak mempunyai transaksi dan indeks IndexedDB.

Langkah 4: Letakkan hanya keadaan tab pakai buang dalam sessionStorage

sessionStorage dipisahkan mengikut asal dan konteks penyemakan imbas peringkat teratas. Ia bertahan terhadap muat semula dalam tab yang sama dan dikosongkan apabila tab atau tetingkap ditutup. Itu menjadikannya sesuai untuk nombor langkah tab semasa dan draf pakai buang, tetapi bukan untuk troli beli-belah merentas tab, pemulihan jangka panjang, atau keadaan merentas peranti.

Sempadan pembuka (opener boundary) mudah terlepas pandang. Halaman yang baru dibuka pada mulanya mungkin menerima salinan sessionStorage pembukanya; kedua-dua salinan itu kemudiannya berubah secara bebas. Jika draf tidak boleh disalin sama sekali, buang hubungan pembuka atau sertakan ID tika (instance ID) bagi setiap tab dalam draf dan sahkannya semasa pemulihan.

Skrip asal yang sama juga boleh membaca dan menulis sessionStorage. "Dikosongkan semasa tutup" bukan alasan untuk menyimpan kelayakan berjangka hayat panjang. Sebelum mengekalkan draf, kecualikan medan seperti kata laluan, data pembayaran, atau maklumat perubatan yang tidak sepatutnya ditulis ke cakera.

Langkah 5: Bina replika luar talian yang boleh dibina semula dalam IndexedDB

IndexedDB menawarkan permintaan tak segerak, transaksi, stor objek, kunci, indeks, dan storan blob. Ia sesuai dengan rekod berstruktur dan imej senario ini. Pisahkan data mengikut tenantId + userId, cipta stor objek untuk tugasan, lampiran, dan peti keluar (outbox), serta tambah hanya indeks yang diperlukan oleh pertanyaan sebenar seperti projek, masa kemas kini, dan status penyegerakan.

Gunakan versi pangkalan data yang eksplisit dan migrasi berperingkat. Membuka versi baharu boleh disekat oleh sambungan daripada tab lama. Tab tersebut harus mendengar versionchange, menutup sambungan lama mereka, dan meminta pengguna untuk memuat semula. Halaman baharu harus mengendalikan blocked dan bukannya tergantung selama-lamanya semasa pemulaan.

IndexedDB ialah pangkalan data tempatan, bukan perkhidmatan penyegerakan. Penulisan yang berjaya bermakna transaksi tempatan telah dikomit. Aplikasi masih merekodkan versi tempatan dan pelayan, ID operasi, dan status penyegerakan, serta menjadikan percubaan semula sebagai idempoten.

Langkah 6: Reka bentuk penyegerakan luar talian dan konflik rentas tab secara eksplisit

Komit setiap perubahan perniagaan luar talian dan entri peti keluarnya dalam satu transaksi IndexedDB. Selepas menyambung semula, pekerja memuat naik mengikut ID operasi. Pelayan menyahduplikasi dengan kunci keidempotanan dan membandingkan versi rekod. Hanya selepas pengesahan barulah transaksi lain harus mengemas kini versi pelayan dan membuang item peti keluar. Ini mengelakkan perubahan rekod sambil kehilangan operasi yang belum selesai.

Dasar konflik datang daripada keperluan perniagaan. Keutamaan berisiko rendah mungkin menggunakan pemenang penulisan terakhir (last writer wins); status tugas boleh menolak ketidakpadanan versi dan meminta pengguna untuk menggabungkan; perubahan kewangan atau keizinan mungkin melarang komit luar talian. Peristiwa storage atau BroadcastChannel boleh memberitahu tab lain untuk memuat semula data, tetapi pemberitahuan bukan kunci (lock) dan tidak boleh menggantikan transaksi IndexedDB atau pemeriksaan versi pelayan. Peristiwa storage tidak mencetuskan dalam dokumen yang melakukan penulisan.

Langkah 7: Anggap kuota, pengusiran, dan pembersihan sebagai kegagalan biasa

Kuota pelayar berbeza-beza mengikut pelayar, peranti, dan mod. IndexedDB biasanya menggunakan storan usaha terbaik (best-effort storage), yang boleh dikosongkan oleh pengguna dan boleh diusir oleh pelayar di bawah tekanan storan. Penulisan juga boleh gagal kerana kekurangan kuota. Gunakan anggaran storan untuk memerhatikan penggunaan, minta ketahanan secara berhati-hati untuk data yang tidak boleh diganti, dan sentiasa kendalikan kegagalan transaksi dan kuota.

Dasar ini harus merangkumi had lampiran, pembersihan yang paling kurang digunakan baru-baru ini (least-recently-used), pemampatan atau pemadaman versi lama yang disahkan pelayan, dan keadaan boleh pulih "ruang tempatan penuh". Semasa log keluar, batalkan sesi pelayan terlebih dahulu, kemudian tutup sambungan pangkalan data dan alih keluar data IndexedDB, keutamaan, dan draf pengguna serta penyewa tersebut. Beritahu tab lain juga. Pemadaman tempatan tidak boleh menggantikan pembatalan pelayan.

Langkah 8: Sahkan sempadan dengan matriks kegagalan

Uji render SSR pertama dan penghidratan; muat semula, salin, buka baharu, dan tutup tab; log keluar daripada tab lain; skop yang boleh dibaca skrip di bawah XSS; permintaan rentas tapak yang mengubah keadaan; penyemakan imbas peribadi; pembersihan data tapak; kehabisan kuota; tab lama yang menyekat peningkatan pangkalan data; dua tab menyunting secara serentak; percubaan semula luar talian, respons pendua dan tidak mengikut urutan, serta konflik; dan menukar penyewa tanpa mendedahkan data lama.

Lulus bermakna lebih daripada sekadar "data kekal." Pengesahan boleh dibatalkan, nilai sensitif tidak didedahkan kepada JavaScript, draf mematuhi sempadan tab, penulisan luar talian tidak boleh kehilangan entri peti keluarnya, penyegerakan pendua tidak menduplikasi kesan perniagaan, peningkatan berjaya dipulihkan, kegagalan kuota mempunyai pelan sandaran, dan pelayan boleh membina semula replika tempatan.

Contoh Jawapan Berkualiti Tinggi

"Saya bermula dengan pembaca, jangka hayat, model data, sempadan kepercayaan, dan punca kebenaran dan bukannya kapasiti. Pelayan dan setiap tab memerlukan sesi log masuk, jadi sesi sebenar berada pada pelayan dan pelayar memegang kuki __Host- dengan Secure, HttpOnly, dan nilai SameSite yang sesuai. Ini mengurangkan capaian token JavaScript, tetapi XSS masih boleh bertindak sebagai pengguna, dan penghantaran kuki automatik masih memerlukan token CSRF, pemeriksaan asal, dan pengesahan semula untuk tindakan sensitif.

Tema dan bahasa ialah keutamaan kecil yang tidak sensitif, jadi ia menggunakan localStorage. Jika SSR memerlukannya pada bingkai pertama, saya menyegerakkan keutamaan yang disahkan dan boleh dibaca pelayan serta menentukan salinan yang berwibawa. Draf borang pakai buang tab semasa menggunakan sessionStorage: muat semula memulihkannya dan tutup membuangnya. Saya juga mengambil kira halaman baharu yang pada mulanya menyalin nilai pembuka.

10,000 tugas dan imej menggunakan IndexedDB. Pangkalan data dipisahkan mengikut pengguna dan penyewa serta menggunakan skema berversi, indeks, dan transaksi. Setiap suntingan perniagaan dan entri peti keluar dikomit bersama. Semasa menyambung semula, klien memuat naik dengan ID operasi yang idempoten, dan pelayan membandingkan versi rekod sebelum mengesahkan atau mengembalikan konflik. Pemberitahuan rentas tab hanya menyebabkan muat semula; transaksi tempatan dan versi pelayan menyediakan ketepatan.

Saya menganggap semua storan tempatan sebagai boleh dikosongkan, boleh gagal akibat kuota, dan tersedia untuk skrip asal yang sama. Saya mengendalikan ralat kuota, membersihkan lampiran yang boleh dibina semula, menutup sambungan lama semasa peningkatan, dan membatalkan sesi pelayan sebelum membersihkan ruang nama tempatan pengguna semasa log keluar. Matriks ujian saya merangkumi SSR dan penghidratan, salinan tab, XSS, CSRF, kuota, pengusiran, peningkatan yang disekat, penyuntingan serentak, percubaan semula luar talian, dan pertukaran penyewa."

Kesilapan Biasa

• Memilih secara mekanikal daripada jadual kapasiti → terlepas pandang pembaca pelayan, sempadan tab, dan punca kuasa → gunakan matriks lima dimensi terlebih dahulu.
• Meletakkan pengecam sesi dalam localStorage → XSS asal yang sama boleh membaca dan mengeksfiltrasi data tersebut → gunakan kuki terlindung yang disandarkan oleh sesi pelayan dan teruskan mencegah XSS.
• Menganggap HttpOnly menghapuskan XSS → skrip berniat jahat masih boleh melakukan tindakan yang disahkan → pisahkan pertahanan kecurian token daripada pertahanan tindakan.
• Hanya menggunakan SameSite untuk CSRF → dasar pelayar, jenis permintaan, dan aliran perniagaan masih mempunyai sempadan → gabungkan token, pemeriksaan asal, dan pengesahan semula.
• Menjadikan pelayan bergantung pada localStorage → SSR tidak boleh membaca storan pelayar → sediakan nilai awal yang boleh dibaca pelayan atau terima perubahan selepas pemasangan.
• Mengandaikan tab baharu sentiasa mempunyai sessionStorage yang kosong → pembuka boleh menyediakan salinan awal → buang pembuka atau tambah ID tika tab.
• Meletakkan tatasusunan besar dalam localStorage → memerlukan penghuraian segerak, penulisan semula keseluruhan nilai, dan tidak mempunyai transaksi berindeks → gunakan IndexedDB.
• Mengandaikan IndexedDB menyegerak secara automatik → komit tempatan dan pengesahan pelayan ialah peristiwa yang berbeza → laksanakan peti keluar, keidempotanan, versi, dan dasar konflik.
• Menganggap pemberitahuan rentas tab sebagai kunci teragih (distributed lock) → mesej boleh tertangguh dan tidak boleh memutuskan konflik pelayan → muat semula selepas pemberitahuan dan gunakan transaksi serta versi untuk ketepatan.
• Mengandaikan data tempatan adalah kekal → pembersihan, pengusiran, mod peribadi, dan kuota boleh membuangnya → jadikan ia boleh dibina semula dan kendalikan kegagalan penulisan.
• Hanya mengosongkan kuki semasa log keluar → IndexedDB dan keutamaan boleh bocor ke dalam akaun seterusnya → batalkan pada bahagian pelayan, kemudian bersihkan setiap replika tempatan pengguna dan penyewa.

Soalan Susulan dan Maklum Balas

Susulan 1: Bolehkah saya menyulitkan token dan meletakkannya dalam localStorage?

Jika JavaScript halaman boleh memperoleh kunci atau memanggil laluan penyahsulitan, skrip berniat jahat asal yang sama yang berjaya dijalankan biasanya boleh berbuat demikian juga. Itu tidak menangani kecurian sesi daripada XSS dalam senario ini. Sempadan yang lebih kukuh ialah sesi pelayan dengan kuki HttpOnly ditambah pencegahan XSS, perlindungan CSRF, penggiliran, dan pembatalan. Penyulitan bahagian klien hanya menangani ancaman apabila kuncinya berada di luar permukaan serangan yang sama.

Susulan 2: Bagaimana jika draf mesti kekal selepas menutup tab?

Keperluan jangka hayat telah berubah, jadi sessionStorage tidak lagi sesuai. Draf tidak sensitif yang hanya memerlukan pemulihan tempatan boleh menggunakan IndexedDB. Draf yang mesti merentas peranti atau tidak boleh hilang harus disegerakkan ke pelayan. Kedua-dua pilihan memerlukan tempoh pengekalan, pengasingan pengguna dan penyewa, serta peraturan yang mengecualikan medan sensitif daripada ketahanan.

Susulan 3: Bagaimana jika dua tab menyunting tugas luar talian yang sama?

Simpan versi pelayan dan semakan tempatan pada setiap rekod dan gunakan transaksi IndexedDB untuk setiap penulisan. BroadcastChannel atau pemberitahuan perubahan data memberitahu tab lain untuk memuat semula, tetapi pelayan tetap melakukan kemas kini bersyarat terhadap versi tersebut. Selepas konflik, perniagaan memilih penggabungan medan, prom pengguna, atau penolakan. Tab terakhir yang menerima mesej tidak boleh menjadi punca kebenaran.

Susulan 4: Bagaimana jika tab lama menyekat peningkatan IndexedDB?

Sambungan lama mendengar versionchange, menutup sambungan, dan menggesa untuk muat semula. Halaman baharu mengendalikan blocked dengan keadaan yang boleh dipulihkan dan bukannya menunggu selama-lamanya. Migrasi adalah berperingkat, idempoten, dan bertolak ansur dengan data sejarah separa. Sebelum pelepasan, pastikan tab versi lama kekal bersambung dan buka versi baharu untuk mengesahkan penutupan, pemesejan, dan migrasi.

Susulan 5: Bagaimanakah aplikasi harus merosot nilainya (degrade) apabila storan pelayar penuh?

Kendalikan ralat kuota dan transaksi, hentikan pengesahan cache lampiran baharu terlebih dahulu, dan alih keluar lampiran lama serta versi yang disahkan pelayan yang boleh dibina semula. Peti keluar yang belum disegerakkan mempunyai keutamaan yang lebih tinggi daripada cache yang boleh dimuat turun. Jika ruang masih tidak mencukupi, beritahu pengguna untuk menyambung semula dan menyegerak atau mengosongkan ruang; jangan sekali-kali melaporkan simpanan senyap sebagai berjaya.

Susulan 6: Apakah susunan log keluar yang betul?

Mula-mula minta pelayan membatalkan sesi semasa supaya kuki yang disalin dan tab yang masih terbuka turut kehilangan capaian. Kemudian beritahu tab lain, hentikan kerja penyegerakan, tutup sambungan IndexedDB, alih keluar pangkalan data, draf, dan keutamaan untuk pengguna dan penyewa, dan akhirnya masuk ke UI yang telah dilog keluar. Jika permintaan rangkaian gagal, jangan paparkan log keluar palsu tempatan sahaja sebagai disahkan; sekat kerja selanjutnya dan tunjukkan bahawa pembatalan sedang menunggu keputusan.