Ik zit er aan te denken om nog eens wat in PHP te gaan doen. Als basis wil ik eerst en vooral een degelijk 'usermangement system' opzetten. Dit in een object gericht concept.
Omdat hierbij zowel het databaseontwerp als het implementeren van de code zelf belangrijk zijn, zou ik deze graag beiden bespreken.
De database zou ik als volgt willen inrichten:
Misschien kort even het schema toelichten:
In de database wordt over elke gebruiker wat basisgegevens bijgehouden. Er kunnen eventueel een aantal opmerkingen gemaakt worden over een gebruiker. (bv. zijn specifieke functie op de website). Verder is er verplicht een koppeling met de permissies tabel. Uiteraard, behoord een 'permissie-entry' altijd aan 1 specifieke gebruiker. (kleine opmerking hieronder) Verder worden alle belangrijke zaken die een gebruiker uitvoert gelogd. Tot slot is er nog een tabel met sessies in (Ik ben van plan een eigen session handler te programmeren die via de database werkt.) Elke sessie verwijst naar 1 gebruiker.
[opmerking permissies]
Ik overweeg dit nog wat aan te passen, namelijk een toevoeging: groups. Elke gebruiker krijgt dan een group en een group krijgt op zijn beurt een aantal permissies.
In PHP zou ik dan volgende klassen bekomen:
Session, User, Log, Note. Wat deze doen, lijkt mij vanzelfsprekend. Indien dat niet het geval zou zijn, wil ik dit gerust even toelichten.
Daarom ook dat ik dacht, een tabel met de gebruikers, een tabel met de groepen en een tabel met de permissies.
Wat altijd zeker is: een groep is verbonden aan een permissie record.
Een gebruiker daarentegen is OF met een groep verbonden OF met een permissie record. Nooit beide. (althans niet rechtstreeks) Volgens mij blijft dit dan toch de handigste manier?
Ook als je bijvoorbeeld nog verder gaat, je kent aan een gebruiker een groep toe, maar wilt bijvoorbeeld nog 1 extra permissie. Dan heeft een gebruiker dus zowel een groep record als een permissie record.
Misschien moet je dan nog verder gaan, een tabel voor de gebruikers, wen tabel voor de groepen, een (koppeltabel) voor de combinatie groepen/gebruikers en een tabel voor de permissies voor een groep dan wel een gebruiker. Op die manier ben je aardig flexibel.
Jeroen, ben het eens hoor. Maar vroeg me af wat Ger bedoelt. Vandaar dat ik even een schets maakte. Wat zou dan volgens jou de ideale oplossing zijn?
[size=xsmall]Toevoeging op 04/07/2012 12:28:08:[/size]
Ik laat heel even het SQL gedeelte voor wat het is. Als iemand zich geroepen voelt om te reageren: graag!
Ik heb deze voormiddag al wat UML's zitten te tekenen en zou nu werkelijk willen starten met het programmeren. Alleen, na het herlezen van een post van Wouter zat ik even te denken. Ik kwam uit op SessionHandlerInterface. Die ga ik sowieso momenteel nog niet gebruiken. Ik wil mijn applicatie liefst werkend vanaf 5.3. (dit is bij mijn weten nu zo'n beetje de standaard) Uiteraard zou ik deze interface zelf kunnen implementeren.
Ik denk echter dat dat niet de bedoeling van Wouter was. Wat ikzelf nu van plan ben is in de 'Storage' klasse een aantal basis methoden zou gaan schrijven. Bijvoorbeeld om kunnen te schrijven naar een bestand en opslaan in de database. Ik zou dus SessionStorage laten extenden van Storage en e.v.t. de SessionHandlerInterface implementeren. Graag jullie meningen!
Wat ik bedoelde is dat je niet noodzakelijk hierarchies hoeft te denken bij het toekennen van rechten. Ik beschouw een groep als een object met daarin een x aantal userobjects. Maar een user kan ook tot meerdere groepen behoren, vandaar de koppeltabel.
Ik denk bij het toekennen van rechten ook altijd OO.
Die laatste tabel is bedoeld om rechten te kunnen toekennen op bv de users en groups tabellen.
Dit lijkt misschien een beetje overkill, maar met dit systeem kun je dus over je hele website gericht rechten uitdelen, niet alleen puur in gebruikers gedeelte zelf.
Als ik nog een duit in het zakje mag doen.... ik zou echt niet permissies instellen op group OF user niveau. Ofwel het een, ofwel het ander, met een voorkeur voor groepen.
Doe je het beide dan maak je je queries alleen maar nodeloos moeilijk en het levert je geen extra flexibiliteit op. Je kan namelijk altijd al een groep aanmaken voor 1 persoon. En in werkelijkheid kan ik me niet voorstellen dat je buiten een paar specifieke gevallen om (eigenaar, bepaalde VIP user) de rechten wil toekennen aan maar 1 persoon.