login  Naam:   Wachtwoord: 
Registreer je!
 Tutorials
Tutorials > PHP

Gegevens:
Geschreven door:
 Rik
Moeilijkheidsgraad:
 Moeilijk
Hits:
 9396
Punten:
Aantal punten:
  (5)
Aantal stemmen:
 7
Stem:
 Niet ingelogd
Nota's:
 Lees de nota's (17)
 



Tutorial:

Rechten beheren


1. Inleiding

In deze tutorial zal ik uitleggen hoe je rechten kunt beheren in een applicatie. Rechten geven aan wat er wel en niet mag gebeuren tijdens het uitvoeren van code. Ze worden gegeven op basis van regels. Er worden eerst regels gedefinieerd, waarna die worden toegepast. Om dat wat duidelijker te maken zal ik straks eerst een paar definities geven.

Er zijn verschillende manieren om regels te definiëren en toe te passen. De belangrijkste en meest gebruikte methoden zal ik toelichten. Je zult zien dat je een probleem op verschillende manieren op kunt lossen, maar dat je daarbij steeds een goede balans moet vinden tussen flexibiliteit, efficiëntie en performance. De voorbeelden die ik geef zullen in php gemaakt zijn, maar het idee erachter is in elke willekeurige taal te implementeren.


 top
2. Definities

Er zijn drie belangrijke aspecten die de basis van een regel vastleggen: de rol, het object en het recht. Daarnaast zijn er nog drie principes die het geheel een stuk flexibeler kunnen maken. Dat zijn overerving, prioriteit en het stellen van voorwaardes.

Rol (role)

De rol is een weergave van iets of iemand die ergens al dan geen toestemming voor heeft. In een eenvoudig scenario is dit de bezoeker van een website die bijvoorbeeld wel op het publieke forum mag posten, maar geen instellingen op het beheerspaneel kan aanpassen.

Object (resource)

Het object is iets waar een rol toegang toe zou kunnen krijgen. Dit kan weer een beheerspaneel zijn, maar ook het profiel van een lid van een website of een bepaald nieuwsbericht.

Overerven (inherit)

Overerven voorkomt dat er onnodig veel regels hoeven te worden gedefinieerd. Het is logisch dat een directeur minstens alle rechten heeft als de chef die drie rangen lager staat. Of dat een bezoeker die de toegang tot het forum is ontzegd ook niet meer een post in dat forum mag bekijken.

Als er geen regels zijn voor een bepaalde rol, moet er gekeken naar de regels voor de bovengelegen rol. Als die niet is opgegeven, wordt er gekeken naar de anonieme rol die in het algemeen zeer beperkende regels heeft. Andersom kan natuurlijk ook, daar kom ik later nog op.

De grootste kracht van overerven is dat een rol of een object van verschillende andere rollen of objecten kan overerven. Zo kan met weinig regels een complex systeem beschreven worden.

Prioriteit (priority)

Prioriteit kan worden opgegeven om aan te geven hoe belangrijk een rol of een object is. Zo kan er bij het zoeken naar regels bij hoger gelegen rollen of objecten eerst worden gekeken naar de belangrijke en dan pas naar de minder belangrijke rollen.

Recht (privilege)

Een recht is iets dat een rol zou kunnen doen met een object. In het geval van een gebruiker zou dit het aanpassen van zijn of haar eigen profiel zijn. Maar ook het mogen posten op een forum kan een recht zijn.

Voorwaarde (assertion)

Een voorwaarde bepaalt of een regel al dan niet wordt nageleefd. Voorwaardes zijn handig als je bijvoorbeeld onderscheidt wilt maken tussen mannelijke- en vrouwelijke bezoekers. Je wilt dan niet dat er een aparte rol is voor mannen en voor vrouwen, omdat je dan erg lastige constructies kunt krijgen als je ook nog met overerving werkt. Op eenzelfde manier kun je voorwaarden gebruiken om bijvoorbeeld alleen overdag een poll open te zetten. Je valt de rol en het object dan niet lastig met het tijdstip van de dag.


 top
