Min erfaring er, at det egentlige spørgsmål for det meste går ud på, om der vil forekomme nogen brugerspecifik adgangsbegrænsning eller ej.
Antag for eksempel, at du designer skemaet for et fællesskab, og at du tillader brugere at skifte synligheden af deres profil.
En mulighed er at holde sig til et offentligt/privat profilflag og holde sig til brede, forebyggende tilladelsestjek:'users.view' (viser offentlige brugere) vs f.eks. 'users.view_all' (viser alle brugere, for moderatorer) .
En anden involverer mere raffinerede tilladelser, du vil måske have dem til at være i stand til at konfigurere tingene, så de kan gøre sig selv (a) synlige for alle, (b) synlige af deres håndplukkede venner, (c) holdes helt private og måske (d) ) kan ses af alle undtagen deres håndplukkede bozos. I dette tilfælde skal du gemme ejer-/adgangsrelaterede data for individuelle rækker, og du bliver nødt til at abstrahere nogle af disse ting kraftigt for at undgå at materialisere den transitive lukning af en tæt, orienteret graf.
Med begge tilgange har jeg fundet ud af, at øget kompleksitet i rolleredigering/-tildeling opvejes af den resulterende lethed/fleksibilitet ved tildeling tilladelser til individuelle stykker data, og at følgende fungerede bedst:
- Brugere kan have flere roller
- Roller og tilladelser slået sammen i den samme tabel med et flag for at skelne mellem de to (nyttigt ved redigering af roller/perms)
- Roller kan tildele andre roller, og roller og tilladelser kan tildele tilladelser (men tilladelser kan ikke tildele roller) fra den samme tabel.
Den resulterende orienterede graf kan derefter trækkes i to forespørgsler, bygget én gang for alle inden for rimelig tid ved at bruge det sprog, du bruger, og cache i Memcache eller lignende til efterfølgende brug.
Derfra er det at trække en brugers tilladelser et spørgsmål om at kontrollere, hvilke roller han har, og behandle dem ved hjælp af tilladelsesgrafen for at få de endelige tilladelser. Tjek tilladelser ved at verificere, at en bruger har den angivne rolle/tilladelse eller ej. Og kør derefter din forespørgsel/udsted en fejl baseret på det tilladelsestjek.
Du kan udvide kontrollen for individuelle noder (dvs. check_perms($user, 'users.edit', $node) for "kan redigere denne node" vs check_perms($user, 'users.edit') for "kan redigere en node"), hvis du har brug for det, og du vil have noget meget fleksibelt/nemt at bruge for slutbrugere.
Som åbningseksemplet skal illustrere, skal du være varsom med at styre for meget mod tilladelser på rækkeniveau. Ydeevneflaskehalsen er mindre ved at kontrollere en individuel nodes tilladelser, end den er ved at trække en liste over gyldige noder (dvs. kun dem, som brugeren kan se eller redigere). Jeg vil fraråde alt andet end flag og user_id-felter i selve rækkerne, hvis du ikke er (meget) velbevandret i forespørgselsoptimering.