[PHP] Rechtensysteem

[Deviruchi]

Ik ben nu aan de gang met een rechtensysteem, maar ik zit nu vast.
Het is de bedoeling om de rechten op te slaan in een getal, en om dat dan te converteren naar binair, en daar vervolgens per 1 of 0 kijken welke rechten daarbij horen. Dit lijkt omslachtig, maar het levert ons een cleanere database op, en daar gaat het ons om.
Nu heb ik de volgende rechten en bijbehorende waarden:

Rechten

Omschrijving Waarde
Can_read_user 1
Can_create_user 2
Can_modify_user 4
Can_delete_user 8

Can_read_performance 16
Can_create_performance 32
Can_modify_performance 64
Can_delete_performance 128
Can_join_performance 256

Can_read_research_question 512
Can_create_research_question 1024
Can_modify_research_question 2048
Can_delete_research_question 4096
Can_join_research_question 8192

Voorbeeld
Een Leerling mag wel prestaties bekijken en zich er voor aanmelden, hetzelfde met onderzoeksvragen. De gebruiker mag verder niks met andere gebruikers doen.

Can_read_performance = 16
Can_join_performance = 256
Can_read_research_question = 512
Can_join_research_question = 8192
Totaal = 8976

Oftewel Binair:
10001100010000

Hoe kan ik nu via een functie berekenen welke rechten die persoon precies heeft? Ik gebruik nu decbin(), maar nu is dus het 'probleem' dat ik dan soms kleinere getallen krijg, denk aan 1101, moet ik er dan nullen voor gaan plakken? Ik gebruik trouwens PHP 4, dus str_split is geen optie.

PHP:

<?php
function getRights ( $iRights ){

    //Set the rights into a binary format.
    $iBinaryRights = decbin( $iRights );

}
?>

Hoe zou ik dan ooit de binaire nummers door moeten lopen om de rechten te krijgen?
Ik zat zelf te denken om al die getallen in een array te zetten, maarja, aangezien ik dus geen str_split kan gebruiken heb ik geen idee hoe, en substr lijkt me weer iets te omslachtig.

Kan iemand van jullie hier een helder licht op schijnen? Nee, dit is geen code-request, ik heb gewoon een klein duwtje in de rug nodig, als ik het licht zie kan ik er wel naar toe lopen zegmaar ;o.

[RedHat]

Waarom definiëer je niet elke recht zoals je hierboven hebt gedaan maar dan met 3 tabels

1 Users
2 Rights (canViewUsers b.v.) met een 1 of een 0.
3 LinkedRights (UserID 3 heeft rechtenset 3)

En dan een class maken die controleerd welke gebruiker het is, welke rechtenset hij heeft, en welke rechtenset op 1 moet staan om deze pagina te bezoeken.

[justmental]

Je hebt in principe geen binaire representatie van de rechten nodig.
Het controleren van de rechten kan met een bitand functie (geen idee hoe deze heet in php).

[RobIII]

Deviruchi schreef op dinsdag 13 maart 2007 @ 13:16:
Dit lijkt omslachtig, maar het levert ons een cleanere database op, en daar gaat het ons om.

En wat denk je dat gebruikers er om geven? En gaat het daar uiteindelijk niet om?

Deviruchi schreef op dinsdag 13 maart 2007 @ 13:16:
Hoe kan ik nu via een functie berekenen welke rechten die persoon precies heeft? Ik gebruik nu decbin(), maar nu is dus het 'probleem' dat ik dan soms kleinere getallen krijg, denk aan 1101, moet ik er dan nullen voor gaan plakken? Ik gebruik trouwens PHP 4, dus str_split is geen optie.

Je kunt met wat and-en en or-en de juiste rechten wel 'bepalen', maar ik zou dus al in den beginne niet voor dit 'systeem' gaan. Kijk eens naar (bijv.) RBAC, ook "clean" en vele vele malen makkelijker te beheren.

Deviruchi schreef op dinsdag 13 maart 2007 @ 13:16:
Hoe zou ik dan ooit de binaire nummers door moeten lopen om de rechten te krijgen?

Que
Gewoon met and/or de juiste bits er uit filteren; maar ik heb het idee dat booleaanse logica je nog wat ontgaat; daarom zie ik ook niet waarom je dan juist voor dit systeem zou kiezen.

Toch nog een tip: voila

[ Voor 4% gewijzigd door RobIII op 13-03-2007 13:26 ]

[NMe]

justmental schreef op dinsdag 13 maart 2007 @ 13:22:
Je hebt in principe geen binaire representatie van de rechten nodig.
Het controleren van de rechten kan met een bitand functie (geen idee hoe deze heet in php).

Gewoon met de &-operator?

[Deviruchi]

RobIII schreef op dinsdag 13 maart 2007 @ 13:24:
En wat denk je dat gebruikers er om geven? En gaat het daar uiteindelijk niet om?

True, ware het niet dat de gebruikers leerlingen van de school zijn, en die daar nou eenmaal niet zo veel mee te maken hebben.

Je kunt met wat and-en en or-en de juiste rechten wel 'bepalen', maar ik zou dus al in den beginne niet voor dit 'systeem' gaan. Kijk eens naar (bijv.) RBAC, ook "clean" en vele vele malen makkelijker te beheren.

Klopt, maar dit gaat me nog aardig boven de pet, misschien dat ik hier later eens naar ga kijken, maar daar heb ik nu niet genoeg tijd voor.