3. Logica van dit systeem

Nu deze definities zijn vastgelegd moet er worden afgevraagd of dit ook logisch is. Zitten er geen denkfouten in dit concept? Ik zal een aantal vragen beantwoorden om te laten zien dat dit systeem toch best goed in elkaar zit is.

Waarom kan een recht niet overerven?

Op zich kun je het concept zo implementeren dat ook rechten kunnen overerven. In de praktijk blijkt dat echter meestal overbodig. Er zijn namelijk vaak een grote hoeveelheid verschillende rollen en objecten die erg dynamisch zijn. Een recht daarentegen is dat niet. Voor elk recht staat in de code vast wat er mee kan gebeuren.

Het posten van een reactie bij-, of het stemmen op een poll bijvoorbeeld. Stemmen en posten zijn twee behoorlijk verschillende rechten die niet logisch samenhangen. Natuurlijk kun je definiëren dat iemand die mag stemmen, ook mag posten, maar hoe vaak zul je dit in de praktijk gebruiken? Het is dan veel gemakkelijker om de toestemming per recht op te geven.

Een voorbeeld waarbij het wel handig is dat rechten overerven is een uploadformulier waarin bepaalde gebruikers bepaalde bestandstypen mogen uploaden. Als iemand helemaal niet mag uploaden, mag hij ook geen afbeeldingen uploaden. Hier ga je er van uit dat het uploadformulier het object is. Maar dit kun je ook anders oplossen door het soort bestand dat wordt geüpload als object te nemen. Er is dan alleen het recht uploaden nodig en als iemand helemaal niet mag uploaden, ontneem je hem dat recht.

Waarom zou de anonieme rol beperkende regels opgelegd krijgen?

Er moeten regels zijn die algemeen de rechten vastleggen als er geen specifieke regels voor een combinatie van een rol, een object en een recht zijn. Als die niet zouden zijn gedefinieerd zou het systeem geen beslissing kunnen nemen. Dit probleem kan van twee kanten worden benaderd: oplopend toestaand en oplopend beperkend.

Bij oplopend toestaand heeft niemand rechten totdat de rechten wel worden verleend. Standaard mag niemand een forumbericht aanpassen, maar dat wordt wel toegestaan aan de poster, de moderator en hoger gelegen admins. Om nu niet onnodig veel regels te hoeven definiëren, moet een hoger geplaatst iemand (een admin) de rechten overerven van een lager geplaatst iemand (de moderator) en daarna pas extra rechten krijgen.

Bij oplopend beperkend is dit precies andersom: standaard mag iedereen een forumbericht bewerken, maar niet-admins, niet-moderators en anderen die niet de poster zijn mogen dat niet. Hier erft de lager gelegen rol over van de hoger gelegen rol, waarna de lager gelegen rol beperkingen worden opgelegd. Het hangt erg af van de situatie welke benadering het makkelijkste is, maar voor websites is oplopend toestaand meestal de slimste keuze.

Hoe weet ik of een rol bepaalde rechten tegelijk heeft?

Neem als voorbeeld een gebruiker die een afbeelding wilt uploaden. Dat heeft voor hem alleen zin als hij én mag uploaden én mag zien wat hij heeft geüpload, want anders kan hij er niets meer mee. In dit geval moet er (afhankelijk van prioriteit!) eerst worden gecontroleerd of de gebruiker mag uploaden en dan of hij zijn upload mag bekijken. Als hij een van beiden niet mag, mag hij de combinatie ook niet. In de implementatie is het dus handig om een manier mee te nemen om rechten te kunnen combineren.


 top
4. Praktijkvoorbeelden

Dit systeem is meer dan een techniek om regels op te stellen alleen. Het is een gedachtegang waarmee je op een overzichtelijke manier rechten weer kunt geven. Met een beetje moeite kun je dit ook toepassen op ondoorzichtig uitziende systemen. Een tweetal voorbeelden waarin rechten beheerd moeten worden:

Het bestandssysteem (in *nix).

