modulaire website, hoe ver moet je gaan?

[xces]

Stel je hebt een universele website met meerdere modules. Je heb ook meerdere klanten die gebruik maken van deze website. Per klant heb je gebruikers.

Momenteel heb ik het zo gemaakt dat ik per gebruiker aan kan geven welke module ze aankunnen. Nu vroeg ik me af of het nut kan hebben om een niveau hoger te gaan, zodat ik per gebruiker moet aangeven welke pagina binnen welke module ze mogen gebruiken, in plaats van alle pagina's in de module.

Wat vinden jullie? Het komt eigenlijk nooit voor dat een gebruiker 1 bepaalde pagina in een module niet aanmag, maar misschien om voorbereid te zijn op de toekomst?

[CyBeR]

Dat regel je imo beter binnen die module zelf.

[xces]

Wat bedoel je? Dat je binnen een pagina van een module aangeeft wie de module aankan? Ik heb er ook al over nagedacht om misschien met rollen te gaan werken;

Je defineert een aantal rollen, bijvoorbeeld (heel simpel voorbeeld):
- Fotos_tonen
- Fotos_toevoegen
- Fotos_wijzigen
- Fotos_verwijderen

En kan per gebruiker aanvinken wat zijn rollen zijn. Als je het namelijk in de module gaat vastleggen, moet je nadat je een gebruiker verwijderd hebt, ook de module aanpassen.

[mithras]

Zelfs het regelen van modules voor gebruikers lijkt me niet handig. Wat ik heb gedaan was een pluginsysteem gebouwd, waarbij alle users een level meekregen. Dan kan de plugin zelf bepalen of de gebruiker deze plugin mag gebruiken. Zo ja, dan regelt de plugin uiteraard ook zelf welke pagina de gebruiker mag zien (weer afhankelijk van je userlevel).

Als je bij de gebruikers aangeeft of hij een module mag gebruiken is dit systeem niet modulair: met het schrijven van een nieuwe module heb je geen zekerheid wat die module gaat doen bij een gebruiker, omdat de gebruiker dit regelt, en niet de module zelf (tenzij je een clausule hebt dat een onbekende module wordt toegestaan of juist niet).

In mijn verhaal is er echter wel een hierarchie. Heb je gebruikers die verschillende modules gebruiken wel parallel staan moet je wel iets anders verzinnen.

xces schreef op maandag 11 december 2006 @ 14:59:
Wat bedoel je? Dat je binnen een pagina van een module aangeeft wie de module aankan? Ik heb er ook al over nagedacht om misschien met rollen te gaan werken;

Je defineert een aantal rollen, bijvoorbeeld (heel simpel voorbeeld):
- Fotos_tonen
- Fotos_toevoegen
- Fotos_wijzigen
- Fotos_verwijderen

En kan per gebruiker aanvinken wat zijn rollen zijn. Als je het namelijk in de module gaat vastleggen, moet je nadat je een gebruiker verwijderd hebt, ook de module aanpassen.

Wat je dus kan doen is als volgt:

code:

Heeft gebruiker genoeg rechten?
  Nee -> stop
  Ja ->ga door
    Gebruiker heeft rank om foto's aan te tonen? Ja-> toon foto's. Nee->doe niets
    Foto's toevoegen? Ja->Mogelijkheid om toe te voegen tonen. Nee->doe niets

etc..

[The Eagle]

Je praat hier over een drietraps beveiliging. Da's heel simpel:
Gebruiker: heeft rol(len)
Rol: bevat permissielijst(en)
Permissielijst: bevat paginatoegang

Is lekker flexibel, werk ik hier ook mee

[xces]

Thanx! Volgens mij denk ik alleen nu te moeilijk, in 6 tabellen

Ik kwam dan tot de volgende entiteiten:

Klant	Klant tabel
KlantContact	Bij 1 klant kunnen meerdere contactpersonen horen
KlantContactRol	Bij 1 contactpersoon kunnen meerdere rollen horen
Rol	Een rol kan gezien worden als een userlevel.
Taak	Een taak kan gezien worden als bijv. heeft CRUD rechten
RolTaak	Aangezien 1 rol meerdere taken kan hebben, moet je dus ook een koppeling tussen beide hebben

Klopt toch wel een beetje zo?

[MSalters]

Neuh, nog steeds te moeilijk. Een contactpersoon heeft meerdere klanten, dus je hebt een N-M relatie. Maak dus een tabel klant, medewerker, en contactpersonen. Contactpersonen is puur een koppeltabel (twee FKs). De rest volgt gewoon uit wat The Eagle zegt. Wat hij een permissielist noemt is bij jou blijkbaar een taak, dat maakt niet veel uit.

[RobIII]

Zoek eens op RBAC

[ Voor 56% gewijzigd door RobIII op 11-12-2006 21:15 ]

[xces]

MSalters schreef op maandag 11 december 2006 @ 20:27:
Neuh, nog steeds te moeilijk. Een contactpersoon heeft meerdere klanten, dus je hebt een N-M relatie. Maak dus een tabel klant, medewerker, en contactpersonen. Contactpersonen is puur een koppeltabel (twee FKs). De rest volgt gewoon uit wat The Eagle zegt. Wat hij een permissielist noemt is bij jou blijkbaar een taak, dat maakt niet veel uit.

Neuj, je begrijpt de opzet niet. Bij 1 klant kunnen meerdere contactpersonen horen (dit lees jij als medewerkers), vandaar die opzet. Doordat deze medewerker meerdere rollen kan vervullen kan ik dus meerdere rechten gaan combineren (om zodoende datgene te bereiken wat ik wil).

@RobIII thanx!

[Verwijderd]

Binnen het Framework waaraan ik samen met een vriend werk voor het ontwikkelen van websites wordt ook Role Based Access Control (RBAC) gebruikt. Zoals Rob||| al aangeeft, is dat de term waar je naar zoekt.
Het artikel RBAC: Gewoon doen! is een perfecte start. In het artikel worden verschillende vormen van RBAC uitgelegd.

Je stelt in je openingspost heel stellig dat het verbieden van een bepaalde pagina nooit voorkomt. Dat is een absolute misvatting. Het ligt aan de doelgroep waarvoor je ontwikkelt, wat nodig is. De gemiddelde website van de bakker op de hoek, heeft dat hoogst waarschijnlijk niet nodig. Het NRC die een heel publicatie systeem heeft van Redacteuren, Journalisten en Hoofdredacteuren, Financiële Directie, wil je dat waarschijnlijk wel.

RBAC is zeer complex, vooral als je op tabel row niveau wilt beveiligen. Kijk voor jezelf wat je wilt beveiligen; modules, acties binnen modules, of zelfs individuele items. Hoe meer je kan, hoe complexer het wordt.

Bekijk de volgende situaties en denk voor jezelf na hoe waarschijnlijk het is dat vergelijkbare situaties in de nabije toekomst door jou geïmplementeerd moeten worden.

Een Journalist mag alleen zijn eigen artikelen zien.
Een Redacteur mag alle artikelen zien.
Een Journalist mag alleen zijn eigen artikelen zien en die van een Stagiaire.
Een Journalist A mag alle artikelen zien, behalve die van Journalist B en Journalist D.

RBAC is niet voldoende, je hebt ook nog Workflow.
Een Journalist mag een artikel toevoegen, maar hij wordt pas geplaatst als een Redacteur hem goedkeurt.

Naast Workflow heb je ook nog Versie Beheer...

Je kan wel een perfect systeem uitdenken, maar dat is zinloos als de moeite die je er in steekt niet wordt terug verdient. Bekijk wat op dit moment de vraag is van het markt segment waarin je werkt. Als huidige techniek niet meer kan voldoen aan wensen van klanten binnen een hoger markt segment, dan is het tijd om verder te ontwikkelen.
Conclusie; begin klein, en werk dat verder uit in de loop der tijd.