In mijn ervaring komt de echte vraag meestal neer op het al dan niet optreden van gebruikersspecifieke toegangsbeperkingen.
Stel bijvoorbeeld dat u het schema van een community ontwerpt en dat u gebruikers toestaat de zichtbaarheid van hun profiel te wijzigen.
Een optie is om vast te houden aan een openbare/private profielvlag en vast te houden aan brede, preventieve toestemmingscontroles:'users.view' (bekijkt openbare gebruikers) versus bijvoorbeeld 'users.view_all' (bekijkt alle gebruikers, voor moderators) .
Een andere heeft meer verfijnde machtigingen, je zou willen dat ze dingen kunnen configureren zodat ze zichzelf (a) zichtbaar kunnen maken voor iedereen, (b) zichtbaar zijn voor hun zorgvuldig uitgekozen vrienden, (c) volledig privé houden, en misschien (d ) zichtbaar voor iedereen behalve hun met de hand geplukte bozo's. In dit geval moet u eigenaar-/toegangsgerelateerde gegevens voor afzonderlijke rijen opslaan, en u zult sommige van deze dingen sterk moeten abstraheren om te voorkomen dat de transitieve afsluiting van een dichte, georiënteerde grafiek wordt gerealiseerd.
Bij beide benaderingen heb ik geconstateerd dat de extra complexiteit bij het bewerken/toewijzen van rollen teniet wordt gedaan door het resulterende gemak/flexibiliteit bij het toewijzen toestemmingen voor individuele stukjes gegevens, en dat het volgende het beste werkte:
- Gebruikers kunnen meerdere rollen hebben
- Rollen en machtigingen samengevoegd in dezelfde tabel met een vlag om de twee te onderscheiden (handig bij het bewerken van rollen/machtigingen)
- Rollen kunnen andere rollen toewijzen, en rollen en machtigingen kunnen machtigingen toewijzen (maar machtigingen kunnen geen rollen toewijzen), vanuit dezelfde tabel.
De resulterende georiënteerde grafiek kan vervolgens in twee query's worden opgehaald, voor eens en voor altijd worden gebouwd in een redelijke hoeveelheid tijd met behulp van de taal die u gebruikt, en in de cache worden opgeslagen in Memcache of iets dergelijks voor later gebruik.
Van daaruit is het ophalen van de machtigingen van een gebruiker een kwestie van controleren welke rollen hij heeft en deze verwerken met behulp van de machtigingsgrafiek om de definitieve machtigingen te krijgen. Controleer machtigingen door te controleren of een gebruiker de opgegeven rol/machtiging heeft of niet. En voer vervolgens uw vraag uit / geef een fout op basis van die toestemmingscontrole.
U kunt de controle voor individuele nodes uitbreiden (bijv. check_perms($user, 'users.edit', $node) voor "kan dit knooppunt bewerken" vs check_perms($user, 'users.edit') voor "kan een knooppunt bewerken") als dat nodig is, en je hebt iets heel flexibels/gemakkelijks te gebruiken voor eindgebruikers.
Zoals het openingsvoorbeeld zou moeten illustreren, moet u op uw hoede zijn om niet te veel naar machtigingen op rijniveau te sturen. Het prestatie knelpunt is minder bij het controleren van de machtigingen van een individueel knooppunt dan bij het trekken van een lijst met geldige knooppunten (d.w.z. alleen die de gebruiker kan bekijken of bewerken). Ik raad alles af dat verder gaat dan vlaggen en user_id-velden in de rijen zelf als je niet (zeer) goed thuis bent in het optimaliseren van zoekopdrachten.