In *nix is in de manier waarop bestanden en mappen worden beheerd en mogen worden benaderd erg precies geregeld. Het bestand wordt hierbij gezien als een object. Voor elk bestand zijn er voor drie verschillende rollen de rechten bepaald. Die drie rollen zijn de gebruiker, de groep (elke gebruiker is lid van een groep) en anoniem. Er zijn drie rechten: lezen, schrijven en uitvoeren. Overerving vindt hier plaats van gebruiker naar groep en van map naar bestand, want een nieuw bestand krijgt automatisch dezelfde rechten als de map waar die in staat. Hier wordt geen gebruik gemaakt van voorwaardes.

Openbaar vervoer

Een heel algemeen voorbeeld is het openbaar vervoer, want ook hierin is een systeem met rechten te herkennen. Zo zijn er verschillende soorten vervoer die we als objecten kunnen zien, zoals: pont, bus, tram, metro en trein. Vaak moet er een "vervoersbewijs" worden gekocht in de vorm van een kaartje, een strippenkaart of een abbonement, al dan niet met korting. Ook kun je verschillende groepen reizigers onderscheiden, zoals: kinderen, volwassenen, ouderen en studenten. Maar voor de conducteur maakt het in de eerste instantie niets uit wie hij voor zich heeft, alleen het vervoersbewijs is van belang. Daarom is de rol hier het soort vervoersbewijs en niet de persoon zelf. Het soort persoon kan wel een voorwaarde zijn voor het soort vervoersbewijs dat voor diegene is toegestaan. Nu de rol, het object en de voorwaarde zijn gedefinieerd, blijven de rechten over. Hierbij kun je bijvoorbeeld denken aan het al dan niet gratis of met korting mogen reizen.

Ter illustratie een aantal voorbeelden:

  • Een (roze) strippenkaart met korting is alleen geldig in de bus, tram en metro als je recht hebt op korting. Regel:

    • Rol: roze strippenkaart.
    • Object: bus, tram en metro.
    • Recht: met korting reizen
    • Voorwaarde: kind, oud of op een andere manier recht op korting en gestempeld.

  • Een ov-kaart voor studenten. Regel:

    • Rol: ov-kaart.
    • Object: bus, tram, metro, trein.
    • Recht: gratis reizen.
    • Voorwaarde: niet op feestdagen, in vakanties of buiten het recht op studiefinanciering om.

  • Een treinkaartje voor de eerste klas zonder datum van Utrecht naar Amsterdam. Regel:

    • Rol: kaartje zonder datum
    • Object: trein
    • Recht: reizen in de eerste klas.
    • Voorwaarde: gestempeld en op juiste traject.

 top
5. Implementatie

Je weet nu wat een regel in houdt, maar hoe definieer je die? En hoe controleer je welke regel toegepast moet worden in een bepaald geval? Dit kan op vele manieren, oplopend van eenvoudig tot moeilijk en tegelijk van log naar flexibel. Ik zal me beperken tot drie methoden die goed te onderscheiden zijn. Voor de duidelijkheid zal ik steeds dezelfde rollen, objecten en rechten gebruiken:

  • Rollen: admin, moderator, member, guest en banned.
  • Objecten: blog, poll en forum.
  • Rechten: view, post, vote en delete.

Voor gebruik in de praktijk is het verstandig mijn stukken code te voorzien van de nodige controles op correcte invoer.


 top
 5.1. Pure code

In het begin verreweg de meest toegepaste en eenvoudigste manier om rechten te beheren is door alles rechtstreeks in code op te geven. Waarschijnlijk heeft iedereen die al eens met php (of een andere webbased taal) heeft gewerkt dit ooit gebruikt. Een hele serie if en else of switch statements om op alle mogelijkheden voorbereid te zijn.

Voor simpele applicaties werkt dit prima en zonder al te veel moeite, maar als je steeds verder wilt uitbreiden, zul je problemen tegenkomen omdat je telkens uitzonderingen toe moet voegen. Aan overerving kun je beter helemaal niet beginnen, omdat het geheel dan echt onhandelbaar wordt.

