Goede auth class maken
Ik ben bezig met mijn eigen systeem dat gebaseerd is op MVC.
En nu wil ik voor al mijn dashboard controllers een auth class/functie gebruiken zodat deze goed beveiligd is.
Normaal gezien zou ik wat gaan proberen en als het me goed "lijkt" zo laten.
Deze keer wil ik voordat ik er mee begin eigenlijk al om hulp vragen.
Kan iemand mij vertellen hoe ik een goede beveiliging opzetten maar wel op zo'n manier dat deze zowel te gebruiken is voor gebruikers als administrators.
Dit zou ook een mooi moment zijn voor een goede discussie om erachter te komen wat men liever doet.
M.V.G,
Wouter.
Topic verplaatst naar het OOP onderdeel[/modedit]
Gewijzigd op 03/05/2015 11:20:51 door Wouter J
Ik weet niet of dat helemaal de lading denkt, maar ik heb over dit topic zeer recent een artikel geschreven (shameless self plug).
Bekijk ook vooral het voorbeeld.
Sure, het is niet echt OOP, maar wel retesimpel en volgens mij best krachtig. En je kunt hier best een eenvoudge class omheen fietsen.
Hier zijn natuurlijk 568036873555783857359873 mogelijke varianten op te bedenken.
De bovenstaande site (eigen framework) maakt hier ook gebruik van om adminpagina's en dergelijke af te schermen.
Gewijzigd op 02/05/2015 22:48:08 door Thomas van den Heuvel
Toevallig heb je topic inderdaad al gelezen ja.
En heel eerlijk ik snap daar totaal niks van.
Komt meer om het feit hoe je rechten benoemt en dergelijke.
Ik ben gewend om het volgende te zien :
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
// Fake check
$user = User::select(1); // admin gebruiker ophalen.
Auth::hasRights('PAGE FROM DB', $user); // $user->rigts of $user->level
// In auth class.
if($page['needed_rights'] == $user->rights) {
// true....
?>
// Fake check
$user = User::select(1); // admin gebruiker ophalen.
Auth::hasRights('PAGE FROM DB', $user); // $user->rigts of $user->level
// In auth class.
if($page['needed_rights'] == $user->rights) {
// true....
?>
Misschien kun je me beter uitleggen hoe jouw manier werkt.
Het voordeel van een geserialiseerde expressie is dat je deze ontkoppelt van code (deze is dus niet meer hard-coded maar dynamisch).
In mijn variant evalueer je de expressie tegen een set van rechten. Dit levert dan een simpel "ja" of "nee" op.
Bijvoorbeeld: de expressie bevat een statement die beschrijft welke rechten je nodig hebt voor toegang tot een pagina. De set van rechten kunnen de rechten van de huidige gebruiker zijn. Daarmee kun je dus heel simpel de vraag "mag deze gebruiker deze pagina zien" beantwoorden, en de rechten die nodig zijn om toegang te krijgen tot de pagina kun je dus per pagina instellen. De "check" zelf blijft ongewijzigd.
Het artikel beschrijft dit eigenlijk stap voor stap :s.
EDIT: het gebruik is verder vrijwel hetzelfde als jouw voorbeeld hierboven:
Code (php)
Die geserialiseerde expressies blijven verder "onder water", waar de gebruiker tegenaan kijkt is een boompje waarin ze kunnen klikken en waar ze de rechten-expressie op een semi-gebruiksvriendelijke manier kunnen opbouwen.
Gewijzigd op 02/05/2015 23:46:22 door Thomas van den Heuvel
Als het over auth gaat dan spreek je toch 1 class aan? En die dan niet static denk ik.
Wil je meerdere classes aanspreken dan heb je het niet bij het juiste eind en kan je misschien met interfaces werken.
Want volgens mij ben ik best duidelijk geweest toen ik zei : ik ben gewend om dit te zien.
Ik heb van te voren al naar oplossingen gezocht maar weet niet of dat wel correct is.
Daarom wil ik nu dus een goede beveiliging hebben die ik voor meerdere groepen gebruikers kan gebruiken.
Verder lijkt me de Auth class mij meer een helper class.
Dus als ik die voorbij zou zien komen in een code kan ik best begrijpen als iemand daar eerder een static functie gebruikt ipv van te initialiseren.
http://www.sitepoint.com/role-based-access-control-in-php/
In een MVC model zijn er drie handige momenten om op de rechten te controleren:
- door de router/dispatcher om hele delen van de URI af te schermen.
Bijv: mydomain.com/admin/??? (alles wat met admin begint dus)
- bij de Controller methods
- in de view (om bijv een bepaalde div wel of niet te laten zien)
Gewijzigd op 03/05/2015 11:52:57 door Frank Nietbelangrijk
Je hebt een collectie van soortgelijke resources (denk bijvoorbeeld aan artikelen of pagina's) waar je op grond van permissies toegang toe krijgt; nog enkel even toegang, we hebben het niet eens over andere bewerkingen zoals wijzigen of verwijderen. Nu heb je dus bijvoorbeeld een of meer classes voor het opzetten/aanmaken/afdrukken etc. hiervoor: Article, Page, whatever.
Vervolgens wil je gaan vastleggen wie toegang heeft tot deze artikelen / pagina's. Waar doe je dit? Rechtstreeks in deze code? Maar dan timmer je dus permissies vast op "Klasse niveau", tenzij je Henk, Piet, en Klaas elk verschillende rechten geeft die je allemaal opneemt in de controlelijst. Het probleem is dus een beetje dat je geen verschillende permissies kunt hebben voor eenzelfde resource, althans, RBAC voorziet daar niet (standaard) in?
Dit is misschien verwarrend, dus een voorbeeld: stel je hebt een set artikelen: 1,2,3. Hoe kun je met RBAC aangeven dat artikel #1 alleen toegankelijk is met rol/permissie A, artikel #2 alleen met rol/permissie B en (nog een complexere variant) artikel #3 alleen toegankelijk is als je ZOWEL rol/permissie A ALSMEDE rol/permissie B hebt?
Dit moet je wel aan de individuele resource-instances hangen (als je zulke fine-grained control wil)? En in de klasse(s) zelf moet je generieke checks hebben die zulke controles kan uitvoeren. Generiek, omdat niet op voorhand vaststaat hoe zo'n check er uitziet.
Dit is precies waar een/mijn ACL in voorziet.
Tis maar net welke mate van controle je wilt hebben. Enkel met het kiezen van een authorisatiestrategie ben je er niet: je moet dan nog je rollen/rechten/etc. gaan inrichten en ook is daar de manier waarop je omspringt met de componenten waarmee je gebruikers bewerkingen wilt laat uitvoeren.
Je zou het dus eigenlijk om moeten draaien: welke functionaliteit heb je, wat voor bewerkingen wil je hier (door welke) gebruikers op laten uitvoeren. Op grond daarvan zou je eigenlijk een strategie moeten kiezen.
Dank voor jullie reacties.
Ik heb inderdaad al eens die Role Based Acces Control gezien op sitepoint.
Reden dat ik niet direct die weg ben in gegaan is de datum dat het artikel geplaatst is.
Maar als voorbeeld zijnde is het eigenlijk wel wat ik zoek.
Hetgeen wat jij bedoelt thomas zal voor mijn website niet echt van toepassing zijn.
Indien het bijvoorbeeld zover komt dat ik bepaalde urls die beginnen met iets wil blokkeren voor andere gebruikers zou ik dit via de db instellen. ( dat zal zo gedaan zijn dmv wat tabellen.)
Ik zal nog eens het artikel doorlezen en er mee beginnen.