benutzerverwaltung - konzept

[HoRnominatoR]

hi,

momentan mache ich mir sorgen um den strukturellen aufbau, insbesondere die datenspeicherung, einer benutzerverwaltung, genuer gesagt um die rechte einzelner gruppen.

strukturell gesehen, wuerde ich zuerst die gruppen festlegen, natuerlich erweiterbar

PHP-Code:

$array = array
(
    'admin' => array
    (
    ),
    'user' => array
    (
    ),
    'guest' => array
    (
    )
) 


dazu muesste man jetz wissen, wie diese in relation zu verschiedenen, erweiterbaren bereichen stehen (news, events, article), die jeweils einem objekt zugeordnet sind.

PHP-Code:

$array = array
(
    'admin' => array
    (
        'news' => array(
        ),
        'events' => array(
        ),
        'article' => array(
        )
    ),
    'user' => array
    (
        'news' => array(
        ),
        'events' => array(
        ),
        'article' => array(
        )
    ),
    'guest' => array
    (
        'news' => array(
        ),
        'events' => array(
        ),
        'article' => array(
        )
    )
) 


dort muesste man jetzt noch die vier aktionen (select, insert, update, delete) unterbringen, die die verschiedenen gruppen ausfuehren duerfen, bezogen natuerlich auf die einzelnen spalten der tabelle, denn es soll ja nicht jeder an IDs, nicknamen oder passwoertern rumspielen koennen (nur bei 'user' ausgefuellt)

PHP-Code:

$array = array
(
    'admin' => array
    (
        'news' => array
        (
            'select' => array
            (
                'id',
                'user',
                'topic',
                'message'
            ),
            'insert' => array
            (
            ),
            'update' => array
            (
            ),
            'delete' => array
            (
            )
        ),
        'events' => array
        (
        ),
        'article' => array
        (
        )
    ),
    'user' => array
    (
        'news' => array
        (
            'select' => array
            (
                'user',
                'topic',
                'message',
                'date',
                'time'
            ),
            'insert' => array
            (
                'topic',
                'message'
            ),
            'update' => array
            (
                'topic',
                'message'
            ),
            'delete' => array
            (
            )
        ),
        'events' => array
        (
        ),
        'article' => array
        (
        )
    ),
    'guest' => array
    (
        'news' => array
        (
        ),
        'events' => array
        (
        ),
        'article' => array
        (
        )
    )
) 


so schoen, so kompliziert und mit sicherheit unangenehm wartbar, da man darauf achten muss, dass gruppen und objekte beim neu erstellen immer einander zugeordnet sind. zudem braeuchte man noch abhaengigkeiten, da ja nicht jeder benutzer alle profile editieren darf, sondern nur jene, die seiner ID zugeordnet sind.

geht das nicht einfacher? schon die darstellung der kompletten rechteverwaltung duerfte unuebersichtlich sein, geschweige denn, wie man die struktur in eine relationelle datenbank uebertraegt.

verwaltungssysteme von diversen boards muesste ich mir noch ansehen...

[Gavon]

Ich weiß nicht, ob Du hierauf überhaupt ein Statement erwartest, aber ich habe es für einen Kunden mal wie folgt gelöst (individuelles CMS; ja, es musste schnell gehen):

Ich habe mit einer .conf den Default-Wert für Gast gesetzt; meist eine 0. Dann befindet sich die komplette Userverwaltung nicht in einem Array, sondern in einer Datenbank, wo die Rechte für einen Bereich dem jeweiligen Nutzer in einem Record (!) zugeteilt ist... theoretisch sieht es dort so aus:

bID bName eNews eEvents ePreise eNewsletter ... usw.
1 Admin 1 1 1 1
2 Pers1 1 0 0 1
3 Pers2 0 1 0 0

...usw. Ich glaube, dass Du verstehst, was da läuft. Zum Login wird ein verschlüsseltes Array (md5; Session) erzeugt, welches auf den Seiten kontrolliert wird, ob der Zugriff autorisiert ist.

Wenn nun Bereiche ergänzt werden, erweiterst Du die Datenbank... nicht das Script!!

Wenn Du jetzt das Argument nimmst, dass Dir die Idee zum Editieren, Löschen etc. fehlt, dann machst Du aus der "1" je Spalte z. B. eine "1100"; je Befugnis einen Wert usw.

Und wenn das jetzt alles für die Katz war, vielleicht hatte gerade just jemand Verwendung für diese Idee.

[steffenk]