Voordat er wordt doorgegaan met meer doordachte systemen wil ik eerst het principe authenticatie bespreken. Authenticatie is het proces waarbij iemand, een computer of applicatie nagaat of een gebruiker, een andere computer of applicatie daadwerkelijk is wie hij beweert te zijn. [1] Want hoe weet je welke rol een bepaalde gebruiker heeft? Vaak wordt hiervoor een login systeem gebruikt. Het is belangrijk dat je de bezoeker eerst identificeert en een bepaalde rol toekent zodat je weet welk pakket rechten je op hem moet toepassen.


 top
 5.2. Bitwise

Het idee achter een bitwise systeem is dat er in één decimaal getal verschillende binaire getallen kunnen worden opgeslagen. Elk decimaal bestaat uit nullen en enen waarbij een één steeds (afhankelijk van de plaats in het getal) een deel van het decimale getal vormt. Een simpel voorbeeld:

13 (decimaal) = 8 + 4 + 1 (decimaal) = 2^3 + 2^2 + 2^0 (decimaal) = 1101 (bitwise)

Als je dit niet helemaal snapt is dat niet heel belangrijk om het systeem te kunnen gebruiken, maar je kunt altijd de uitleg op wikipedia [2] eens doorlezen. Als je nu elk recht een opeenvolgende bit laat voorstellen (1, 2, 4, 8, ..., 2^(n-1), 2^n), dan kan je door de getallen van verschillende rechten bij elkaar op te tellen de combinatie ervan in één decimaal getal vastleggen.

Elke combinatie van rechten kan dan worden opgeslagen in een variabele. Je kunt zelf kiezen waar die variabelen voor staan. Het is op deze manier niet mogelijk om de rechten voor een rol en een object samen zo op te slaan dat er ook nog makkelijk valt te controleren. De meest gebruikte toepassing is dan ook dat de variabele voor een rol staat, en het getal voor de rechten. Merk op dat je door die variabelen heel makkelijk kunt overerven. Dit moet echter wel steeds gebeuren nadat de rechten zijn toegekend!

Om nu te controleren of een recht is verleend wordt de & gebruikt. Dit teken geeft alle binaire componenten die in beide getallen voorkomen bij elkaar opgeteld terug als een decimaal getal. Als er op één recht wordt gecontroleerd zal er bij toestemming één binair component worden teruggegeven en bij twee rechten twee enzovoorts. Er wordt dus geen true of false teruggegeven! Gelukkig is php niet erg strikt wat types betreft, dus een 0 zal worden gezien als false en alles hoger dan dat wordt true.

Het hele gebruik is dan als onderstaand. Ik maak gebruik van de zogenaamde Hongaarse notatie [3] om duidelijk te maken wat voor waarde in welke variabele staat.

  1. /* Rollen definiëren */
  2. $iAdmin = $iModerator = $iMember = $iGuest = $iBanned = 0;
  3.  
  4. /* Rechten definiëren */
  5. define('VIEW', 1);
  6. define('POST', 2);
  7. define('VOTE', 4);
  8. define('DELETE', 8);
  9.  
  10. /* Rechten verlenen en overerven */
  11. $iBanned = 0; // Gebanden mogen helemaal niets
  12. $iGuest = VIEW; // Gasten mogen kijken
  13. $iMember = $iGuest | POST | VOTE; // Leden mogen kijken, posten en stemmen
  14. $iModerator = $iMember | DELETE; // Moderatoren mogen ook nog verwijderen
  15. $iAdmin = $iModerator; // Admins mogen alles wat moderator mogen
  16.  
  17. /* Toestemming opvragen */
  18. $iBanned & POST; // false
  19. $iGuest & DELETE; // false
  20. $iAdmin & VIEW; // true
  21. $iModerator & POST & VIEW; // true
  22. $iMember & VOTE & DELETE; // false

