[ALG] Rechtensysteem

Pagina: 1
Acties:
  • 151 views sinds 30-01-2008
  • Reageer

  • Maxonic
  • Registratie: September 2000
  • Laatst online: 28-07 22:38
Voor een rechtensysteem maak ik gebruikersgroepen aan waaraan gebruikers toegekend kunnen worden.

Ik ga even uit van 3 verschillende methodes voor het controleren van de gebruikersrechten.
Stel men zit in 3 verschillende gebruikersgroepen. Wat is dan een beter systeem voor het controleren op de gebruikersrechten?

Methode 1 noem ik maar ff de zeefmethode. Hierbij is geen gewicht gedefinieerd.
code:
1
2
3
4
5
6
7
abcd --> akties
----
1010 --> groep x
0011 --> groep y
1011 --> groep z
----
1011

De zeefmethode controleert of je ergens in een gebruikersgroep zit die een bepaalde aktie toestaat. Zo ja, dan krijg je het recht die aktie uit te voeren.
Het voordeel hierbij is dat je je niet druk hoeft te maken dat je wel alle rechten aanvinkt die een persoon zou moeten hebben. Als hij die rechten op grond van een andere gebruikersgroep verdient is het ook goed.
Het nadeel is wel dat de controle enigszins ingewikkelder is dan bij Methode 2 en het is lastig om iemand recht over een bepaalde aktie te ontzeggen.

Methode 2 noem ik voor het gemak maar even de 'top-down' methode.
Hierbij krijgen de verschillende rechten een gewicht mee (kolom 1). Het zwaarste gewicht telt.
code:
1
2
3
4
5
3 1010
2 0011
1 1011
  ----
  1010

Het voordeel van deze methode is dat er slechts gekeken hoeft te worden naar welke gebruikersgroep het zwaarste weegt en vervolgens wat de permissies van deze groep zijn.
Het nadeel is dat, wil je mensen ook op grond van andere groepen toegang tot een bepaald item geven, je veel verschillende groepen moet maken die ieder precies zijn gespecificeerd.

Een derde methode is het gebruik van DON'T CARES. (X)
code:
1
2
3
4
5
3 XX10
2 0X11
1 101X
  ----
  0010

Hierbij geef je expliciet aan of een gebruiker een bepaalde aktie mag uitvoeren of niet.
Ook krijgen alle gebruikersgroepen dan een eigen gewicht.
Deze methode heeft mijn voorkeur maar heeft echter 1 nadeel: :'(
In de vorige methodes kon je de rechten verkort noteren.
code:
1
2
3
4
5
6
7
-------------------
     1         2   
-------------------
1| lees    | eet  
2| schrijf | praat
4| loop    | lach
-------------------

Een gebruiker die mag lezen, lopen en praten kan je noteren als 52
Kolom 1, lezen (1) + lopen (4) = 5
Kolom 2, praten = 2

De werking is simpel. Je mag iets of niet. "Don't cares" kennen we niet. :)
Is er een mogelijkheid om toch een soort van CHMOD systeem te hanteren i.c.m. Methode 3.
Ik breek er al een tijd mijn hoofd over maar echt verder kom ik niet.
Dmv de search ben ik wel wat topic tegengekomen die erop lijken maar niemand schijnt met dit probleem te hebben gezeten.

  • snoopy
  • Registratie: December 2000
  • Laatst online: 16-08 21:26
Misschien is het een idee om eens naar het topic van chem te kijken over een naar mijn mening goed beheersbaar rechtensysteem??

Hierbij: [rml]chem in "[ php/[ my]sql] inherited rechtensysteem"[/rml]

[ Voor 33% gewijzigd door snoopy op 29-09-2003 19:23 ]


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 04:06

.oisyn

Moderator Devschuur®

Demotivational Speaker

Maxonic schreef op 29 september 2003 @ 19:11:
Het nadeel is wel dat de controle enigszins ingewikkelder is dan bij Methode 2
valt wel mee, als het bitfields zijn (flags dus in feite) dan doe je simpelweg een OR op alle rechten.

Waar ik overigens zelf voor zou kiezen is tokens ipv flags, en een rechten-boom.

Tokens zijn gewoon bepaalde id's in de database. Op deze manier kun je dus makkelijk een bepaald recht (een token dus) toevoegen, en hoef je bij de controle alleen maar te kijken of een bepaalde user de juiste token bezit.

De rechten-boom ziet er in principe uit zoals een inheritance tree van OOP. Een gebruiker hoort bij een bepaalde groep, en daar bovenop ligt weer een andere groep, etc. Per groep kun je bepaalde rechten toevoegen, of juist ontzeggen. Eigenlijk heb je dus 3 opties: inherit, allow en deny.

Verstandig is wel om, naast deze structuur in je database te zetten, een soort van gecompileerde array te maken van tokens per user. Die kun je dan bijvoorbeeld in een extra kolom in de user database zetten (als serialized array die direct door de programmacode te interpreteren is bijvoorbeeld, of door een script te genereren die je include (bij scripttalen erg handig))

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Verwijderd

Ik weet niet of dit een antwoord is, je vraag is niet echt duidelijk namelijk.

Maar goed, wat betreft je chmod-systeem.

Het werkt zo:
Je geeft elk recht een cijfer uit de binaire reeks, dus:
CodeRecht
1Toevoegen
2Wijzigen
4Verwijderen
8Nog iets


Als je dit getal opteld kan je altijd achterhalen welke rechten hij heeft.

Dus iemand mag toevoegen en verwijderen, dan krijgt hij 'recht' 5.

[ Voor 3% gewijzigd door Verwijderd op 29-09-2003 20:47 ]


  • kasper_vk
  • Registratie: Augustus 2002
  • Laatst online: 08-04-2025