Que
Gewoon met and/or de juiste bits er uit filteren; maar ik heb het idee dat booleaanse logica je nog wat ontgaat; daarom zie ik ook niet waarom je dan juist voor dit systeem zou kiezen.

Toch nog een tip: voila

Die laatste site heeft me enorm geholpen, mijn functie werkt nu helemaal naar behoren, hartstikke bedankt.

PHP:

<?php
function getRights ( $iRights ){
    $iArrayPointer = 0;

    for ( $iBinaryNumber = 1; $iBinaryNumber <= 8192; $iBinaryNumber = $iBinaryNumber*2 ){

        if ( $iRights & $iBinaryNumber ){
            $aRights[$iArrayPointer] = $iBinaryNumber;
            $iArrayPointer++;
        }

    }

    return $aRights;

}

$iUserRights = 611;

$aRights = getRights($iUserRights);

if ( in_array( 512, $aRights, true ) === true ){
    echo "Je hebt genoeg rechten om Onderzoeksvragen te lezen.";
} else {
    echo "Je hebt niet genoeg rechten om Onderzoeksvragen te lezen.";
}
?>

Waarom definiëer je niet elke recht zoals je hierboven hebt gedaan maar dan met 3 tabels

1 Users
2 Rights (canViewUsers b.v.) met een 1 of een 0.
3 LinkedRights (UserID 3 heeft rechtenset 3)

En dan een class maken die controleerd welke gebruiker het is, welke rechtenset hij heeft, en welke rechtenset op 1 moet staan om deze pagina te bezoeken.

Nou, dan krijg ik dus alsnog een rommelige database, en dat is precies wat ik wil vermijden.

Maar allemaal bedankt voor jullie reacties, gelukkig is het nu voor elkaar, en misschien dat andere mensen hier nog wat aan hebben.

[MueR]

Zoals ik het nu lees, zet je deze rechten dus als velden in de users tabel? Dan ga je een beetje het idee van relationele databases voorbij. Je kan, mijn inziens, beter twee tabellen extra gebruiken. Dat maakt je database niet rommelig, maar juist goed ontworpen.

[Deviruchi]

MueR schreef op dinsdag 13 maart 2007 @ 14:35:
Zoals ik het nu lees, zet je deze rechten dus als velden in de users tabel? Dan ga je een beetje het idee van relationele databases voorbij. Je kan, mijn inziens, beter twee tabellen extra gebruiken. Dat maakt je database niet rommelig, maar juist goed ontworpen.

Nou nee, ik heb het veld 'rights' in de tabel 'users', en die heeft dus de waarde van de rechten. Bijvoorbeeld 612.

[P.O. Box]

volgens mij beperk je zo in de toekomst wel je mogelijkheden...
heb je nu niet maar 32 mogelijke verschillende rechten? (2 tot de macht 32 = max int in PHP toch?) daar zit je nu nog niet aan... maar ooit misschien wel..

[Deviruchi]

Daar heb je inderdaad gelijk in, maar dit is voor een project dat eigenlijk niet meer uitgebreid wordt, en aangezien alles in classes wordt geschreven, is het later altijd nog mogelijk om over te stappen, maar dit zal echt zeker de komende 20 jaar niet hoeven.

[KabouterSuper]

Ter info: Een binair gebaseerde opzet voor een rechtensysteem is handig omdat je hierarchische rechten kunt uitdelen.

Als je bijvoorbeeld twee rechten hebt, nl view en edit, dan is het logisch dat een edit-user ook view rechten heeft.

Dit doe je binair door view rol 1 te geven (=01 binair) en edit rol 3 (=11 binair). Als je nu wilt weten of een user content mag viewen, vraag je gewoon aan de database wat het eerste getal is (vanaf rechts gezien). Dit is een extreem goedkope operatie. Op soortgelijke wijze kan je aan de database vragen of een user edit-rechten heeft door naar het tweede getal van rechts te kijken.

Overigens kan mysql unsigned integers aan, zodat je 64 verschillende rechten kunt gebruiken, met 2^64 verschillende rollen. Dit geldt natuurlijk alleen als je de intelligentie in mysql houdt.

Edit: overigens gebruikt de TS zijn rechtensysteem niet op bovenstaande wijze.

[ Voor 11% gewijzigd door KabouterSuper op 13-03-2007 15:17 ]

[RobIII]

Deviruchi schreef op dinsdag 13 maart 2007 @ 14:05:
True, ware het niet dat de gebruikers leerlingen van de school zijn, en die daar nou eenmaal niet zo veel mee te maken hebben.

Nou dan

Deviruchi schreef op dinsdag 13 maart 2007 @ 14:05:
Nou, dan krijg ik dus alsnog een rommelige database, en dat is precies wat ik wil vermijden.

Sinds wanneer is een genormaliseerde DB met (poehee) 3 tabellen ofzo "rommelig"? Je 'binaire systeem', dat is pas rommelig. Nu moet je verrekkes uitkijken dat je ieder bitje goed documenteerd e.d., want over een paar maanden kom je er echt geen wijs meer uit...

[KabouterSuper]

Als je niet precies snapt waarom je een binair rechtensysteem gebruikt, zou ik je aanraden er gelijk mee te stoppen. Drie simpele tabellen doen functioneel hetzelfde, maar is beter onderhoudbaar. Ik geef RobIII helemaal gelijk dat je waarschijnljk binnen de kortste keren een blackbox geprogrammeerd hebt die niemand meer snapt.

[HuHu]

RobIII schreef op dinsdag 13 maart 2007 @ 16:18:
[...]

