Apakah Anda benar-benar membutuhkan kepercayaan atau izin laravel untuk mengimplementasikan otorisasi Anda?

"Jadi ... aku butuh otorisasi sederhana. Beberapa jenis peran admin, dan mungkin peran editor / moderator. Sekarang google itu. Oh! Sudah ada paket yang siap pakai untuk laravel! zizaco / titipan , spatie / izin-lara dan lainnya! Ayo pilih beberapa! ”

Begitulah semuanya terjadi. Kemudian migrasi paket menambahkan 5 label ke database untuk menyimpan peran, izin, dan hubungannya. Semua aturan otorisasi, seperti peran 'admin' dan 'editor' dapat melakukan 'edit posting' , disimpan dalam tabel ini. Biasanya, proyek memiliki banyak salinan database. Salinan pengembang, basis uji dan produksi. Akibatnya, semua aturan otorisasi ini dipaksa untuk menyinkronkan di antara basis data.

Saya bertemu beberapa proyek di mana ada satu salinan utama aturan dalam database produksi dan sisanya menyalin semuanya dari sana.

Gagasan menggunakan kelas Seeder ( contoh ) jauh lebih baik. Anda hanya perlu berlari

php artisan db:seed AuthSeeder

dan Anda memiliki versi terbaru dari aturan dalam database. Dengan demikian, kelas seeder ini menjadi semacam Single Source Of Truth. Bagus, tetapi masih ada banyak ketidaknyamanan dalam pendekatan ini:

• Seeder harus cukup pintar untuk tidak hanya membuat peran dan izin dan koneksi di antara mereka, tetapi juga menyinkronkan versi lama. Yaitu hapus atau buat tautan antara peran dan izin jika perlu.
• Aturan disimpan dalam database dan sinkronisasi konstan antara mereka diperlukan. Setiap perubahan persyaratan dari bentuk "editor seharusnya tidak lagi mengedit posting, hanya mempublikasikannya" mengarah ke perubahan seeder, sinkronisasi basis kode melalui git atau sesuatu, dan "JANGAN LUPA MEMULAI AuthSeeder!"
• Aturan otorisasi bisa rumit. Misalnya, publikasi dapat diedit tidak hanya oleh editor atau administrator, tetapi juga oleh penulis publikasi ini. Karena itu, alih-alih middleware sederhana:

 ['middleware' => ['permission:edit posts']] 

pengembang harus menggunakan otorisasi laravel standar:

 class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } } 

Jadi mungkin cara termudah bukan yang terbaik?

Itu hanya terlihat sederhana: letakkan paket, jalankan migrasi selesai dan pergi. Dari sudut pandang dukungan proyek jangka panjang, ini bukan pilihan terbaik.

Mari kita coba menganalisis proyek apa yang biasanya dibutuhkan? Sistem bermain peran yang sederhana. Hampir selalu satu peran per pengguna. Administrator Ya, mungkin editor atau moderator lain. Dan peran ini memiliki beberapa izin. Ayo jalan paling langsung! Tambahkan bidang baru ke tabel pengguna! is_admin atau peran . Kemudian beberapa pembantu untuk kelas Pengguna :

 class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} } 

Sekarang permishen. Laravel menyediakan dua metode dasar untuk menggambarkan mereka: Gates dan Kebijakan . Saya akan menggunakan gerbang (masih ada trik kecil dengan fungsi dalam variabel, tetapi bagi pecinta pemrograman fungsional ini bukan trik sama sekali):

  $isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin); // Complex permission Gate::define('edit-post', function(User $user, Post $post) { return $user->id == $post->owner_id || $user->isAdmin(); }); 

Jika proyek membutuhkan beberapa peran per pengguna, maka cukup tambahkan tabel user_roles dan ubah bantuan kelas Pengguna . Isi kelas seeder untuk paket * trust dan otorisasi berbasis kode ini hampir identik! Tetapi aturan sekarang hanya disimpan dalam kode dan tidak perlu untuk terus menyinkronkannya dalam database.

Saya tidak ingin mengatakan bahwa paket-paket ini tidak berguna. Pendekatan ini sangat berguna dalam proyek-proyek dengan sistem otorisasi yang kompleks, di mana klien sendiri ingin mengkonfigurasi peran nanti. Ada juga proyek dengan izin dinamis. Contoh: forum dengan subforum. Setiap sub-forum dapat memiliki moderator sendiri, setiap moderator memiliki hak yang ditentukan oleh administrator dalam sub-forum ini. Contoh lain adalah telegram dan grup-grupnya. Ada hal yang sama. Proyek-proyek seperti itu benar-benar membutuhkan sistem otorisasi yang kompleks, disimpan dalam database, beserta semua masalahnya. Tetapi kebanyakan orang tidak.

Situasi dengan paket untuk laravel menjadi mirip dengan situasi dengan komponen untuk Delphi (orang tua ingat). Mereka meletakkan paket-paket tanpa ragu-ragu - benar-benar dibutuhkan atau tidak.

Jadi, saya harus menghitung $ a + $ b dalam proyek saya di sini. Apakah ada paket laravel-sum?

PS Saya minta maaf atas izinnya, tetapi saya tidak menemukan terjemahan akurat yang baik.