Zoals je ziet is het makkelijk om voorwaarden toe te voegen in de if statements waarin op rechten wordt gecontroleerd. Let op dat bij het overerven géén plus wordt gebruikt maar een binaire of (|). Als je de rechten zou optellen, zou het mis gaan als beiden al één of meer rechten gelijk hebben. Het dubbele van een binair component is immers gelijk aan een component hoger! Zo zouden er ongewenst allemaal rechten kunnen worden verleend. Een overzicht van alle bitwise bewerkingen is overigens te vinden op php.net. [4] Een goede en direkt bruikbare implementatie van FangorN staat bij de scripts. [5]

Het grootste nadeel van deze techniek is dat het erg lastig is om regels voor rollen én voor objecten te gebruiken. Een wat minder mooie oplossing is het prefixen van alle rechten met de naam van het object. Een ander nadeel is dat er alleen rechten verleend kunnen worden. Op deze manier is er dus alleen een toestaande aanpak mogelijk. Dit effect zou je om kunnen keren door te definiëren wat niet mag en dus ook te controleren of iemand iets niet mag.

Bovendien is er een software afhankelijke beperking. Als er veel rechten worden gedefinieerd, zal er elke keer een binair getal moeten worden gemaakt dat twee keer zo groot is als de voorafgaande. Op een gegeven moment zal dit zo'n groot getal worden dat het niet meer correct kan worden weergegeven. Het precieze maximum is afhankelijk van het besturingssysteem en de instellingen van php. Natuurlijk is dat probleem te verhelpen door (met behulp van een php extensie als GNU MP Library [6] of BCMath Arbitrary Precision Mathematics [7]) zelf de bitwise berekeningen uit te gaan voeren. De vraag is dan of dit niet teveel ten koste gaat van de performance én of er echt zo veel definities nodig zijn. Voor kleinere en minder complexe systemen is de bitwise oplossing vaak ruim voldoende.


 top
 5.3. Acces control list (ACL)

Een meer flexibele aanpak is de access control list. Daarbij worden rollen, objecten en rechten aan elkaar gekoppeld in een regel. Een set van die regels vormt dan als het ware een lijst waarin staat welke rol welke rechten heeft op welke objecten.

Het gebruik is onderverdeeld in drie eenvoudige stappen:

  1. Rollen, objecten en rechten definiëren.
  2. Rechten verlenen.
  3. Toestemming opvragen.

 top
  5.3.1 De AccessControlList class

Het makkelijkste is om dit in een class te implementeren:

  1. <?php
  2. class AccessControlList {
  3.     protected $aRoles;
  4.     protected $aResources;
  5.     protected $aPrivileges;
  6.     protected $aRules;
  7.     protected $bDefault;
  8.  
  9.     public function __construct($aRoles, $aResources, $aPrivileges, $bDefault = false) {
  10.         /* Rollen, objecten en rechten definiëren */
  11.         $this->aRoles = $aRoles;
  12.         $this->aResources = $aResources;
  13.         $this->aPrivileges = $aPrivileges;
  14.         /* Standaard instelling voor onbekende regels */
  15.         $this->bDefault = $bDefault;
  16.     }
  17.  
  18.     /* Functie om de opgegeven rollen en objecten om te zettin in de rol index */
  19.     protected function getRule($sRole, $sResource, $sPrivilege) {
  20.         return isset($this->aRules[$sRole][$sResource][$sPrivilege])
  21.             ? $this->aRules[$sRole][$sResource][$sPrivilege]
  22.             : null;
  23.     }
  24.  
  25.     /* Functie om rechten te verlenen aan rollen op objecten */
  26.     public function allow($sRole, $sResource, $sPrivilege) {
  27.         $this->aRules[$sRole][$sResource][$sPrivilege] = true;
  28.     }
  29.  
  30.     /* Functie om rechten expliciet te ontnemen */
  31.     public function deny($sRole, $sResource, $sPrivilege) {
  32.         $this->aRules[$sRole][$sResource][$sPrivilege] = false;
  33.     }
  34.  
  35.     /* Functie om te controleren of een recht is verleend */
  36.     public function isAllowed($sRole, $sResource, $sPrivilege) {
  37.         $bRule = $this->getRule($sRole, $sResource, $sPrivilege);
  38.         return $bRule === null ? $this->bDefault : $bRule === true;
  39.     }
  40.  
  41.     /* Functie om te controleren of een recht is ontnomen */
  42.     public function isDenied($sRole, $sResource, $sPrivilege) {
  43.         $bRule = $this->getRule($sRole, $sResource, $sPrivilege);
  44.         return $bRule === null ? $this->bDefault : $bRule === false;
  45.     }
  46. }

