Access Control List (Acl) class

Mooi, hierom vroeg ik dus in Bas zijn Tut over Bitwise Operators...

Dank Arjen ;)

Kun je me even vertellen wat de precieze verschillen zijn tussen jou classe en die van Zend? Wat kan ik met jou classe meer doen?

@ Wouser: Eerlijk gezegd kan Zend_Acl precies hetzelfde.
Alleen is mijn versie iets makkelijker te doorgronden denk ik, en misschien iets makkelijker te gebruiken.

Ook maak ik gebruik van de Bitwise Operators, wat je als voordeel zou kunnen zien.

Nog een voordeel, je hioeft niet meteen de complete Zend Library te downloaden

Edit:
spellings foutje in functie:
->alow() moet zijn:
->allow() (met 2 l'en)

Ik heb het typ foutje even aangepast hoor.. beetje dom foutje :P

Ik heb wat kleine dingen aangepast.
Ook sla ik de resources niet meer op in Awf_Acl, maar in een aparte (singleton) class, zodat je in de Awf_Acl_Role::allow() methode niet per se een Awf_Acl_Resource instantie hoeft mee te geven, maar de naam van die resource ook is. (Zie voorbeeld).

Je kunt hem nog wel gewoon gebruiken zoals eerst.

Ik denk juist van niet, aangezien die van Zend volledig gedocumenteerd is.

Desalniettemin ziet het er redelijk uit. Er zit naar mijn mening een grote fout in. Je doet nu bij een Role deny/allow. Dat is niet logisch. De hele reden dat je een Role hebt is zodat je in je Acl kunt zeggen of een bepaalde Role toegang heeft tot een Resource. Bij jouw script maak je een Acl en Resources maar ga je bij de Role aangeven dat hij toegang heeft tot een Resource, zonder daarbij de Acl te betrekken. Zo creëer je verkeerde dependencies. Je Acl (=ACCESS CONTROL list) zou moeten controleren of iemand ACCESS heeft, aangezien hij dit CONTROLeert :)

Edit: aan de hand van je vorige post (de post vóór dit bericht) zie je dus al dat je te kampen hebt met dit probleem. Je gaat nu zelfs een aparte class maken voor iets waar je hele Acl voor bedoeld is. Zodra je dit hebt aangepast zal je zien dat je uitkomt op ongeveer een kopie van Zend_Acl.

.... Daarom kun je dus beter bestaande modules gebruiken zoals Zend_Acl, dan hoef je ze niet te herschrijven.

Nice try though, het komt er zeker in de buurt :)

Erik bedoel je dat een acl standaard alles DENYED en alleen bepaalde ACCESS geeft?

Oftewel dat daarom de DENY vreemd is?

@ PHPerik.

Opzich snap je je wel.
Vanuit een misschien iets ander perspectief gezien, OOP?:

Een role beschrijft in mijn opzicht een soort gebruikersniveau. Bijvoorbeeld een beheerder, mag minder dan een admin, maar meer dan een gewoon lid. Het is dus een eigenschap van de Role wat hij mag. Daarom vond ik het logisch dat je aan de role vertelt wat hij wel en wat hij niet mag.

Wat hij wel en wat hij niet mag zijn dus de Resources. Ieder met hun eigen ID 1,2,4,8,16... zodat je makkelijk met bitwise dus kunt checken of een role een bepaade resourse bevat dus mag doen.

In dit geval komt alles in de Awf_Acl class bij elkaar. Dus heeft deze class inderdaad een iets andere functie dan die van Zend_Acl...

Maar vanuit mijn OOP perspectief lijkt het mij dat de rechten van een role, een property van een role is. Dus het bij de class Awf_Acl_Role hoort. Dus dat je aan die instantie moet vertellen wat hij wel en niet mag.

Voor het gebruikersgemak heb ik dus die Awf_Acl_Resources toegevoegd, zodat de resources overal benaderbaar zijn, dus dat je ook vanuit de Role instantie dmv een string de bijhorende resource kunt krijgen...

Een role beschrijft een persoon c.q. groep. Het is puur een definitie van de aanwezigheid van een groep.

Een resource is puur een definitie van een locatie c.q. handeling.

Maar uiteindelijk zal 'iets' moeten bepalen welke roles aan welke resources worden gekoppeld. Dat is de Access Control List. Stel dat de Acl dit niet zelf hoeft te doen, dan zou je de hele Acl niet eens nodig hebben. Dan kun je evengoed een Array gebruiken aangezien de roles alle informatie bevatten.

Bekijk het eens anders. Is het feit dat ik wel in het serverhok mag en de marketingmensen niet een eigenschap van mij als developer? Of is het een recht dat mij is toegekend door de organisatie? Een recht is geen eigenschap maar een toekenning door een overkoepelend orgaan.

Bedankt voor de goede uitleg.

Ik heb hem een beetje aangepast. Nu lijkt hij denk ik meer op hoe jij een Acl beschrijft (en zoals zend het doet).

Ik denk dat het nu zelfs makkelijker is geworden om hem te gebruiken.

Ook is hij zelfs aanzienlijk korter geworden ;)

Ziet er erg goed uit, mijn complimenten. Ook in eerste instantie was het erg goed, ik vond dus alleen die ene keuze zelf niet logisch. Erg mooi en een zeer goede toevoeging voor PHPhulp.

Erg leuk, maar deze ACL class komt niet boven de 30 resources uit op een 32-bit PHP configuratie omdat een integer boven 2147483648 (2^31) automatisch een float wordt.