Nou dan


[...]

Sinds wanneer is een genormaliseerde DB met (poehee) 3 tabellen ofzo "rommelig"? Je 'binaire systeem', dat is pas rommelig. Nu moet je verrekkes uitkijken dat je ieder bitje goed documenteerd e.d., want over een paar maanden kom je er echt geen wijs meer uit...

Waar zie jij staan dat zijn hele database maar uit 3 (ofzo) tabellen bestaat ?

[Y0ur1]

HuHu schreef op dinsdag 13 maart 2007 @ 20:10:
[...]

Waar zie jij staan dat zijn hele database maar uit 3 (ofzo) tabellen bestaat ?

Deviruchi noemt de databaseoplossing rommelig, wat onzin is, RobIII doelt op de 3 tabellen die nodig zijn voor de oplossing met een database.

Even spieken bij de buren is vaak helemaal geen slecht idee:

Database structure

Role table

* role id
* role name
* role description
* role type (global / local)
* created by (user id)

Rights table

* right id
* right name
* right description

Location table

* location id
* location (this is a string, e.g. platform|courses|course,7019|tool,forum)

Relationship users / roles

We need a table to store which users have which roles. This is a many to many relationship. Since local roles are connected to a location, we need to store that as well.

* user id
* role id
* location id

Relationship role/right/location

There are many roles, many rights, and many locations. For every combination of role - right - location, there is also the value of it: is the right set or not (true or false) for that role in that location?

* role id
* right id
* location id'
* value (true/false) (1/0)

van: http://www.dokeos.com/wiki/index.php/User_roles_and_rights (onderaan)

Is simpel maar effectief, en dan zou ik denk ik de rechten 1 keer inladen bij het inloggen zodat je niet iedere keer requests naar de database krijgt over rechten bij iedere pagina.

[ Voor 65% gewijzigd door Y0ur1 op 13-03-2007 21:54 ]

[wackmaniac]

Heerlijk zo'n topic. Ben met de planning bezig van een nieuwe community site en ik was me net aan het orienteren op dit punt.

Denk dat ik de laatste "3-tabellen-oplossing" maar een kans ga geven.

[Deviruchi]

Oké, ik ben begonnen om het toch met 3 tabellen te doen, alles goed en wel, maar hoe los ik dit precies op met de query, ik heb met enig gepruts de volgende query gekregen:

PHP:

<?php

// hier wordt de gebruiker ingelogd etc, de userid wordt uit de database gehaald.
$iUserID = $_SESSION['UserID'];

$sGetRightsQuery = $oUser->doQuery( "SELECT r.rights_set_name, r.view_user, r.create_user, r.modify_user, r.delete_user,
r.view_performance, r.create_performance, r.modify_performance, r.delete_performance, r.join_performance,
r.view_research_question, r.create_research_question, r.modify_research_question, r.delete_research_question, r.join_research_question,
u.username
FROM rights AS r, link_user_rights AS lur, users AS u
WHERE lur.user_id = '$iUserID'
AND lur.rights_id = r.rights_id" );

// hier wordt de data geshowed aan de user.
?>

Werkt goed, zolang er 1 user gelinkt is aan een rechtenset. Met meerdere gebruikers selecteerd hij ze allemaal. Dit is dus niet wat ik wil hebben, ik wil de rechtenset hebben van 1 persoon, de persoon die dus op dat moment ingelogd is.

Ik heb zelf nog nooit gewerkt met JOINs, dus vandaar dat ik dit niet zelf zo 1, 2, 3 op kan lossen, ik hoop dat jullie me hier wat verder mee op weg kunnen / willen helpen.

[ Voor 7% gewijzigd door Deviruchi op 15-03-2007 11:36 ]

[Matthis]

waarom niet gebruik maken van bestaande tools ipv (weeral) het wiel opnieuw uit te vinden?
PHPGACL doet exact wat je nodig hebt, is flexibel, uitbreidbaar en heeft z'n sporen reeds verdiend: http://phpgacl.sourceforge.net/ .

[P.O. Box]

je bent vergeten de user tabel aan de link_user_rights tabel te koppelen...

ik zelf zou het sowieso met joins doen, maar dat is niet perse noodzakelijk

[Grijze Vos]

Ik snap het gezeur in deze thread niet zo. Of je nou een koppeltabel gebruikt om elke user/usergroup aan rechten te hangen, of dat je bitmasking gebruikt.

Bij mijn eigen systeem heb ik verschillende usergroups, die beslaan de verschillende bits. Een user kan in verschillende groups zitten, en elke actie die gedaan kan worden in het systeem kan door sommige groups worden uitgevoerd. Een user bitmasken met een actie en je weet of iets uitgevoerd mag worden.

Dit is niets meer of minder dan een ontwerpbeslissing, en als je claimt dat een systeem 'ononderhoudbaar' wordt van deze keuze, dan is je systeem in de eerste plaats al brak. Want als je je rechtensysteem moet onderhouden, dan gebeurt dat in de component die je rechtensysteem afhandelt, en in een zinnig systeem is dat gewoon fatsoenlijk loosely coupled van de rest van je architectuur.

Ikzelf vind dit systeem wel fijn werken en heb ervoor gekozen omdat het m.i. performanter is dan de andere oplossing. (Dat vermoed ik, ik heb het verder niet gebenchmarked.) Maar goed, 1 tabel erbij en 6 regels code aanpassen en het is al op de andere manier geimplementeerd. Dat is onderhoudbaarheid.

Matthis schreef op donderdag 15 maart 2007 @ 11:59:
waarom niet gebruik maken van bestaande tools ipv (weeral) het wiel opnieuw uit te vinden?
PHPGACL doet exact wat je nodig hebt, is flexibel, uitbreidbaar en heeft z'n sporen reeds verdiend: http://phpgacl.sourceforge.net/ .

Twee redenen bedenk ik me zo snel al.
1.) Voor iets dat misschien 150 regels code hoeft te kosten zou ik geen bloatware met > 20K regels willen gebruiken.
2.) Over iets van zulk integraal belang code ik liever mijn eigen software, zodat ik 100% controle erover heb, en niet van anderen afhankelijk ben voor mijn security.

