gebruikerstoegang in een MVC omgeving
Ik gebruik een MVC patroon. Op het moment dat ik een functie aanroep binnen in een controller moet ik kunnen controleren of de gebruiker wel de nodige rechten heeft om dat deel uit te voeren. Ik wil dat OOP doen. Ik wil ook vermijden dat ik overal dezelfde controle code moet invoegen.
Mijn gedachten gaan om een controller class te maken en die telkens te extenden voor de eigenlijke controller class. Zo kan ik dan in de base class een functie zetten die de controle doet. In __construct van de extend class kan ik dan iets schrijven zoals $this->level = "123456789";. Mijn probleem is dat ik dan wel de controller level eenvoudig beheer maar niet de functies binnen die controller.
De controle dient ook binnen de controller zelf te gebeuren en niet in een array waar het in opgezocht wordt. Niet zo OOP en gevoelig voor vergetelheden.
Hoe zou ik dat elegant kunnen oplossen?
Thanks,
Marc
P.S.: nu ga ik eerst eten.
Vervolgens kunnen overige objecten iets doen als:
Code (php)
1
2
3
2
3
if($oUser->getRight('RIGHT_NAME'))
{
}
{
}
Je zou daarin ook het rechten-systeem kunnen prikken, en die vanuit je controllers dan raadplegen wanneer nodig.
Een andere methode die ikzelf nog niet veel op andere plekken heb gezien is om een extra laag om je model heen te bouwen. Ervan uitgaande dat je data-objects gebruikt om je data uit je model te representeren (oftewel: classes, bijvoorbeeld een class Topic, een class Post, etc die de werkelijke data bevatten) kan je in deze laag, die om je model heen hangt, alle inkomende en uitgaande data-objecten controleren, en kijken of de op dat moment aangemelde gebruiker ze wel of niet mag lezen/schrijven. Wanneer je dan ook werkelijk alleen je model-laag toegang geeft tot de data, en niet stiekem in je controller nog SQL code hebt staan heb je volgens mij een behoorlijk waterdicht systeem om de veiligheid van je data te garanderen.
In de laag om je model-laag beslis je dan welke data een bepaalde gebruiker mag zien of mag wijzigen (bijv. alle topics mag hij zien, behalve die met het category-id van het admin forum, en hij mag alleen topics waarvan hijzelf de auteur is bewerken)
Deze laag is waarschijnlijk niet voldoende om een prettige website te maken (je kan bijvoorbeeld wel het edit-topic forumlier openen, want dat is in weze alleen een leesactie, maar je kan hem niet opslaan) maar die laatste extra checks om te kijken welke links er allemaal getoond moeten worden, kan je nog wel via een interface erin pluggen.
Marc Cools schreef op 14.03.2009 18:39:
De controle dient ook binnen de controller zelf te gebeuren en niet in een array waar het in opgezocht wordt. Niet zo OOP en gevoelig voor vergetelheden.
Ik denk dat ik toch ergens centraal die gegevens moet opslaan. Ik kan die gegevens dan ook gebruiken om een site omvattend menu te maken, alsook breadcrums en een sitemap. Via een configuratiebestand kan ik dan de inhoud linken binnen deze main_menu class. Maar oeps daar gaat de OOP.
Zo'n main_menu object dynamisch opbouwen als er een request komt, lijkt mij niet aan te raden. Veel te veel nutteloos werk.
Ik zou een tool kunnen maken die alle controllers naloopt en op die manier een config bestand maakt. In elke controller zou dan een array staan met alle functies en hun toegangsniveau. Niet zo mooi doch eens een site operationeel is moet daar in theorie niet meer aan gepruts worden. Bij aanpassingen zou ik dan de tool kunnen starten om het config bestand aan te passen aan de veranderingen.
Moet hierover nog eens goed nadenken.
Heeft iemand anders daar wat nuttige gedachten over?
mvg,
Marc
Jelmer schreef op 15.03.2009 20:21:
Ik denk dat je prima een configuratie-bestandje kan maken met alle namen van de controllers, hun methods, ...
Lijkt mij uiteindelijk nog de meest praktische benadering.
Quote:
... en welke (groepen!) gebruikers erbij mogen.
Ik zou geen hiërarchie maken maar vier bytes zodat ik op 32 punten kan filteren. Elke gebruikersgroep krijgt dan wel of niet één van de 32 rechten. Zodat gebruikers die "hoger" staan niet noodzakelijk ook alle rechten van "lagere" gebruikers hebben.
Quote:
Om jezelf dan te behoeden voor fouten zou je kunnen maken dat wanneer een method niet op de lijst staat, er sowieso geen toegang toe is.
Dit is een prima idee!
Thanks.
Dus Role Based Access Control, met Create Read Update Delete rechten, per controller/method. Hierdoor zou je een eenvoudige validator kunnen bouwen die de request af handeld.