Dalam pengalaman saya, pertanyaan sebenarnya sebagian besar terbagi menjadi apakah sejumlah pembatasan akses khusus pengguna akan terjadi atau tidak.
Misalnya, Anda merancang skema komunitas dan mengizinkan pengguna untuk mengubah visibilitas profil mereka.
Salah satu opsi adalah tetap berpegang pada bendera profil publik/pribadi dan tetap pada pemeriksaan izin pre-emptive yang luas:'users.view' (melihat pengguna publik) vs, katakanlah, 'users.view_all' (melihat semua pengguna, untuk moderator) .
Lain melibatkan izin yang lebih halus, Anda mungkin ingin mereka dapat mengonfigurasi sesuatu sehingga mereka dapat membuat diri mereka sendiri (a) dapat dilihat oleh semua orang, (b) dapat dilihat oleh teman-teman pilihan mereka, (c) dirahasiakan sepenuhnya, dan mungkin (d ) dapat dilihat oleh semua orang kecuali bozos pilihan mereka. Dalam hal ini Anda perlu menyimpan data pemilik/akses terkait untuk setiap baris, dan Anda harus banyak mengabstraksi beberapa hal ini untuk menghindari terwujudnya penutupan transitif dari grafik yang padat dan berorientasi.
Dengan kedua pendekatan tersebut, saya menemukan bahwa kerumitan tambahan dalam pengeditan peran/penugasan diimbangi oleh kemudahan/fleksibilitas yang dihasilkan dalam penugasan izin untuk setiap bagian data, dan yang berikut ini berfungsi paling baik:
- Pengguna dapat memiliki banyak peran
- Peran dan izin digabungkan dalam tabel yang sama dengan tanda untuk membedakan keduanya (berguna saat mengedit peran/izin)
- Peran dapat menetapkan peran lain, dan peran serta izin dapat menetapkan izin (tetapi izin tidak dapat menetapkan peran), dari dalam tabel yang sama.
Grafik berorientasi yang dihasilkan kemudian dapat ditarik dalam dua kueri, dibuat sekali dan untuk semua dalam jumlah waktu yang wajar menggunakan bahasa apa pun yang Anda gunakan, dan di-cache ke Memcache atau serupa untuk penggunaan selanjutnya.
Dari sana, menarik izin pengguna adalah masalah memeriksa peran mana yang dimilikinya, dan memprosesnya menggunakan grafik izin untuk mendapatkan izin akhir. Periksa izin dengan memverifikasi bahwa pengguna memiliki peran/izin yang ditentukan atau tidak. Dan kemudian jalankan kueri Anda/masalahkan kesalahan berdasarkan pemeriksaan izin itu.
Anda dapat memperpanjang pemeriksaan untuk masing-masing node (yaitu check_perms($user, 'users.edit', $node)
untuk "dapat mengedit simpul ini" vs check_perms($user, 'users.edit')
untuk "dapat mengedit simpul") jika perlu, dan Anda akan memiliki sesuatu yang sangat fleksibel/mudah digunakan untuk pengguna akhir.
Seperti yang harus diilustrasikan oleh contoh pembukaan, berhati-hatilah dalam mengarahkan terlalu banyak ke izin tingkat baris. Kemacetan kinerja kurang dalam memeriksa izin node individu daripada dalam menarik daftar node yang valid (yaitu hanya yang dapat dilihat atau diedit oleh pengguna). Saya akan menyarankan untuk tidak melakukan apa pun selain bidang flags dan user_id di dalam baris itu sendiri jika Anda tidak (sangat) berpengalaman dalam pengoptimalan kueri.