Wie kan mij een goede ACL omschrijven? db model
Ik zit met het probleem een goede ACL uit te werken. Ik weet wel ongeveer wat een ACL is, dat je werkt met user/role/activity, maar hier werk je met een vooraf gedefinieerde lijst.
Hoe kan het opgezet worden dat je meerdere groepen hebt met bepaalde rollen? Dat rollen worden toegekend door middel van een groep waar je als gebruiker in zit?
Dat je dus niet een 1-n hebt tussen user-role en een n-n op activity, maar dat je dus een extra group krijgt waar je dit in kunt zetten?
Wat ik heb zijn de tabellen:
user
role
action (resources/activity ? hoe je het wil noemen)
group
grouplist
Waar group list een koppeltabel is tussen groep en action
Rol en group hebben een 1-n relatie en user-role heeft ook een 1-n relatie.
Maar op de een of andere manier klopt het niet. Wat ik dus vraag is of iemand mij inzicht kan verschaffen in dit vraagstuk.
Groet, M
Gesponsorde koppelingen:
Edit:
laat je group en grouplist dus vervallen. Begin met users en rollen en werk dan uit hoe je een rol aan een rol kan toekennen en later afwegen uiteraard. Groepeer je functies in je programma en bedenk daar een rol bij enz.
laat je group en grouplist dus vervallen. Begin met users en rollen en werk dan uit hoe je een rol aan een rol kan toekennen en later afwegen uiteraard. Groepeer je functies in je programma en bedenk daar een rol bij enz.
Gewijzigd op 05/08/2010 20:53:00 door Aad B
Bedankt voor je reactie. Ik heb er zelf ook al over zitten na denken. Wellicht is het handig inderdaad om meerdere acties aan rollen toe te kennen.
Waar het mij om ging/gaat is eigenlijk dat ik die n-n relatie wil voorkomen. Dit wou ik dus oplossen door de group er tussen te zetten. Maar wellicht dat die namen een beetje verwarrend zijn.
Stel ik heb een rol genaamd: fotograaf, daar horen bij wijze van spreken 6 toegekende taken bij.
Nou wil ik niet dat een gebruiker dus slechts 1 rol kan vervullen, wat dus effectief betekent dat je meerdere gebruikers meerdere rollen krijgen. Maar toen ik daar logisch over ging nadenken, viel m`n aanname weg.
Immers, je kunt 1 gebruiker meerdere rollen toe kennen. Wat nog steeds betekent dat je een 1-n relatie krijgt. De group is dus eigenlijk niet per definitie nodig.
Ik ga eerst de rollen omschrijven, kijken in hoeverre ik denk rollen nodig te hebben en pas daarna begin een een db model te maken. Ik denk namelijk dat het standaard model van user/role/activity wel stand houdt zonder flexibileit op te geven.
PS. Group moest dus een collectie worden van rollen. Een betere naam was/is waarschijnlijk profiel. Op die manier kun je zelf profielen samen stellen en die toekennen aan gebruikers, maar ook dan kom je weer uit dat je meerdere profielen aan aan meerdere gebruikers toe kunt voegen.
Maar snap je m`n probleem? Althans, het probleem valt nu eerst weg, eerst rollen beschrijven en dan pas nadenken over rollen, maar goed..
Je introduceert een extra moeilijkheid, een laag qua programmeren tenzij je een strakke hierarchie user/profiel/role/activity aanhoudt en het dus voor kan komen dat 1 user 1 profiel heeft en in dat profiel zit 1 rol. In feite is dat profiel dus een rol met een rol. Probeer daarin te blijven is mijn idee en later met aftesten: user x mag hij functie y ? check de rol die hij heeft, zit functie y daarin zonee, zit er in de rol die hij heeft een andere rol en zit is daar functie y toegestaan enz.
Het is alleen wel een rol in een rol, zo zie ik. Even kort door de bocht: Admin is een cumulatief van gebruiker/moderator/beheer + eigen rol, wat dus ook gewoon een combinatie is van rollen. Ik snap je punt.
Maar dit valt wellicht af te vangen door die rollen zelf als pre definieerbaar te maken. Dus al een rol "admin" te maken waar alle presets van gebruiker/moderator/beheerder/admin in vallen.
Dat is in het begin wat lastig, maar wellicht een betere oplossing.