In principe kun je zoveel regels toevoegen als je zelf wilt. Daarbij kun je zelf bepalen of je rechten verleent of ontneemt. Merk op dat er bij gebruik van isAllowed() en isDenied() altijd true of false wordt teruggegeven, ook al bestaan er geen regels voor de situatie waarvan je de rechten opvraagt. Deze functies geven dus een standaard waarde terug die kan worden gedefinieerd in de constructor.


 top
  5.3.2 Het gebruik

Het definiëren van rollen, objecten en rechten gaat als volgt:

  1. /* Rollen, objecten en rechten definiëren */
  2. $oACL = new AccessControlList(
  3.     array('admin', 'moderator', 'member', 'guest', 'banned'), // Rollen
  4.     array('blog', 'poll', 'forum'), // Objecten
  5.     array('view', 'post', 'vote', 'delete') // Rechten
  6. );

Nu moeten de rechten worden verleend:

  1. /* Rechten verlenen */
  2. // Iedereen behalve gebanden mogen alles bekijken
  3. $oACL->allow('admin', 'blog', 'view');
  4. $oACL->allow('admin', 'poll', 'view');
  5. $oACL->allow('admin', 'forum', 'view');
  6. $oACL->allow('moderator', 'blog', 'view');
  7. $oACL->allow('moderator', 'poll', 'view');
  8. $oACL->allow('moderator', 'forum', 'view');
  9. $oACL->allow('member', 'blog', 'view');
  10. $oACL->allow('member', 'poll', 'view');
  11. $oACL->allow('member', 'forum', 'view');
  12. $oACL->allow('guest', 'blog', 'view');
  13. $oACL->allow('guest', 'poll', 'view');
  14. $oACL->allow('guest', 'forum', 'view');
  15.  
  16.  
  17. // Posten op het forum mag alleen door leden en hoger
  18. $oACL->allow('admin', 'forum', 'post');
  19. $oACL->allow('moderator', 'forum', 'post');
  20. $oACL->allow('forum', 'forum', 'post');
  21.  
  22.  
  23. // Alleen admins en moderators mogen op het forum verwijderen
  24. $oACL->allow('admin', 'forum', 'delete');
  25. $oACL->allow('moderator', 'forum', 'delete');
  26.  
  27.  
  28. // Alleen admins mogen een poll verwijderen
  29. $oACL->allow('admin', 'poll', 'delete');
  30.  
  31. // Alleen leden mogen stemmen bij polls
  32. $oACL->allow('member', 'poll', 'vote');
  33.  
  34. // Alleen admins mogen een blog aanmaken of verwijderen
  35. $oACL->allow('admin', 'blog', 'post');
  36. $oACL->allow('admin', 'blog', 'delete');

En de acces control list is klaar voor gebruik!

  1. /* Toestemming opvragen */
  2. $oACL->isAllowed('moderator', 'forum', 'post'); // true
  3. $oACL->isAllowed('guest', 'poll', 'delete'); // false

Zo kun je dus op een erg overzichtelijke manier de rechten beheren.


 top
  5.3.3 Verbeterpunten

