[CMS] Indeling rollen / functies

[oZy]

Ik heb vanmiddag een bespreking over hoe we de verschillende rollen/functies gaan verdelen in ons CMS.

Nu vroeg ik me af of er niet ergens een model bestaat betreft content ownership / content management, waar de basis van het beheer wordt beschreven / verdeeld.

In het kort: wie mag wat doen?

Ik snap dat dit voor iedere situatie anders is, maar een CMS is 1 ding, de manier waarop ermee gewerkt wordt is heel wat anders, en minstens zo essentieel. Misschien dat er hier mensen zijn die tegen dingen zijn aangelopen? Of wat tips hebben. bvd

[chris]

Je kan een tabel maken met

code:

page_id uid pid

En dan moet je dus voor elke pagina een uniek id genereren, en je kan dan een user (uid) een recht geven (pid).
pid = 1 -> Bekijken
pid = 2 -> Bewerken
pid = 3 -> Verwijderen.

[oZy]

voor de goede orde: ik wil niets weten over de techniek van een CMS, we hebben al een zeer uitgebreid CMS.

In dit CMS kunnen we verschillende groepen maken (rollen) waar we users aan toevoegen. Maar nu is de vraag, hoe gaan we deze indeling maken? Denk hierbij aan een grote onderneming onderverdeeld in divisies die elk hun eigen site hebben en die ze ook moeten beheren. Maar waar leggen we de grenzen van de verantwoordelijkheid? De content moet natuurlijk aan zeer strenge eissen voldoen, dus hoever kan je gaan met rechten geven.

Ik ben gewoon benieuwd of er meer mensen zijn die hierover hebben nagedacht, en of er misschien mensen zijn die tegen praktijk problemen zijn aangelopen mbt dit onderwerp.

[LuCarD]

Ik ben nu bezig met een uitgebreide CMS en daar heb ik de gebruikers op gedeeld in meerdere groepen.

0 - normale gebruikers
1 - administrators
2 - admin afd a
3 - admin afd b
.
.
10 - html posters

Iedereen zit altijd in groep 0. Elke administror zit in groep 1 dus ook mensen van afd a,b ...
Daarna als een admin een edit wil maken in afd a moet hij dus tot groep 1 en 2 horen. Wil hij de mogelijkheid hebben om html te gebruiken dan moet hij in groep 1,2,10.

that's it.

Ik heb voor de login 3 tabellen gebruikt.
users - userid, pass, username, .....
groups - groupid, groupname
rights - userid, groupid

tijdens login worden alle rights in een array gedumpt en in een kant klare sql statement zoiets als "groupSQL in (0,1,2)"

De array gebruik je dan om makkelijk een vergelijking te maken of iemand dat mag zien (in de logica)
de klantklare sql gebruik je om te vergelijken of een user die data wel uit de database mag halen.

that's it for me....
Iemand een denk fout ontdekt gaarne laten weten aangezien ik nog bezig ben kan ik nog veel veranderen!!!

[Nielsz]

Ik zou geen oplopende getallen doen
maar ik zou gaan voor:
1 - mag lezen
2 - mag replien
4 - mag editen
8 - mag trashen

Nu kan je elke combi maken die je wilt.

[D2k]

[topic=356022/1/25]
bekijk dit topic eens
heb je btw wel ff gezocht naar "rechten" oid hier?

[dusty]

Op woensdag 30 januari 2002 11:22 schreef Nielsz het volgende:
Ik zou geen oplopende getallen doen
maar ik zou gaan voor:
[..]
Nu kan je elke combi maken die je wilt.

En ik ben het er nog steeds mee oneens

[LuCarD]

Op woensdag 30 januari 2002 11:24 schreef D2k het volgende:
[topic=356022/1/25]
bekijk dit topic eens
heb je btw wel ff gezocht naar "rechten" oid hier?

Nee... Hoezo

[Nielsz]

Op woensdag 30 januari 2002 11:26 schreef dusty het volgende:

[..]

En ik ben het er nog steeds mee oneens

* staande ovatie *
zo mooi onderbouwt zie ik ze niet vaak

[Nielsz]

in mijn nieuwe project doe ik het iig zo:

GU_id
Cat_Id
Right
GU

GU staat voor Group User.
In principe stel je in dat het voor een group is, maar eventueel kan je ook zeggen dat het over een user gaat.
Dan krijg je dus:

code:

select cat_id,right from table where (GU_id=$groupid and GU=G) or (GU_id=$userid and GU=U) order by cat_id,GU

while()
{
$cat[$result[0]]=$right;
}

Nu krijg je dus een array met je rechten (van de group), en als je nog rechten per persoon hebt gemaakt, dan schrijven die de groupsettings over.
Btw in de right dinges zet ik "PRED" (post, repy, edit, delete) oid.

[Verwijderd]

Wat jij bedoel is Roll Based Security. Meestal wordt in een CMS uitgegaan van een redactie schema. En heb je vaak het rollensysteem wat op redacties gebruikt wordt zoals, schrijver, redacteur, eindredacteur etc.