... und wenns noch etwas komfortabler sein soll, dann definierst Du Gruppen nach gleichem Schema. Ein Benutzer, der zu einer Gruppe gehört, erbt die Rechte der Gruppe - je nach Bedarf kann man für die Benutzer zusätzlich Rechte vergeben, das Ergebnis wäre dann eine logische Verknüpfung.

[Driver]

Zitat von Gavon

Ich weiß nicht, ob Du hierauf überhaupt ein Statement erwartest, aber ich habe es für einen Kunden mal wie folgt gelöst (individuelles CMS; ja, es musste schnell gehen):

Ich habe mit einer .conf den Default-Wert für Gast gesetzt; meist eine 0. Dann befindet sich die komplette Userverwaltung nicht in einem Array, sondern in einer Datenbank, wo die Rechte für einen Bereich dem jeweiligen Nutzer in einem Record (!) zugeteilt ist... theoretisch sieht es dort so aus:

bID bName eNews eEvents ePreise eNewsletter ... usw.
1 Admin 1 1 1 1
2 Pers1 1 0 0 1
3 Pers2 0 1 0 0

...usw. Ich glaube, dass Du verstehst, was da läuft. Zum Login wird ein verschlüsseltes Array (md5; Session) erzeugt, welches auf den Seiten kontrolliert wird, ob der Zugriff autorisiert ist.

Wenn nun Bereiche ergänzt werden, erweiterst Du die Datenbank... nicht das Script!!

Wenn Du jetzt das Argument nimmst, dass Dir die Idee zum Editieren, Löschen etc. fehlt, dann machst Du aus der "1" je Spalte z. B. eine "1100"; je Befugnis einen Wert usw.

Und wenn das jetzt alles für die Katz war, vielleicht hatte gerade just jemand Verwendung für diese Idee.

Das schreit nach einer Umstrukturierung meines Projekts, danke!

[Gavon]

Na, so drastisch wollen wir ja nun denken, oder?

[HoRnominatoR]

@gavon
so weit habe ich auch schon gedacht, das spiegelt mein array ja wieder, nur ist das problem, dass ich auch noch die moeglichkeit geben moechte, die spalten fuer die vier funktionen (select, insert, update, delete) dort einzutragen (bspl nr 3) und da zusaetzlich noch in konflikt mit JOINS (um die IDs auszuwerten) und WHERE (damit zB nur eigene datensaetze bearbeitet werden koennen) komme.

[Gavon]

Deswegen hatte ich doch gesagt, dass Du folgende Syntax nimmst:

[UserID][Select 0 or 1][Insert 0 or 1][Update 0 or 1][Delete 0 or 1]

Der erste Benutzer - meist der Admin - hätte überall eine Erlaubnis und der Wert in der Datenbank würde "11111" aussehen. Ein Benutzer, der gar nichts darf, wäre "10000" usw. Verstehst Du das jetzt besser? Die Zahlenkombinationen lädst Du Dir einfach einzeln in ein Array je User bei Verwendung... ganz simpel eigentlich.

[321]

Die User zu gruppieren finde ich OK, aber ich würde ihnen nicht Rechte zuordnen,
sondern eine Tabelle mit den zuschützenden Objekten anlegen
und dort eintragen WER berechtigt ist:
Objekt(key) - Gruppe - User - R-read, R-add, R-upd, R-del, usw.
Pro Objekt sind mehrere Einträge möglich.

Für Gruppe und User sollte ein 'alle'-Eintrag, zB. * möglich sein
R-xxx steht für Rechte: j/n oder 1/0
Bei der Gruppe 'Gaeste' würde dann unter User ein * eingetragen, da Gäste kaum namentlich bekannte User sind.

So wurde das für ein komplexes IRW (Rechnungswesen) gelöst, wo unter Objekt sogar einzelne Konten geführt wurden.
Der Gruppe 'Gaeste' entsprach 'allg. Personal'
Realisiert wurde das aber in einem Nicht-Web-Projekt auf einem ganz andern System und bewährte sich über Jaaahre.

[HoRnominatoR]

@gavon

das prinzip ist klar, es spiegelt nur mein bspl wieder, was allerdings nichts dran aendert, dass die kontrolle ueber spezifische spalten und abhaengigkeiten fehlt -- ein admin darf mehr spalten bearbeiten als ein benutzer. ein admin darf alle benutzer bearbeiten, ein benutzer nur sich selbst.

[Gavon]

Dann kannst Du es doch beliebig erweitern? Lege Dir doch irgendwo in einer "Neben-Table" eine Matrix an, die vorgibt, welcher Wert was regelt oder welcher Bereich betroffen ist...

Dass Benutzer nur sich bearbeiten und der Admin alle... hey, dann lies nochmal von vorne!