Token Storage
Membaca trade-off cookie, memory, dan persistent browser storage tanpa menganggap ada satu pilihan universal.
Tujuan belajar
- Menjelaskan bahwa lokasi token/session evidence memengaruhi risk dan UX
- Membedakan HttpOnly cookie, in-memory state, dan persistent browser storage
- Memahami bahwa client decode bukan authorization check
- Menentukan pertanyaan architecture sebelum memilih storage
Isi lesson
6 blok- 1.Storage choice adalah contract security dan experienceBelum selesaiWajib
- 2.Bandingkan property, bukan jawaban universalBelum selesaiWajib
- 3.Coding practiceBelum selesaiWajib
- 4.Cek pemahamanBelum selesaiWajib
- 5.Jangan masukkan token ke observabilityBelum selesaiWajib
- 6.RingkasanBelum selesaiWajib
Storage choice adalah contract security dan experience
WajibTidak ada satu lokasi token yang otomatis paling aman untuk setiap application. HttpOnly cookie dikelola browser dan JavaScript tidak dapat membaca valuenya, tetapi mutation berbasis cookie tetap perlu CSRF-aware server contract. In-memory state hilang saat refresh sehingga mengurangi persistence di browser, tetapi app perlu session recovery flow. Persistent browser storage mudah dipakai untuk beberapa data UI, namun value di sana dapat dibaca JavaScript yang berjalan di origin aplikasi sehingga penggunaan token memerlukan risk review yang jelas.
Token atau session evidence tidak boleh diperlakukan seperti data profile. Jangan taruh di URL, analytics event, error report, screenshot, local draft, atau console log. Decode token di client bukan proof permission untuk resource saat ini; server/provider tetap memverifikasi session, token, dan policy sebelum memberi data atau menjalankan action.
Bagian ini memengaruhi progres lesson.
Bandingkan property, bukan jawaban universal
Wajibconst sessionStorageTradeoffs = {
httpOnlyCookie: "browser-managed; JavaScript cannot read value; needs CSRF-aware server contract",
inMemory: "clears on refresh; avoids persistent browser token storage",
persistentBrowserStorage: "JavaScript-readable; requires explicit risk review",
};Object ini bukan configuration auth dan tidak menyimpan token. Pilihan nyata bergantung provider, architecture, session refresh behavior, cross-site need, dan backend enforcement. Jangan mengubah storage berdasarkan satu tutorial tanpa memahami seluruh boundary.
Bagian ini memengaruhi progres lesson.
Coding practice
WajibDibuka di workspace khususExplain course token storage trade-offs
Nyatakan trade-off storage tanpa membuat atau menyimpan token.
Tujuan awal: Fokus di tab TS.
Practice ini dibuka di workspace khusus. Buka practice untuk memakai editor, preview, dan cek otomatis.
Tombol selesai aktif setelah semua validasi wajib lolos.
Cek pemahaman
WajibJawab duluCek pemahaman singkat
Mengapa decode token di browser tidak cukup untuk membolehkan action admin?
Progres lesson naik setelah jawaban benar.
Catatan penting
WajibJangan masukkan token ke observability
Saat debugging auth, catat endpoint, method, status, origin, environment, cookie attributes tanpa value, dan UI symptom. Jangan menempelkan token atau session ID ke chat, issue, analytics, console, atau screen recording. Jika value terekspos, perlakukan sebagai security incident dan ikuti process team.
Bagian ini memengaruhi progres lesson.
Ringkasan
Wajib- Token storage memengaruhi security boundary, session UX, dan recovery behavior.
- HttpOnly cookie, memory, dan persistent storage mempunyai trade-off berbeda.
- Client decode bukan authorization check; server/provider membuat keputusan access.
- Token dan session value tidak boleh masuk URL, log, analytics, atau issue.
- Berikutnya, kita membaca attributes cookie sebagai bagian dari session contract.
Bagian ini memengaruhi progres lesson.
Langkah berikutnya
Selesaikan bagian penting lesson ini
Lanjutkan blok wajib berikutnya: Storage choice adalah contract security dan experience.