Ik ben zelf erg te spreken over het rechten systeem in Lotus Notes:
- groepsrechten tellen op (jouw methode 1)
- individuelen mogen ook voorkomen --> individueel recht gaat vóór groepsrecht

Dan is het beheer nog redelijk eenvoudig en kun je toch mensen individueel beperkingen opleggen. Overigens blijft het zaak je groepen goed te definieren en te beheren.

The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny...'


  • Maxonic
  • Registratie: September 2000
  • Laatst online: 28-07 22:38
Chem's systeem zit idd wel leuk in elkaar maar ik vind het een erg omslachtige oplossing voor iets wat zo simpel lijkt.
Ik wil het systeem zoals ik het voorstel wel erg graag aanhouden en het enige wat dus eigenlijk nog zou moeten kunnen is inherited flags hijsen op de wijze van het CHMOD systeem.

Mijn systeem hoeft geen individueel recht te kennen. Maak dan maar een groep met 1 gebruiker is mijn mening.

Ik bedenk me nu ineens...
Wat ik zou kunnen doen is 2 flagsets maken.

1 flagset over wat wel mag
1 flagset over wat niet mag

Het restant geeft dan aan wat de DONT CARE's zijn.

Zoiets als, de gebruiker lezen, lopen en praten maar niet eten.
oftewel, de gebruiker mag wel 52 maar niet 21
Restant hierbij is dan 04 (7 - ( 5 + 2) = 0 en 7 - ( 2 + 1) = 4)

4 is lachen dus of de gebruiker mag lachen hangt af van een gebruikersgroep waar de gebruiker ook lid van is met een lager gewicht.

Echter dit systeem maakt snel fouten... Wat als een gebruik mag lopen en niet mag lopen. Natuurlijk is dit een kwestie van gewoon een goed fouttollerant systeem maken die het niet mogelijk maakt dit soort tegenspraken in de database op te nemen.
Zou dit een idee zijn of id dit echt te vies? :)

@ D2K: Dat topic ken ik al. Gaat meer over de techniek achter het flaggen. Dit topic moet echter het probleem van een overervend systeem oplossen. tnx anyway :)

[ Voor 8% gewijzigd door Maxonic op 29-09-2003 20:04 ]


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25

D2k

of zie 7 = 4 + 2 + 1

Doet iets met Cloud (MS/IBM)


  • Tux
  • Registratie: Augustus 2001
  • Laatst online: 21-08 06:33

Tux

snoopy schreef op 29 September 2003 @ 19:23:
Misschien is het een idee om eens naar het topic van chem te kijken over een naar mijn mening goed beheersbaar rechtensysteem??

Hierbij: [rml]chem in "[ php/[ my]sql] inherited rechtensysteem"[/rml]
Ik ben zelf ook 'fan' van dit rechtensysteem :P Dat komt omdat de code betrekkelijk eenvoudig is en er zijn toch complexe structuren mogelijk. (Wat er hier dus op GoT mogelijk is aan rechtenstructuren :P).

Zelf gebruik ik voor mijn eigen applicaties meestal iets wat lijkt op het systeem van chem. Waar ik ook over zit te denken is het cachen van rechtensets zoals al eerder genoemd. Maar ik weet nog niet precies hoe je bijvoorbeeld verifieërd of er wijzigingen zijn geweest.

Wat ik het nadeel vind van chmod achtige rechtensystemen is, is dat je verdomd goed op moet letten of je wel precies de juiste berekening uitvoert en je ziet minder snel aan een rij cijfers welke rechten de persoon nou precies heeft.

Ik heb wel van eerdere rechtensystemen geleerd dat je alles zo flexibel mogelijk moet maken, en eigenlijk niets moet vastleggen. Mijn oude rechtensysteem voor m'n forum was bijvoorbeeld alleen maar instelbaar op forum niveau en of een topic van de user zelf was of niet. Bij het nieuwe rechtensysteem is het mogelijk om op alle niveau's (board, categorie, forum, topic, post (misschien dat rechten op een topic of post wat overdreven zijn, alhoewel het wel handig is als je bijvoorbeeld een gebruiker een FAQ wil laten maken met html)) de rechten in te stellen.

The NS has launched a new space transportation service, using German trains which were upgraded into spaceships.


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 04:06

.oisyn

Moderator Devschuur®

Demotivational Speaker

Tux schreef op 29 September 2003 @ 22:56:
Ik ben zelf ook 'fan' van dit rechtensysteem :P Dat komt omdat de code betrekkelijk eenvoudig is en er zijn toch complexe structuren mogelijk. (Wat er hier dus op GoT mogelijk is aan rechtenstructuren :P).
van wat ik ervan begrepen heb is het rechtensysteem uitermate complex terwijl dat in principe helemaal niet nodig is. Bovendien gebruiken ze flags, geen tokens :P (geloof dat dat in React 2.0 gewijzigd wordt, aldus chem)
Zelf gebruik ik voor mijn eigen applicaties meestal iets wat lijkt op het systeem van chem. Waar ik ook over zit te denken is het cachen van rechtensets zoals al eerder genoemd. Maar ik weet nog niet precies hoe je bijvoorbeeld verifieërd of er wijzigingen zijn geweest.
Gewoon bij elke wijziging opnieuw cachen (php script updaten, cache tabel in database wijzigen, whatever)
Wat ik het nadeel vind van chmod achtige rechtensystemen is, is dat je verdomd goed op moet letten of je wel precies de juiste berekening uitvoert en je ziet minder snel aan een rij cijfers welke rechten de persoon nou precies heeft.
Een goede programmeur gebruikt daar defines voor. Een ander nadeel is overigens wel dat je vrij gelimiteerd bent aan het aantal rechten, wat je bij tokens dus niet hebt

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Pagina: 1