Advanced · Level 19: Security BasicsAdvanced60 menitBahasa Indonesia

Permission UI

Membuat UI yang mencerminkan capability user tanpa menjadikan button visibility sebagai security enforcement.

StatusMemuat progres

ProgresMemuat...

...

Memuat progres

Menyiapkan langkah berikutnya

Tujuan belajar

Menjelaskan peran Permission UI untuk clarity dan recovery
Membedakan hidden/disabled/read-only state dari server authorization
Memilih copy saat action tidak tersedia bagi user
Mendeteksi role flag client yang bukan bukti permission

PermissionsAuthorizationUXAccess DeniedRLS

Isi lesson

6 blok

1.
UI menjelaskan access, bukan memutuskan accessBelum selesaiWajib
2.
Role UI dan enforcement data dipisahkanBelum selesaiWajib
3.
Coding practiceBelum selesaiWajib
4.
Cek pemahamanBelum selesaiWajib
5.
Client permission bukan source of truthBelum selesaiWajib
6.
RingkasanBelum selesaiWajib

UI menjelaskan access, bukan memutuskan access

Wajib

Permission UI memberi context: learner dapat melihat course, editor dapat mengubah course, dan user tanpa access melihat penjelasan read-only atau request-access path. Hiding action dapat mengurangi kebingungan; disabled action dengan alasan dapat membantu ketika user perlu tahu capability yang hilang. Pilihan UX bergantung context product.

Namun role flag di browser, hidden menu, disabled button, atau client-side condition bukan enforcement. User dapat mengubah route, memanggil endpoint di luar UI, atau mendapat state client stale. API server, service layer, dan database policy seperti RLS tetap memeriksa identity serta permission pada data/action penting. Jika server menolak request, UI perlu menampilkan access denied yang jujur, bukan memalsukan success.

Bagian ini memengaruhi progres lesson.

Role UI dan enforcement data dipisahkan

Wajib

const coursePermissionUi = {
  canEditCourse: "show edit action",
  cannotEditCourse: "show read-only explanation or request-access path",
  clientRoleHint: "helps UI decisions only",
  serverEnforcement: "verify permission for every protected data action",
};

clientRoleHint dapat membuat UI relevan, tetapi serverEnforcement memeriksa request yang mencapai data. Jangan infer sensitive permission dari profile field yang dapat diubah user. Jika project memakai Supabase browser access, RLS menjadi enforcement database, bukan button state.

Bagian ini memengaruhi progres lesson.

Coding practice

WajibDibuka di workspace khusus

Design course permission UI boundary

Map clarity UI dan server enforcement pada capability editor tanpa client role access control.

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.

4 cek otomatis4 checklist

Belum selesaiBuka practice

Cek pemahaman

WajibJawab dulu

Cek pemahaman singkat

Apa respons UI yang tepat saat server menolak update course dengan 403?

Progres lesson naik setelah jawaban benar.

Kesalahan umum

Wajib

Client permission bukan source of truth

Client state bisa stale, dimodifikasi, atau tidak lengkap. Jangan memakai flag isAdmin yang dapat diubah user sebagai bukti backend boleh melakukan action. Untuk issue permission, catat resource, action, endpoint/method, status, environment, dan expected versus actual UI. Jangan mengubah local client state untuk melewati denial.

Bagian ini memengaruhi progres lesson.

Ringkasan

Wajib

Permission UI memberi clarity, guidance, dan recovery bagi user.
Hidden/disabled action serta role hint client bukan enforcement security.
Server/API/RLS tetap memverifikasi permission pada protected data/action.
403 harus menjadi access denied UI yang jujur, bukan fake success atau workaround.
Berikutnya, kita melihat apa yang dapat dan tidak dapat dilindungi auth guard frontend.

Bagian ini memengaruhi progres lesson.

Langkah berikutnya

Selesaikan bagian penting lesson ini

Lanjutkan blok wajib berikutnya: UI menjelaskan access, bukan memutuskan access.

Memuat progres Review module