gebruikerstoegang in een MVC omgeving

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Marc Cools

Marc Cools

14/03/2009 18:39:00
Quote Anchor link
Hallo,

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.
 
PHP hulp

PHP hulp

12/07/2024 11:53:22
 
Martijn Wieringa

Martijn Wieringa

14/03/2009 18:47:00
Quote Anchor link
Ik zou elk recht een naam/code geven, en per recht cache'en welk recht de huidige gebuiker heeft.

Vervolgens kunnen overige objecten iets doen als:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
if($oUser->getRight('RIGHT_NAME'))
{
}
 
Jelmer -

Jelmer -

14/03/2009 22:04:00
Quote Anchor link
Ik zou het in de controllers zelf doen. Ik neem aan dat je een of andere manier hebt om gemakkelijk bij je model-laag te komen? Een soort registery pattern, of misschien een property ergens in de base-class van je controllers?

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

Marc Cools

15/03/2009 20:07:00
Quote Anchor link
Die layer rond de data is interessant. Gelijk hoe je de gegevens benaderd, toegang word gecontroleerd. Zeer veilig en kan perfect OOP. Ik geef de voorkeur om de controle op pagina niveau toe te passen. zodat ook pagina's die geen model gebruiken ook kunnen gecontroleerd worden.
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 -

Jelmer -

15/03/2009 20:21:00
Quote Anchor link
Ik denk dat je prima een configuratie-bestandje kan maken met alle namen van de controllers, hun methods, en welke (groepen!) gebruikers erbij mogen. 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.
 
Marc Cools

Marc Cools

15/03/2009 20:52:00
Quote Anchor link
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.
 
Ed

Ed

19/03/2009 19:36:00
Quote Anchor link
Een goede manier is het RBAC model toepassen op de CRUD rechten.

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.