[edit]
3.) En dan is er nog zoiets als het 'leer' aspect natuurlijk.

[ Voor 26% gewijzigd door Grijze Vos op 15-03-2007 12:24 ]

[KabouterSuper]

Grijze Vos schreef op donderdag 15 maart 2007 @ 12:17:
Dit is niets meer of minder dan een ontwerpbeslissing, en als je claimt dat een systeem 'ononderhoudbaar' wordt van deze keuze, dan is je systeem in de eerste plaats al brak.

Ik maak me zorgen dat de programmeur 'brak' is, niet dat het systeem brak is. Een goed systeem wat niemand snapt, is een black box, hoe je het ook wendt of keert. Een goed werkende GUI vermindert het risico (zoals je terecht opmerkt), maar het is prettig als er iemand is die alle ins en outs van de low-level architectuur snapt.

[Grijze Vos]

KabouterSuper schreef op donderdag 15 maart 2007 @ 12:28:
[...]

Ik maak me zorgen dat de programmeur 'brak' is, niet dat het systeem brak is. Een goed systeem wat niemand snapt, is een black box, hoe je het ook wendt of keert. Een goed werkende GUI vermindert het risico (zoals je terecht opmerkt), maar het is prettig als er iemand is die alle ins en outs van de low-level architectuur snapt.

Een brakke programmeur produceert brakke systemen.
En een beetje documentatie indien nodig is natuurlijk nooit weg. Los van het feit dat iemand met een blik op de code ook wel ziet dat je bitmasking hebt gebruikt of dat je met een koppeltabel werkt, of welke andere enge oplossingen mensen al niet verzonnen hebben.

Maar goed, mijn punt was dat zowel bitmasking als de koppeltabel-methode (bij gebrek aan betere benaming) implementaties zijn voor RBAC, en dat het slechts een ontwerpbeslissing is hoe je dat wilt implementeren.

Oh, een andere (minder belangrijke) reden waarom ik koos voor dit systeem, als je voor en koppeltabel gaat dan moet je weer records kunnen deleten uit de DB, en ik ben tegen het geven van dat soort rechten aan de webserver-database-user.

[Deviruchi]

Edwardvb schreef op donderdag 15 maart 2007 @ 11:59:
je bent vergeten de user tabel aan de link_user_rights tabel te koppelen...

En hoe is dat precies te doen dan, ik heb al wat geprobeerd met Foreign key, maar op de een of andere manier wil dat toch niet lukken .

@ de rest, ik ga geen software van anderen hiervoor gebruiken, omdat dit voor mijn stage is, en zoals Grijze Vos al zei, is voor mij het leer-aspect dus het belangrijkst.

[edit]
Terwijl ik dit typte, dacht ik er meteen over na, en na een 'AND lur.user_id = u.user_id', is het 'probleem' verholpen, bedankt allemaal.

[ Voor 12% gewijzigd door Deviruchi op 15-03-2007 12:54 ]

[Verwijderd]

Grijze Vos schreef op donderdag 15 maart 2007 @ 12:40:
[...]

Oh, een andere (minder belangrijke) reden waarom ik koos voor dit systeem, als je voor en koppeltabel gaat dan moet je weer records kunnen deleten uit de DB, en ik ben tegen het geven van dat soort rechten aan de webserver-database-user.

Je kan volgens mij volstaan met update en een extra kolom, iets als 'verwijderd (true | false)'.

[Grijze Vos]

Verwijderd schreef op donderdag 15 maart 2007 @ 12:52:
[...]

Je kan volgens mij volstaan met update en een extra kolom, iets als 'verwijderd (true | false)'.

En dat is elegant wil je zeggen? Kijk, bij een regulier record (zeg een message in een forum) is dat niet meer dan normaal. Maar bij koppeltabel-records vind ik het vrij ranzig om dat zo toe te passen. Moet je dan weer van die fijne update/insert queries bouwen etc.

(Maar goed, dit geeft maar weer aan dat het duidelijk een kwestie van smaak is, en niet van right/wrong.)

[ Voor 10% gewijzigd door Grijze Vos op 15-03-2007 12:57 ]

[Verwijderd]

Ha, hier ben ik mij dus ook op aan het orienteren! Ik heb al verschillende manieren gezien waarop het gedaan wordt, eerst begon ik met bitwise, zoals de TS dat gedaan had, daarna gerelateerde tabellen, zoals voorgesteld wordt. En nu ben ik al een tijdje bezig met het proberen te snappen van het volgende systeem. Waarbij voor standaard functies inderdaad simpele tekst bitwise voor gebruikt wordt, maar voor de rest tabellen. Ik vond het in ieder geval erg leerzaam om te lezen! En ik zou het ook iedereen aanraden, al was het alleen maar voor sommige ideeen in de tekst.

