Pengaturan Hak Akses Fleksibel & Anti-Kecurangan | User Role Management

Tantangan & Kebutuhan Pengguna

Pada banyak aplikasi backoffice, aturan izin sering kali ditulis kaku (hardcoded) berdasarkan nama role di dalam komponen tampilan. Pendekatan tersebut berisiko tinggi: setiap kali organisasi menambah jabatan baru, developer harus mengubah kode sumber dan melakukan deploy ulang. Lebih berbahaya lagi, jika admin biasa diberi akses ke halaman pengaturan role tanpa validasi anti-eskalasi, ia dapat menyuntikkan izin yang melampaui wewenangnya sendiri ke role lain.

Seorang pengguna tidak boleh pernah bisa memberikan hak akses yang ia sendiri tidak miliki kepada role mana pun, dan tidak boleh mengubah hak akses role yang sedang ia gunakan sendiri.

Solusi & Cara Kerja

Sistem ini memisahkan identitas Role dari daftar Feature melalui tabel relasi `role_permissions` dengan empat kolom boolean granular (`is_read`, `is_add`, `is_edit`, `is_delete`). Pembacaan matriks izin di-cache per request menggunakan React `cache()` pada fungsi `getPermissionMap()`, lalu ditegakkan di 4 titik: Edge Proxy (`proxy.ts`), Server Page Guard (`requirePageAccess`), Server Action & API Guard (`requirePermission`), serta Client UI (`PermissionContext`). Saat matriks izin disimpan, layanan `saveRolePermissions` menjalankan transaksi atomik yang memverifikasi bahwa setiap aksi yang diberikan memang tersedia pada feature terkait dan dimiliki oleh aktor penyimpan.

Berikut adalah implementasi asli validasi anti-eskalasi dan penyimpanan matriks izin di dalam `modules/dashboard/role-permission/role-permission.service.ts`:

Detail & Hal yang Diperhatikan

Pencegahan Self-Privilege Modification: Admin non-Super Admin dilarang memodifikasi izin dari role yang sedang ia gunakan sendiri agar tidak mengunci diri sendiri atau menaikkan wewenangnya.
Filter Intersection pada `availableActions`: Sebuah feature seperti Audit Log hanya mendukung aksi `read`. Meskipun baris database memiliki kolom `is_delete`, fungsi `getPermissionMap` selalu mengiris (`filter`) nilai boolean dengan `feature.availableActions`.
Deduplikasi Query per Request: Pembacaan peta izin dibungkus `cache()` dari React sehingga meskipun dipanggil di layout, halaman, dan komponen server sekaligus, kueri ke PostgreSQL hanya dieksekusi satu kali per siklus request.

Tantangan & Kebutuhan Pengguna

Seorang pengguna tidak boleh pernah bisa memberikan hak akses yang ia sendiri tidak miliki kepada role mana pun, dan tidak boleh mengubah hak akses role yang sedang ia gunakan sendiri.

Solusi & Cara Kerja

Berikut adalah implementasi asli validasi anti-eskalasi dan penyimpanan matriks izin di dalam `modules/dashboard/role-permission/role-permission.service.ts`:

Detail & Hal yang Diperhatikan

Pencegahan Self-Privilege Modification: Admin non-Super Admin dilarang memodifikasi izin dari role yang sedang ia gunakan sendiri agar tidak mengunci diri sendiri atau menaikkan wewenangnya.
Filter Intersection pada `availableActions`: Sebuah feature seperti Audit Log hanya mendukung aksi `read`. Meskipun baris database memiliki kolom `is_delete`, fungsi `getPermissionMap` selalu mengiris (`filter`) nilai boolean dengan `feature.availableActions`.
Deduplikasi Query per Request: Pembacaan peta izin dibungkus `cache()` dari React sehingga meskipun dipanggil di layout, halaman, dan komponen server sekaligus, kueri ke PostgreSQL hanya dieksekusi satu kali per siklus request.