Membuat Policy Laravel 13.x: Gate, Policy, dan Otorisasi Resource

Seorang pengguna sudah login dan membuka halaman edit artikel. Apakah itu berarti ia boleh mengubah artikel tersebut? Belum tentu. Login menjawab siapa pengguna itu. Otorisasi menjawab tindakan apa yang boleh ia lakukan terhadap resource tertentu.

Perbedaan ini penting ketika aplikasi memiliki data milik banyak pengguna. Autentikasi dapat mengenali Rina, tetapi aplikasi masih harus memutuskan apakah Rina boleh memperbarui Post yang sedang dibuka. Dokumentasi otorisasi Laravel 13.x menempatkan keputusan seperti ini pada dua mekanisme utama: gate dan policy.

Gate atau policy: lihat letak aturannya

Gate adalah pemeriksaan berbasis closure. Ia cocok untuk kemampuan yang tidak berpusat pada satu model atau resource, misalnya membuka dashboard administrator.

Policy adalah class yang mengelompokkan aturan otorisasi di sekitar model atau resource. Jika pertanyaannya berbunyi “bolehkah pengguna ini memperbarui post tersebut?”, policy biasanya memberi tempat yang lebih jelas untuk aturan view, update, atau delete.

Keduanya tidak saling meniadakan. Satu aplikasi dapat memakai gate untuk kemampuan global dan policy untuk tindakan terhadap resource. Aturan praktisnya:

• gunakan gate ketika kemampuan tidak terikat pada instance model tertentu;
• gunakan policy ketika keputusan membutuhkan pengguna, tindakan, dan model atau resource yang sedang dituju.

Pilihan ini bukan sistem role/permission yang lengkap dan bukan jaminan keamanan. Ia hanya menentukan tempat pemeriksaan otorisasi dikelola.

Contoh konseptual: hanya pemilik yang boleh memperbarui post

Anggap aplikasi memiliki model Post dengan kolom user_id. Aturan kecilnya: pengguna boleh menjalankan tindakan update hanya ketika ID pengguna sama dengan user_id pada post.

Contoh berikut mengikuti dokumentasi Laravel 13.x dan belum dijalankan pada proyek lokal. Mulai dengan membuat policy untuk model Post:

php artisan make:policy PostPolicy --model=Post

Perintah tersebut membuat policy dengan contoh method untuk tindakan terhadap resource. Untuk alur ini, inti PostPolicy dapat dibatasi pada pemeriksaan update:

<?php

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }
}

Method itu menerima pengguna yang sedang diautentikasi dan Post yang akan diubah. Nilai true mengizinkan tindakan; false menolaknya. Aturan kepemilikan ini sengaja sederhana agar alurnya terlihat. Aplikasi nyata mungkin membutuhkan status post, keanggotaan organisasi, atau kondisi lain yang harus dirumuskan dan diuji sesuai kebutuhan setempat.

Laravel mendokumentasikan penemuan policy otomatis ketika lokasi dan nama class mengikuti konvensi. Model App\Models\Post dapat dipasangkan dengan App\Policies\PostPolicy. Jika struktur aplikasi berbeda, policy perlu didaftarkan atau aturan penemuannya disesuaikan. Jangan menganggap policy ditemukan otomatis tanpa memeriksa struktur proyek.

Pemeriksaan kemudian harus dilakukan sebelum logika perubahan resource berjalan. Salah satu bentuk yang didokumentasikan adalah:

use App\Models\Post;
use Illuminate\Support\Facades\Gate;

public function update(Post $post)
{
    Gate::authorize('update', $post);

    // Lanjutkan validasi dan perubahan data setelah otorisasi lolos.
}

Pada alur tersebut, ability update dan instance Post mengarahkan pemeriksaan ke policy yang sesuai. Contoh berhenti setelah titik otorisasi; ia tidak mengajarkan route, validasi, penyimpanan data, atau endpoint API.

Letakkan pemeriksaan di batas server

Laravel juga menyediakan middleware can dan helper lain untuk menjalankan pemeriksaan sebelum tindakan diproses. Pilih titik yang mudah dilihat dan konsisten dengan struktur aplikasi, tetapi pertahankan pemeriksaan pada sisi server.

Tombol edit boleh disembunyikan dengan directive seperti @can agar antarmuka lebih jelas. Namun, menyembunyikan tombol tidak menggantikan otorisasi server. Request masih dapat dibuat tanpa melewati antarmuka tersebut. Karena itu, policy atau gate tetap perlu diperiksa pada jalur yang menerima tindakan.

Artikel API Laravel yang sudah ada membahas route, validasi, autentikasi Sanctum, dan HTTP test. Artikel ini sengaja tidak mengulang alur itu: middleware autentikasi memastikan identitas tersedia, sedangkan policy pada contoh ini memutuskan apakah identitas tersebut boleh mengubah satu resource.

Apa yang terjadi ketika akses ditolak?

Menurut dokumentasi Laravel 13.x, Gate::authorize(...) melempar AuthorizationException ketika pemeriksaan gagal. Laravel mengubah exception tersebut menjadi respons HTTP 403 secara default.

Gate dan policy juga dapat mengembalikan objek Response untuk membawa pesan penolakan. Dokumentasi menyediakan cara mengubah status, termasuk pola “not found”. Gunakan perubahan status hanya jika kontrak aplikasi memang membutuhkannya. Jangan memilih 404 sekadar untuk menyembunyikan masalah desain akses, dan jangan menampilkan pesan yang membocorkan informasi sensitif tentang resource atau pengguna lain.

Batas artikel ini berhenti pada perilaku framework. Kode contoh belum dijalankan, tidak menguji kasus pengguna tamu, tidak memeriksa kebocoran data, dan tidak membuktikan bahwa aturan aplikasi sudah lengkap.

Keputusan praktis

Gunakan gate untuk kemampuan global yang tidak terikat pada model tertentu. Gunakan policy ketika keputusan berpusat pada tindakan terhadap resource, seperti melihat, memperbarui, atau menghapus sebuah Post. Setelah memilih tempat aturannya, jalankan pemeriksaan di sisi server sebelum perubahan data, lalu uji setidaknya jalur diizinkan dan ditolak pada proyek Anda sendiri.

Untuk contoh di atas, policy adalah pilihan yang masuk akal karena keputusan membutuhkan dua hal sekaligus: pengguna yang sedang login dan post yang hendak diperbarui. Yang tetap harus Anda validasi pada proyek Anda adalah penemuan policy, route model binding, aturan bisnis, perilaku untuk tamu, kontrak respons penolakan, dan test pada konfigurasi aplikasi yang sebenarnya.