_{Er is trouwens ook een deel 2}

[Janoz]

Het enige voordeel van een binair rechten system is dat het controleren van rechten erg efficient gaat (1x een bitwise and. Snap niet wat voor gruwel implementaties er door dit topic staan waarbij strings en arrays worden gebruikt). Het grote nadeel van een binair rechten systeem is dat je een beperking hebt op het aantal rechten. Je kunt immers maar een beperkt aantal bits in een int stoppen. Bij PHP moet je daarnaast extra opletten dathij er niet ineens een float van maakt waardoor een deel van je rechten ineens wegvalt.

Voor de continuiteit en onderhoudbaarheid is een koppeltabel veel handiger. Het onderhoud bestaat nu eenmaal niet uit het alleen aanpassen van de code. Doordat je minder in je mogelijkheden bent beperkt kun je een veel hogere resolutie in rechten halen. Door hier een rol laag tussen te zetten (waarbij je meerdere rechten aan een rol hangt en meerdere rollen aan een gebruiker) kun je ook de complete toegankelijkheid van je applicatie aanpassen zonder dat je een letter code aan hoeft te passen.

[Grijze Vos]

Janoz, met het door mij gerepresenteerde idee heb je een oneindig aantal rechten, maar een beperkt aantal usergroups. Hoeveel websystemen (we praten hier immers over php) hebben meer dan 32 (danwel 64) verschillende usergroups?

Zoals ik al zei, mijn implementatie is gewoon RBAC met een bitwise implementatie, de enige restrictie zit hem in het aantal usergroups, wat m.i. geen probleem oplevert.

[ Voor 27% gewijzigd door Grijze Vos op 15-03-2007 13:34 ]

[Snake]

Grijze Vos schreef op donderdag 15 maart 2007 @ 13:34:
Janoz, met het door mij gerepresenteerde idee heb je een oneindig aantal rechten, maar een beperkt aantal usergroups. Hoeveel websystemen (we praten hier immers over php) hebben meer dan 32 (danwel 64) verschillende usergroups?

Zoals ik al zei, mijn implementatie is gewoon RBAC met een bitwise implementatie, de enige restrictie zit hem in het aantal usergroups, wat m.i. geen probleem oplevert.

Het gaat niet over 32/64 verschillende usergroups, maar om 64 verschillende rechten, waarbij bepaalde groepen bepaalde rechten hebben en anderen niet.

[Janoz]

Grijze Vos schreef op donderdag 15 maart 2007 @ 13:34:
Hoeveel websystemen (we praten hier immers over php) hebben meer dan 32 (danwel 64) verschillende usergroups?

Zover hoef je daarvoor niet te kijken. Bij tweakers is het aantal mogelijke verschillende setjes rechten niet meer te vangen in 64 bitjes.

[Verwijderd]

Grijze Vos schreef op donderdag 15 maart 2007 @ 12:54:
[...]

En dat is elegant wil je zeggen? Kijk, bij een regulier record (zeg een message in een forum) is dat niet meer dan normaal. Maar bij koppeltabel-records vind ik het vrij ranzig om dat zo toe te passen. Moet je dan weer van die fijne update/insert queries bouwen etc.

(Maar goed, dit geeft maar weer aan dat het duidelijk een kwestie van smaak is, en niet van right/wrong.)

Idd kwestie van smaak, je kan je database-user ook delete-rechten geven

Ben zelf atm ook (weer) bezig met een wat complexer rechtensysteem voor 't intranet hier. Ben nog aan het bedenken wat de best passende oplossing is. Kan hier iig weer even genoeg inspiratie opdoen.

[Grijze Vos]

Janoz schreef op donderdag 15 maart 2007 @ 14:03:
[...]

Zover hoef je daarvoor niet te kijken. Bij tweakers is het aantal mogelijke verschillende setjes rechten niet meer te vangen in 64 bitjes.

Scroll up, lees waarin ik vertelde over het systeem dat ik geimplementeerd heb. Lees dat je daar een oneindig aantal rechten kunt hebben, maar 'slechts' 64 usergroups. Kom vervolgens tot de conclusie dat zelfs tweakers geen 64 usergroups heeft...

[Janoz]

Ik heb op mijn overzichts pagina alleen al 56 verschillende fora staan, en dan heb ik ze nog niet eens allemaal. Elk van deze fora heeft lees of post of moderatie rechten. Ook al zou je hier groepen op definieren, dan zou je al behoorlijk snel over de 64 heen gaan zitten aangezien er heel wat verchillende combinaties mogelijk zijn. Dan heb ik vervolgens de frontpage nog niet eens meegeteld.

[wackmaniac]

Maar je definieert niet voor elk forum een groep. Je definieert een aantal groepen (vb admin, mod, user) en als doel heb je elk forum. Voor ieder forum een apart groep aanmaken is gekkenwerk.

[Superdeboer]

wackmaniac schreef op donderdag 15 maart 2007 @ 21:45:
Maar je definieert niet voor elk forum een groep. Je definieert een aantal groepen (vb admin, mod, user) en als doel heb je elk forum. Voor ieder forum een apart groep aanmaken is gekkenwerk.

offtopic:
De rechtenstructuur van GoT is veel complexer dan je je kunt voorstellen totdat je dat in de admin hebt bekeken. Die 64 usergroups zitten misschien nog niet eens zo heel ver van het echte aantal af.

Wellicht is dit nog wel een illustratief topic waar TS wat ideeen uit kan halen: \[php/[my]sql] inherited rechtensysteem