Wat je dus krijgt is dat een artikel wat door de schrijver is gemaakt wordt gecontroleerd door de redacteur, en eindredacteur alvorens het live wordt ge-published.

Als voorbeeld voor een basic CMS kun je tabellen als volgt indelen.

TABEL gebruiker
id (auto-increment)
username
paswoord (encrypted)
usergroup (id van de row uit de tabel groepen, omdat group een gereserveerd SQL woord is gebruik ik dit niet, het is overigens wel te gebruiken als je singlequotes gebruikt in je SELECT aanroep)
approving (id van de user welke toestemming verleent)

TABEL groepen
id (auto-increment)
name
policy (id van de row uit de tabel policies etc.)

TABEL policies/rechten
id (auto-increment)
article_read (boolean)
article_write (boolean)
article_edit (boolean)
article_remove (boolean)
article_publish (boolean)
article_approver (boolean)


Je hebt zo een heel schaalbaar model, en je kunt snel en makkelijk nieuwe policies toewijzen, groepen toewijzen, en users updaten.

De table policies kan uiteindelijk heel erg veel columns bevatten, daarom voor het overzicht gebruik ik voor modules een eigen policy table.

Je kunt er ook voor kiezen om approver naar de groups table te wijzigen, zodat je groups en approving beter kan scheiden. Nadeel is wel dat 1 wijziging van invloed is op alle gebruikers binnen die groep.

Dit is een heel basic voorbeeld, maar het is zo schaalbaar dat je het bijna oneindig kunt uitbouwen. Voor toewijzen van rechten gebruik ik express geen list zoals 1,0,2,3,0,4 omdat ik dan later alle rows zou moeten gaan updaten zodra ik nieuwe rechten toeken. Nu kan ik dat doen dmv 1 ID.

Beetje duidelijker zo?

[oZy]

Op woensdag 30 januari 2002 12:51 schreef Gordijnstok het volgende:
Wat jij bedoel is Roll Based Security.

[...]

Beetje duidelijker zo?

idd, roll based security, en ja erg duidelijk, tnx!

[Verwijderd]

Security hangt samen met je workflow: wanneer worden welke acties mogelijk en wie mag dan die acties doen?

Hoe je het ook wend of keert: het komt er op neer dat een invididu een setje acties meedraagt die hij/zij mag uitvoeren. rollen, groepen etc, ze dienen om het geheel beheersbaar te maken / houden, maar nodig zijn ze niet.

Als je dmv welke gui dan ook, hebt aangegeven als beheerder wie welke acties mag plegen, kun je dmv het testen op die acties kijken of iemand bepaalde onderdelen van de workflow mag bekijken uberhaupt (iemand die geen publish rechten heeft hoeft dat menu niet te zien bv).

Hoe je de rechten implementeert hangt ook af van hoe je CMS is opgezet. 9 van de 10 CMS'en zijn page-based: men legt rechten vast op basis van een page. Wat je ook kunt hebben, zoals ons CMS, is een CMS dat item-based is, dus gebaseerd op informatiedeeltjes. Die zijn van een bepaald type. Bv 'nieuwsitemtype' of 'productbeschrijvingtype'. Die kunnen op 1 page staan, maar men kan bv edit/delete/archive rechten hebben op het nieuwsitemtype maar niet op het productbeschrijvingstype. Rechten dan implementeren op basis van pages gaat niet werken.

Security is het beste in te bouwen op een zo'n laag mogelijke layer op een zo'n klein mogelijk onderdeeltje van je CMS: kun je een dataelementje niet wijzigen, wat onderdeel is van een groter geheel? Dan kun je dat grotere geheel ook niet wijzigen, want je kunt dat dataelementje niet wijzigen. Security in de kleine basisbouwstenen inbouwen is veelal goed te doen en goed overzichtelijk te houden. Al wat rest is de code daarbovenop goed solide te maken zodat een 'security voilation' op een lager niveau resulteert in het gewenste resultaat (in het voorbeeld hierboven dus het afkeuren van een wijziging in dat grotere geheel op basis van een security voilation op een lager niveau).

Je moet ook je security model niet laten vertroebelen door alle mogelijke rollen/groepen structuren te kunnen aanmaken in een gui. Het individu, daar gaat het om, die erft rechten van alle groepen waar dat individu in zit, en DIE is bezig met het systeem, niet de groep. Wanneer een user inlogt, stel je een set acties samen wat die user kan op basis van de rechtenboom van groepen/roles en die set rechten gebruik je om te testen of een user iets mag of niet. Dit kun je eventueel static opslaan in een redundante table, die de rechten op roles / groepen uitwerkt per individu (en jij moet die telkens updaten wanneer men rechten op roles/groepen wijzigt, maar dat is bijzaak). Je kunt dan snel toetsen in de database (bv dmv 1 enkele call van een security check stored proc in je stored procs) of de calling user mag wat de stored proc wil gaan doen (page publiceren oid).