Hoewel dit goed werkt wordt niet de volledige kracht van acl benut. Allereerst is er veel code nodig om de regels op te stellen. Dat zou veel korter kunnen door de allow() en de deny() ook arrays te laten accepteren. Het opstellen van regels zou er dan zo uit kunnen zien:

  1. /* Rechten verlenen */
  2. // Iedereen behalve gebanden mogen alles bekijken
  3. $oACL->allow(array('admin', 'moderator' , 'member', 'guest'), array('blog', 'poll', 'forum'), 'view');
  4.  
  5. // Posten op het forum mag alleen door leden en hoger
  6. $oACL->allow(array('admin', 'moderator' , 'member'), 'forum', 'post');
  7.  
  8. // Alleen admins en moderators mogen op het forum verwijderen
  9. $oACL->allow(array('admin', 'moderator'), 'forum', 'delete');
  10.  
  11. // Alleen admins mogen een poll verwijderen
  12. $oACL->allow('admin', 'poll', 'delete');
  13.  
  14. // Alleen leden mogen stemmen bij polls
  15. $oACL->allow('member', 'poll', 'vote');
  16.  
  17. // Alleen admins mogen een blog aanmaken of verwijderen
  18. $oACL->allow('admin', 'blog', array('post', 'delete'));

Dat is nog veel overzichtelijker! Eenzelfde principe zou in de isAllowed() en isDenied() functies ook handig zijn om eenvoudig op een combinatie van rechten te kunnen controleren. Ook kan er nog verder worden uitgebreid door rollen, objecten rechten en regels flexibel toe te laten voegen of te laten verwijderen

Andere verbeterpunten zijn het implementeren van overerving en voorwaarden. Vooral in het implementeren van overerving gaat enorm veel werk zitten weet ik uit ervaring. Er moet opgepast worden voor oneindige lussen (bijvoorbeeld door rollen die van elkaar overerven), en er moet zo mogelijk rekening worden gehouden met prioriteit. Daarbij is het ook verstandig om gelijk te denken aan een anonieme rol, object en recht. Zo kun je bijvoorbeeld alle rollen in één keer alle rechten geven op een bepaald object.

Het implementeren van deze verbeterpunten laat ik aan de lezer over. Een erg goede en volledige implementatie van ACL is gemaakt door Zend. [8] Als je overweegt zelf een compleet ACL systeem te bouwen zou ik je zeker aanraden die classes eens goed te bestuderen.

Met een volledig ACL systeem is het tijd om na te denken wat de handigste manier is om de rechten op te slaan. Je kunt elke keer opnieuw alles defiëneren, maar dat is niet erg bevorderlijk voor de performance bij grote systemen. Beter is het dan om het hele AccesControlList-object op te slaan. Als er vaak moet worden gewijzigd in de rechten kan het ook handig zijn om de definities in een ander formaat op te slaan. In een xml bestand of in een database bijvoorbeeld, zodat er niet rechtstreeks in de php code hoeft te worden gewijzigd.


 top
6. Conclusie

Rechten zijn op verschillende manieren te beheren. In elke situatie moet er opnieuw worden gekeken wat de beste oplossing is. Als je eenmaal gewend bent ACL te gebruiken, zul je zien dat je niet snel meer terug zult keren naar de eenvoudigere oplossingen omdat die zoveel minder flexibel zijn. Probeer vooral ook eens zelf een systeem systematisch op te bouwen volgens dit principe. Daarvan krijg je het nog beter door en leer je gelijk hoe je lastige problemen makkelijk in kleinere stukken op kunt lossen.


 top
7. Referenties
  1. Authenticatie
  2. Binair
  3. Hongaarse notatie
  4. Bitwise Operators
  5. Loginscript mbv Sessies
  6. GNU Multiple Precision
  7. BCMath Arbitrary Precision Mathematics
  8. Zend_Acl

 top
8. Afsluiting

Allereerst wil ik je feliciteren dat je deze toch redelijk omvangrijke tutorial hebt doorgenomen. Daarnaast hoop in ieder geval dat je wat inzicht hebt gekregen in het beheren van rechten en dat je nu ook ziet hoe het op een andere manier kan dan je misschien gewend was.

Vragen, opmerkingen, suggesties en commentaren zijn altijd welkom in een pm of als reactie!

Rik Veenboer aka Boukefalos

 top



« Vorige tutorial : Geavanceerde Arrays Volgende tutorial : Beveiliging in scripts »

© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.019s