[Janoz]

wackmaniac schreef op donderdag 15 maart 2007 @ 21:45:
Maar je definieert niet voor elk forum een groep. Je definieert een aantal groepen (vb admin, mod, user) en als doel heb je elk forum. Voor ieder forum een apart groep aanmaken is gekkenwerk.

Dan ben je dus weer die 1:N relatie aan het introduceren die je er juist uit wilde hebben. Je hebt de (performance) winst van een bitmask dan weer helemaal teniet gedaan.

[We Are Borg]

Superdeboer schreef op donderdag 15 maart 2007 @ 22:43:
[...]

offtopic:
De rechtenstructuur van GoT is veel complexer dan je je kunt voorstellen totdat je dat in de admin hebt bekeken. Die 64 usergroups zitten misschien nog niet eens zo heel ver van het echte aantal af.

Wellicht is dit nog wel een illustratief topic waar TS wat ideeen uit kan halen: \[php/[my]sql] inherited rechtensysteem

Wilde dit linkje al geven maar moest even doorscrollen om te checken of iemand anders het al had gedaan.

Vraag me af of deze methode nog steeds gebruikt wordt met react en nog steeds ook wenselijk is. Heb er eens met hobbymatige intresse naar gekeken, maar begrijp chem's uitwerking nog niet helemaal

[Deviruchi]

Pfoe, leuk, ik heb nu die functie dus werkend, maar nu wil ik ook meerdere rechten in een keer kunnen checken, in plaats van een paar keer de functie aanroepen, maar dit wil niet helemaal lukken

PHP:

<?php

// hier staat code

$aNeededRights = explode( ',', $sNeededRights );
            $iAmountOfRightsToBeChecked = count( $aNeededRights );
            $aSearchArray = array_flip( $aUserRights );

            // Check if there are more than 1 rights to be checked
            if ( $iAmountOfRightsToBeChecked > 1 ){

                // Search the array for the given rights.
                $iSearchResult = array_search( $aNeededRights[$iTempPointer], $aSearchArray );

                // Keep a temporary pointer to check where you are in the array.
                for ( $iTempPointer = 0; $iTempPointer<=$iAmountOfRightsToBeChecked; $iTempPointer++ ){

                    // If the rights that are needed are in the result, return true
                    // otherwise return false.
                    if ( $iSearchResult != false && $aSearchArray[$iSearchResult] == '1' ){
                        $this->bUserHasRights = true;
                    } else{
                        return false;
                    }
                }

                // If user has all rights, return true.
                if ( $this->bUserHasRights === true ){
                    return true;
                }

            } else {
                if ( $aUserRights[$sNeededRights] == '1' ){
                    return true;
                } else{
                    return false;
                }
            }
// hier staat nog meer code
?>

Dit werkt niet, maar ik heb al meerdere mogelijkheden geprobeerd, ik zie de bomen door het bos echt niet meer . De ene array die je uit de database ophaald is opgebouwd als [view_user] => '1' of '0', terwijl de andere array ( de array die je opgeeft om te checken ) is opgebouwd als [0] => 'view_user', hoe kan ik nou vanuit deze laatste array kijken, of de waarde van de laatste array, bestaat als key in de andere array, en de waarde van die key 1 is?

Dus ter verduidelijking:
2 arrays:
array 1: [view_user] => '1'
array 2: [0] => 'view_user'

Nu wil ik dus kijken, of de waarde van array 2 ( view_user ), bestaat als key in array 1. In dit geval bestaat die dus. Maar dan wil ik ook nog kijken of de waarde van die key in array 1 ook op '1' staat. Dan moet er true gereturned worden, en anders false. Ik hoop dat het zo iets duidelijker is ;o.

[ Voor 21% gewijzigd door Deviruchi op 16-03-2007 10:48 ]

[Verwijderd]

Ik heb niet het hele topic gelezen maar toch een mening

Bitmask gebaseerde rechten systemen zijn simpelweg een no-go. Het is immers niet zelf-documenterend. Een nummer in een of andere hippe db zegt mij namelijk vrij weinig. 1-n, of liever nog n-n, oplossingen zijn simpelweg duidelijk. Ze laten ruimte voor documentatie velden etc.

Performance is wat mij betreft echt een complete non-issue aangezien we het hier over (gebruiker) sessie data hebben. De data zou dus bij het aanmelden van de gebruiker in het geheugen moeten worden geladen. Die eenmalige 'trage' inlaad actie is dus compleet te verwaarlozen.

[P.O. Box]

Deviruchi schreef op vrijdag 16 maart 2007 @ 10:23:
Dus ter verduidelijking:
2 arrays:
array 1: [view_user] => '1'
array 2: [0] => 'view_user'

werkt dit niet dan?

PHP:

if ($array_1[$array_2[0]] == 1) {
}

en verder

PHP:

$validuser = 0;
for ($i=0; $i < count($array_2); $i++) {
    $validuser += $array_1[$array_2[$i]];
}

if ($validuser > 0) {
    // ga je gang, je hebt rechten
} else {
    // booeeeh...
}

[Deviruchi]

Edwardvb schreef op vrijdag 16 maart 2007 @ 11:33:
[...]


werkt dit niet dan?

PHP:

if ($array_1[$array_2[0]] == 1) {
}

en verder

PHP:

$validuser = 0;
for ($i=0; $i < count($array_2); $i++) {
    $validuser += $array_1[$array_2[$i]];
}

if ($validuser > 0) {
    // ga je gang, je hebt rechten
} else {
    // booeeeh...
}

OMG, mijn held! Het werkt! Hoezee!

Maar ligt het nou aan mij, of ben ik nou echt zo dom dat ik hier na 2 uur kloten nog niet uit kom? >_<!

Iig, dit is nu de werkende code:

PHP:

<?php

// Getting the info from the database.

            $aNeededRights = explode( ',', $sNeededRights );
            $iAmountOfRightsToBeChecked = count( $aNeededRights );

            // Check if there are more than 1 rights to be checked
            if ( $iAmountOfRightsToBeChecked > 1 ){

                // Keep a temporary pointer to check where you are in the array.
                for ( $iTempPointer = 0; $iTempPointer<$iAmountOfRightsToBeChecked; $iTempPointer++ ){

                    // Check if the rights from the database are in the given rights.
                    if ( $aUserRights[$aNeededRights[$iTempPointer]] == 1){
                        $iTotalRights++;
                    }
                }

                // If the total of the rights is the same as the amount of rights
                // that needed to be checked, then all rights are there.
                if ( $iTotalRights == $iAmountOfRightsToBeChecked ){
                    return true;
                } else {
                    return false;
                }


            } else {
                if ( $aUserRights[$sNeededRights] == '1' ){
                    return true;
                } else{
                    return false;
                }
            }

// Nog wat meer checks in deze functie, niet van belang

?>

[Verwijderd]

het grote voordeel van bitmasking is dat je per-byte 8 boolean true/false waardes kunt opslaan. dus met slechts 4 bytes kun je kijken of een gebruiker toegang heeft tot 128 verschillende elementen. daarnaast zijn bitwise opperatie's erg snel en daarmee zeer efficient zowel in opslag als in verwerking.

het is waar dat bitwise opperatie's niet zelf-documenteerend zijn en daarom wat on overzichtelijk maar ook een database-oplossing hoeft niet meteen duidelijk te zijn. beide verergen een duidelijke documentatie waar welke rechten voor staan en wat het aan/uit zetten van die rechten voor gevolgen heeft.

de meest duidelijke een overzichtelijke manier zou zijn om gewoon 1 tabel te maken met voor elke soort recht wat er maar kan worden verleend een 1 colom. deze van het type boolean maken en dan voor elke user 1 rij. hierdoor kun je met bijvoorbeeld phpMyAdmin de rechten zelfs erg makkelijke beheeren en aanpassen. door goede colom-namen te kiezen wordt ook meteen duidelijk waar elke colom voorstaat.

het grote nadeel van de deze aanpak is natuurlijk dat de tabel trager en logger wordt, iets wat op een veel bezochte site als tweakers tot een aardige perfomancehit kan worden gemaakt. het desing is daarnaast vere van optimaal maar toch erg simplistiche en makkelijk beheersbaar.

maar aan het einde van de dag, is het eigenlijk nog altijd het zelfde. een collectie van boolean false/true waardes die zeggen of een gebruiker nou wel of niet mag editten en of je dat nou in 1 byte of in 1 kilobyte opslaat maakt eigenlijk niet uit. zonder goede documentatie is elk systeem een blackbox.

[Verwijderd]

Verwijderd schreef op vrijdag 16 maart 2007 @ 12:26:
het is waar dat bitwise opperatie's niet zelf-documenteerend zijn en daarom wat on overzichtelijk maar ook een database-oplossing hoeft niet meteen duidelijk te zijn. beide verergen een duidelijke documentatie waar welke rechten voor staan en wat het aan/uit zetten van die rechten voor gevolgen heeft.

Onzinnig argument. bitwise is gewoon niet zelfdocumenterend, als in: het kan gewoon niet. een n-n relatie doet dat meteen wel, als in: het is meteen te traceren.

Verwijderd schreef op vrijdag 16 maart 2007 @ 12:26:
de meest duidelijke een overzichtelijke manier zou zijn om gewoon 1 tabel te maken met voor elke soort recht wat er maar kan worden verleend een 1 colom. deze van het type boolean maken en dan voor elke user 1 rij. hierdoor kun je met bijvoorbeeld phpMyAdmin de rechten zelfs erg makkelijke beheeren en aanpassen. door goede colom-namen te kiezen wordt ook meteen duidelijk waar elke colom voorstaat.

n-n dus.

Let er op dat een recht niet per definitie van het type boolean hoeft te zijn. Denk bijvoorbeeld aan 'max_concurrent_downloads'

Verwijderd schreef op vrijdag 16 maart 2007 @ 12:26:
het grote nadeel van de deze aanpak is natuurlijk dat de tabel trager en logger wordt, iets wat op een veel bezochte site als tweakers tot een aardige perfomancehit kan worden gemaakt. het desing is daarnaast vere van optimaal maar toch erg simplistiche en makkelijk beheersbaar.

Echt, daar merk je niets significants van. Performance is de grootste drogreden om smerige oplossingen zoals bitwise rechten te rechtvaardigen.

[Verwijderd]

Verwijderd schreef op vrijdag 16 maart 2007 @ 13:49:
[...]

Onzinnig argument. bitwise is gewoon niet zelfdocumenterend, als in: het kan gewoon niet. een n-n relatie doet dat meteen wel, als in: het is meteen te traceren.


[...]
n-n dus.

Let er op dat een recht niet per definitie van het type boolean hoeft te zijn. Denk bijvoorbeeld aan 'max_concurrent_downloads'


[...]

Echt, daar merk je niets significants van. Performance is de grootste drogreden om smerige oplossingen zoals bitwise rechten te rechtvaardigen.

ik denk dat je wel anders piept als je voor elk bestand op je hd een database zou gebruiken om de rechten te controleren. het is waar dat een website lang niet in de buurt komt om je druk te maken over de performance maar dat maakt bitwise niet een smerige oplossing. het zelfs een hele schone oplossing maar zoals elke oplossing vereist het gewoon goede documentatie. niks meer niks minder.

geen enkel rechten-systeem is zelf-documenteerend. en beveiligings gaten onstaan maar al te vaak omdat rechten niet sluitend zijn of elkaar tegenspreken. elk rechten systeem is gewoon een systeem waarin middels simpele ja/nee vragen duidelijk wordt wat een user wel en niet mag. en of dat dan middels een simpele sql tabel of via een bitwise wordt gedaan staat daar los van.

bij beveiliging waar een rechten systeem een onderdeel van is gaat het alleerst om de structuur van de beveiliging en dan pas om de implementatie. ook een limit-syteem zoals jij aangeeft met "max_downloads" bijvoorbeeld vereist allereerst duidelijkheid en overzicht. als dat er al niet is dan maakt de implementatie al niet meer uit. zorg voor goede documentatie en maak dingen niet ingewikkelder dan nodig is en vooral zorg dat je beveiliging los staat en onafhankelijk van de rest functioneert.

[Verwijderd]

Het moet maar even zin voor zin, want het is zo'n lap onzin...

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
ik denk dat je wel anders piept als je voor elk bestand op je hd een database zou gebruiken om de rechten te controleren.

We hebben het nog steeds over websites, dat is de context van dit topic. Dus niet breder trekken dan nodig is.

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
het is waar dat een website lang niet in de buurt komt om je druk te maken over de performance maar dat maakt bitwise niet een smerige oplossing.

Deze zin klopt van geen kant: Je probeert een niet bestaande relatie tussen snelheid netheid aan te tonen oid.

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
het zelfs een hele schone oplossing maar zoals elke oplossing vereist het gewoon goede documentatie. niks meer niks minder. geen enkel rechten-systeem is zelf-documenteerend.

Weer onzin: niet elke oplossing vereist documentatie. Een rol die "allow_post_on_frontpage" geeft toch heel wat info.

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
en beveiligings gaten onstaan maar al te vaak omdat rechten niet sluitend zijn of elkaar tegenspreken.

In de top tien van beveiligings gaten staat deze inderdaad op nummer elf.

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
elk rechten systeem is gewoon een systeem waarin middels simpele ja/nee vragen duidelijk wordt wat een user wel en niet mag.

Nee dus.

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
en of dat dan middels een simpele sql tabel of via een bitwise wordt gedaan staat daar los van.

Wederom nee dus. Ik kan geen omvang kwijt in bitwise rechten.

Verwijderd schreef op vrijdag 16 maart 2007 @ 14:31:
bij beveiliging waar een rechten systeem een onderdeel van is gaat het alleerst om de structuur van de beveiliging en dan pas om de implementatie. ook een limit-syteem zoals jij aangeeft met "max_downloads" bijvoorbeeld vereist allereerst duidelijkheid en overzicht. als dat er al niet is dan maakt de implementatie al niet meer uit. zorg voor goede documentatie en maak dingen niet ingewikkelder dan nodig is en vooral zorg dat je beveiliging los staat en onafhankelijk van de rest functioneert.

En nog wat gezwam in de ruimte. Je zegt hier feitelijk: "Bezint eer ge Begint."

Mijn collega's worden simpelweg een stuk blijer als ze gewoon zonder een pak papier werk mijn stuk code kunnen lezen.

[Matthis]

[b][message=27672647,noline]
Twee redenen bedenk ik me zo snel al.
1.) Voor iets dat misschien 150 regels code hoeft te kosten zou ik geen bloatware met > 20K regels willen gebruiken.
2.) Over iets van zulk integraal belang code ik liever mijn eigen software, zodat ik 100% controle erover heb, en niet van anderen afhankelijk ben voor mijn security.

[edit]
3.) En dan is er nog zoiets als het 'leer' aspect natuurlijk.

1. Je hebt duidelijk geen benul waarover je spreekt: phpDoc comments inclusief is de class welgeteld 625 regels lang...
2. Ik heb meer vertrouwen in iets dat al z'n diensten bewezen heeft en wijdverbreid is, dan dat ik zelf snel iets ineen steek waarvan ik denk dat het goed is.
3. Als je eigen systeem toch zo goed is, heb je duidelijk toch niets meer te leren...

Ik focus liever op applicaties ontwikkelen ipv weeral wielen uitvinden.

[Grijze Vos]

Matthis schreef op vrijdag 16 maart 2007 @ 20:44:
[...]


1. Je hebt duidelijk geen benul waarover je spreekt: phpDoc comments inclusief is de class welgeteld 625 regels lang...

En de andere 4.5MB die in het zipje zitten zijn er voor de gein bijgegooid? -Bloated-

2. Ik heb meer vertrouwen in iets dat al z'n diensten bewezen heeft en wijdverbreid is, dan dat ik zelf snel iets ineen steek waarvan ik denk dat het goed is.

Mja goed, jij hebt kennelijk makkelijk vertrouwen in een open source product, ik niet. Niet als het om security aspecten gaat.

3. Als je eigen systeem toch zo goed is, heb je duidelijk toch niets meer te leren...

Nonargument, denk zelf nog maar eens na waarom.