Ideales Rechte-System
 

Schon wieder ein Thema von mir (hoffentlich wirft mir niemand vor, dass ich spamme! ;) )


Wie sollte man eurer Meinung nach ein idealews
Rechte-Management-System für ein Forum umsetzen?
Damit meine ich jetzt nicht, vom Umfang der Optionen (Kann posten, kann lesen, kann Umfragen erstellen,...),
sondern ehr im Sinne von:

- Soll jede Gruppe ein Standardrechte-System haben,
dass dann vom jeweiligen Forum überschrieben wird oder
- Wie werden die Rechte einem Board zugewiesen ?
- Wie speichere ich das Ganze?


Verschiedene Systeme gibt es ja genug!
Ich weiß einfach nicht, wie ich es in meinem Forum machen soll, bitte helft mir!

naja ich kann derzeit nicht genaues sagen... ich sage mal eine Mischung zwischen dem vBulletin (3) und dem wBB 2.1 Rechtesystem, das ist schon ideal.

Sorry, ich kenne nur das vom vBulletin 2, ist das von 3 großartig anders?

Ich habe es in meinem aktuellen Entwurf so gemacht:

Es gibt für jede Gruppe einen Eintrag in der DB der festlegt was für Rechte sie normalerweise in den Foren haben sollten.

Dann können für jedes Forum nocheinmal extra Rechte gesetzt werden. Das geht sowohl für einzelne Benutzer als auch für ganze Gruppen.

Wobei in diesem Fall ein Forum immer die Rechte vom vorhergehenden erbt.

Edit: Rechte die einem Benutzer erteilt werden haben eine größere Gewichtung als die der Gruppe. Wurde für ein Forum für Gruppe als auch Benutzer unterschiedliche Rechte gesetzt. Werden die vom Benutzer genommen

Die einzige Änderung die ich bisher gesehen habe ist das ein User mehreren Benutzergruppen angehören kann

@DaddyCool: Das mit den mehreren Benutzergruppen ist anscheinend in letzter Zeit sowieso die letzte Mode!
Auf jeden Fall danke für die Hilfe!

Ich habe mri jetzt folgendes überlegt:

Jede Benutzergruppe bekommt Standardrechte zugewiesen und zwar in der selben Tabelle, in der sie gespeichert ist.

Tabelle: user_group

Jeder Benutzer kann in beliebig vielen Gruppen sein, daher benutze ich noch eine Tabelle, um die User mit den Gruppen zu verknüpfen.

Dabei bekommen alle Rechte immer den maximalen Wert zugewiesen, der in den Gruppen, denen der User angehört zu finden ist!

Beispiel:

User Admin0815 ist in folgenden Gruppen:

Mitglieder (can_use_acp = 0),
Administratoren (can_use_acp = 1),
Moderatoren (can_use_acp = 0)

Daher ist es ihm möglich, das ACP (Admin Control Panel) zu nutzen.

Wenn ein Bereich (zB ein Forum) andere Rechte gesetzt hat, werden die den Users überschrieben.

Ich weiß nur noch nicht, wie ich es speichern soll, wenn eine Berechtigung keinen Wert zugewiesen hat und stattdessen einen Standardwert benutzt!
Wie könnte man sowas machen? Als NULL vielleicht? Oder als 0=nein, 1=ja, 2=unset ?

wie wärs mit -1??

Feld darf nur nicht unsigned sein

@DaddyCool: WIeso bin ich da nicht gleich drauf gekommen? Vielen Dank!

Kann ich das auch in ein TINYINT (1) Feld ganz normal eintragen?

Ja, es geht jede INT Spaltenart, nur wie gesagt, du darfst das Feld nur nicht als unsigned markieren.

Okay, dann werde ich es so machen, dass das Array mit den User-Rechten erst mit den Daten aus seinen Gruppen gefüllt werden und dann alle Werte, die noch nicht gesetzt sind (bzw. auf -1 stehen) mit Standarddaten gefüllt werden!

Das sollte eigentlich keinerlei Sicherheitsmängel beinhalten oder probleme darstellen oder irre ich mich?

Ob es Sicherheitsprobleme geben wird musst du austesten.

Das kann ich so auf die schnelle jetzt nicht beurteilen.

Hi @ll

Ich habe vor längerer Zeit auch ein Rechte System entwickelt, dies geht noch a bissal mehr in die Tiefe.

Wie erkläre ich das am Besten??

Also:
Ein User ist in einer oder in mehrern Rollen.
diese Rollen beinhalten eine oder mehrere Gruppen
Eine Gruppe hat rechte auf eine bestimmte Funktion.

Auf eine Funktionen gibt es Rechte: Read, Insert, Modify, Delete

Beispiel:
Es gibt die Rolle Redakteur
Diese hat mehrere Gruppen
zB
News-Redakteur, Termine-Red...

da es ein Redakteur ist, hat er
lesen, Einfügen- Rechte.

Warum das ganze??
Damit man nicht jeden User die Rechte vergeben muss, bildet man Gruppen, und schliesst diese in Rollen zusammen.

So erspart man sich viel Zeit beim neuanlegen eines Users.

Um das ganze noch zu versüssen, hab ich zusätzlich die Möglichkeit, den User Sonderrechte einzuräumen.
Das bedeutet nicht umbediengt, das er mehr kann, sonder das sind Sonderregeln, die nur diesen User betreffen.
Hier kann ich einen User zB noch das Löschen Recht auf eine Funktion geben, welches er über die Gruppe bzw. Rolle nicht hätte.
Andersrum kann ich ihm auch das Recht entziehen, obwohl er es hätte.

Das ganze kann man mit einen Redaktion-System einer Zeitung vergleichen.

@Nev
erinnert mich stark an das Schema das z.B. das vB3 und gerüchteweise auch das WBB2.1.schiessmichtod nutzen.

Dort kann man Gruppen zwar nicht zusammenfassen, einem Benutzer jedoch mehreren Benutzergruppen zuordnen.

Ist zwar nicht so komfortabel, sollte aber den gleichen Effekt haben.

Hi @gain

Mein Rechte-System gibt es schon etwas länger
knapp 2 Jahre.:D

Mal sehen ob ich das richtig verstehe...

Man definiert gewisse Aktionen:
- lesen
- schreiben
- editieren
- löschen

Dann erstellt man Gruppen und vergibt diesen die Rechte an gewissen Aktionen:
- Autor: lesen, schreiben
- Moderator: editieren, löschen, lesen, schreiben
- Benutzer: lesen

Und nun nehmen wir mal das Beispiel Forum. Wie vergebe ich dann diese Rechte getrennt für die Boards?
Gruppen den Boards zuweisen und über die entsprechende Gruppe die Berechtigung erhalten?

Links zu eigenen Themen, die sich auch um ein rechtesystem drehen:
http://boardunity.de/rechtesystem-au...auf-t3790.html
http://boardunity.de/eigenes-cms-mod...bau-t3913.html

Hi eBoy

Ich fühle mich mal angesprochen

Beispiel für ein Forum:
Als Gast bekommst du generell das Kennzeichen Read
dies erlaubt den Besucher, alles zu lesen

Jedes Board ist wie ein Modul zu sehen.
d.h.:
Der Besucher muss in der Gruppe (Board) sein, und dort das Recht Lesen
ansonsten darf er nicht hinein.

dadurch kannst du auch den Gast wieder aussperren.

Der registrierte Besucher
Hat neben dem Recht: Read auch Modify
d.h. er darf auch seine Beiträge löschen.

Die Gruppen ist eine Zusammenfassung von Rechte.
Ein User kann in mehreren Gruppen sein.
Wobei sie zusammen ein gesamtes Recht defineren.

Ich hab vor längerer Zeit mal einen Text geschrieben, siehe attachment

Diese Gruppen wären dann vergleichbar mit einer Rechte-Datenbank, die für gewisse Aktionen die Rechte an die Gruppen vergibt. In diesen Gruppen muss der User dann Mitglied sein, um die entsprechende Aktion ausführen zu können.
Wobei diese Gruppen dann nichts mir den "Gruppen" zu tun hätte, die als Hauptgruppe angezeigt wird (Gruppenmitgliedschaft nach z.B. geschriebenen Beiträgen).
Text habe ich heruntergeladen und werde ich mir durchlesen, danke ;)

Das ganze sieht für mich wie ein einfaches Rechtesystem mit Gruppen- und Benutzerrechten...
Was hat es dann in kurzen Worten mit den "Rollen" auf sich?

ein einfaches Rechtesystem mit Gruppen- und Benutzerrechten
geht ned so in die Tiefe, mit den Rechten (Read, Insert, Modify, Delete)
es ist angelehnt am Unix-Rechte-System

Die Rolle dient nur zur Unterstützung.
diese kann man definieren um sich die gesamten Zuweisungen für einen User zu ersparen is quasi eine Schablone.

Zusätzlich, was in dem Text ned rausgekommen ist, kannst du den User obwohl er die Rechte aus der Rolle hat, Rechte entziehen bzw. ihm auch Sonderrechte einräumen, die ausser halb seiner Rollen liegen.

So kannst du obwohl du Rollen vergibst, jeden noch zusätzlich anpassen.

Das ist imo nicht die letzte Mode, sondern ein notwendiger Fortschritt! Eine Beschränkung auf eine Gruppe ist nicht akzeptabel, wenn man mehr als eine Handvoll Nutzer hat. In jedem mittelgrößeren Unternehmen ist jeder Mitarbeiten Teil mehrerer Gruppen/Projekte, hat oft mehrere Funktionen/Rollen, um so seine Arbeit zu verrichten. So kann man die Berechtigungen näher an der Wirklichkeit modellieren und muss nicht für jede Kombination eine neue spezielle Gruppe aufmachen und alle Nutzer durch die Gegend schieben. jm2c

Ich würde das mal so beschreiben/ machen:

Zugriffsrechte für Modul (z.B. in der Table "module") => grundlegendes Zugriffsrecht
Zugriffsrecht für Kategorie (z.B. Rechte-Table des Modules) => Darf der User, der das Modul betreten darf auch diese Kategorie betreten?
Berechtigung für Aktionen => Darf der User schreiben, (eigenes) editieren, (fremdes) moderieren oder gar administrieren?

Dazu noch global-Admin als Gruppe => besitzt alle Rechte


ich finde dein Rechtesystem nicht unbedingt schlecht, aber zu kompliziert, weshalb ich es auch nicht zu 100% verstehe...


Dazu würde ich versuchen das ganze einfach zu halten, also die Parameter (Rechte des Users/ der Gruppe und Voraussetzungen) nicht in der rechte-Klasse laden, sondern übergeben. Dann kann man die Funktion für die Zugriffsrechte für Module UND Kategorien für beides verwenden.

Ich muss mir da mal weitere Gedanken dazu machen ;)

Hi @gain

Der Ansatz is eine Anregung, ned das Gelbe vom Ei

Jeder hat andere Anregungen bzw. Bedürfnisse.

Bisher hab ich mit dem System einfach alles abdeken können.

Es ist mir auch sehr hilfreich gewesen. Werde da einige meiner Ideen überdenken müssen und schauen, wie ich das Optimum für mich rausholfen kann.

Berechtigungen die ich wohl benötige:
- lesen (Zutritt)
- schreiben
- editieren (eigene)
- löschen (eigene)
- editieren (alle)
- löschen (alle)

So kann ich auch Mderatoren und Administratoren realisieren. Die User werden in Gruppen organisiert. Dieses System ist universell und beliebig erweiterbar. Man muss die Klasse/ Funktion nur erneut aufrufen und die zu prüfenden Daten und die Voraussetzungen mitübergeben.
Das ware wenig Code und universell einsetzbar... denke/ hoffe ich ;)

Dein Rechte-System hat einen kleinen Hacken

Ein Mod kann alle Beirtäge in jeder Sektion bearbeiten bzw. löschen.
das wäre in meinen Augen ein Super-Mod

Ein Mod darf nur in seiner Sektion diese Rechte haben.

Die Rechte werden immer nur für einen Bereich bzw. eine Kategorie vergeben und kann man somit variieren. Ich bin mir momentan nur nicht ganz im klaren, wie die DB-Strukur dafür aussehen müsste...

Einmal gibt es eine module-Tabelle, in der die Zugriffsrechte für einen Bereich vergeben werden können, weitere Rechte werden dann getrennt davon nochmal für jede (Sub-)Kategorie bzw. Aktion des Moduls/ Bereichs vergeben.

Dazu sollte wohl eine Tabelle [MODUL]_rechte Tabelle exisiteren, die Spalten entsprechend der obigen Rechte besitzt und diesen wiederum werden dann Gruppen- und/ oder User-ID's zugeordnet.

Könnte das so funktionieren?

Ich glaube, du solltest dir das ganze nochmal genau überlegen, auf was du dich da einlässt

So einfach wie du, dir das vorstellst, ist es ned.

Da müssen einige Sachen überdenken.

Warum sollte man ein Globales Recht auf eine Funktion legen, ausser wenn man sie gesamt Ausschalten will.

Du kannst die Beziehung Funktion - Recht nur auf die Gruppe oder auf den User legen.

Das eine wäre alle User- und Gruppen-ID's in eine Spalte schreiben (z.B. Komma getrennt) und dann wieder auseinandernehmen oder 2 Spalten je Recht (1* User, 1* Gruppe) anlegen.

In meinen Gedanken sieht das alles ganz doll aus, doch die Umsetzung (DB-Tabellen) ist da problematisch bzw ich habe dazu keine gute Idee.

@Nev:
Dein Rechtesystem habe ich nicht verstanden, weshalb ich nicht weiß, ob dieses einfacher oder besser ist als meine Idee.

Das Rechtesystem, das ich umsetzen will, sollte einfach nur Gruppen und auch Usern Rechte vergeben/ prüfen. Also Gruppen und/ oder Usern Rechte und Verbote für gewisse Bereiche geben. Verbote haben Vorrang. Berechtigungen werden ODER_Verknüpft

Verbot => IMMER verbot!
1+ Berechtigungen => true
0 Berechtigungen => false

Vergebe ich Rechte nur für Gruppen, dann habe ich später evtl sehr viele Gruppen, wenn einzelne/ wenige User zusammen die Rechte für einen Bereich haben sollen und alle anderen keinen Zutritt...

Vielleicht hilft es dir, wenn du dir erstmal ein paar fertige Usermanagement-Systeme anschaust. Um das Prinzip der Rollen zu verstehen, wuerde ich folgende Klassen vorschlagen: http://www.phpclasses.org/browse/package/513.html . Das Package ist nicht so umfangreich und meiner Meinung nach leicht zu ueberschauen. Da kannst du auch sehen, wie die Tables aufgebaut sein koennten. Ansonsten gibt es auf phpclasses.org noch diverse andere Beispiele die man sich anschauen kann um ein Grundverstaendnis fuer eine moegliche Umsetzung zu bekommen.

Ich kann dir wirklich nur zu einem Rollen-Rechtesystem raten. Die Flexibilitaet die du dir damit schaffst, willst du irgendwann nicht mehr missen.

Ok, ich habe zwar oftmals Probleme mich in fremden Code einzuarbeiten, aber ich schau mit die Klasse mal an ;)

Kann mir jemand diese Klasse an xetolosch.arcor.de schicken, ich bin dort nicht angemeldet...

Hier gibts die direkt zum Download: http://adnoctum.netfirms.com/products/auth/

Wie gesagt, ist nur ein Beispiel wie sich sowas umsetzen laesst. Aber der Code ist gut zu durchblicken. Da musst du dich nicht gross einarbeiten. Ich glaube da waren auch Beispiele dabei.

Momentan sehe ich immernoch die wenigsten Probleme mit einem gruppenbasierenden Rechtesystem.

- Aktionen besitzen Rechte (lesen, schreiben, editieren, ...)
- Diesen Rechten werden Gruppen zugeordnet (eindeutige Zahlen)
- Den Gruppen werden User zugeordnet (eindeutige Zahlen)

Geprüft werden diese dann mittels AND-Verknüpfung von benötigten Rechten und Gruppen über die eindeutigen Zahlen.

Dies ist das einzigste Rechtesystem, das ich umzusetzen verstanden habe. Ich werde mir auch weiterhin andere anschauen und überlegen, wie ich Userrechte noch integrieren kann.

falls es noch nicht kam, es gibt da diese Doku vom Koehntopp über phplib. Da ist auch ganz gut erläutert, wie das auth-modul funktioniert, da kannst du dir vielleicht ein paar anregungen holen.

http://kris.koehntopp.de/artikel/phplib-deutsch/

Danke, muss ich mir mal anschauen ;)

Ist es ausreichend mit einem globalen bannen zu arbeiten, oder sollte man das für verschiedene Module getrennt lösen? Globaler Bann würde sich einfach realisieren lassen.

Hier die geplante Abfolge:
1.) User- und Gruppenrechte kombinieren
2.) notwendige Rechte für den Zugriff/ die Aktion holen
3.) Berechtigung prüfen (true oder false)
4.) Berechtigung wiederrufen wenn ein Verbot vorliegt
5.) Berechtigung wiederrufen wenn der User gebannt ist
return "true" oder "false"

Alternative andere Prüfreihenfolge:
=> liegt ein verbot vor oder ist der User gebannt? => Rechte nicht prüfen und direkt "false" zurückgeben


Welche der beiden Möglichkeiten haltet ihr für besser und sinnvoller?

Mit Rollen einfach die jeweilige Rolle entziehen :)

Diese Rolle oder die Berechtigung soll ja nur zeitweise entzogen werden und nicht dauerhaft. Somit kann ich die normalen berechtigungen nicht entziehen, sondern diese nur als ungültig markieren. Dazu benötige ich evtl eine neue Spalte.
Globales bannen kann ich in der Mitglieder-Tabelle problemlos mit einer Spalte realisieren, während ich für das Bannen einzelner Module in der gesamten module-Tabelle eine Spalte hinzufügen muss, wo ich alle gebannten Mitglieder-ID's reinschreiben muss. Diese müsste ich dann wieder trennen und prüfen, ob die entsprechende User-ID dabei ist. Also mehr aufwand wie dies für einen globalen Bann notwendig wäre.

Einfachere Möglichkeiten werden gerne genommen ;)

Also ich finde deine Rechtesystem ziemlich umstaendlich. Nicht nur von der Umsetzung, auch vom Handling. Wenn ich jemandem in einem Rollensystem einen Bereich, auch nur zeitweise sperren will, dann loesch ich seine entsprechende Rolle und wenn er wieder rein darf, dann bekommt er sie halt wieder. Einfacher gehts nicht. Die benoetigten Rollen lassen sich ganz simple in jedem Modul definieren und werden beim laden geprueft. Fertig. Globales Bannen ist genauso ueber eine Rolle moeglich, bzw. ueber eine Gruppe die entsprechende Rollen hat oder nicht hat und der der User zugeordnet ist.

1.) Dann erklär mir bitte mal jemand verständlich wie das mit Rollen funktionieren soll und, abgesehen von der Bezeichung, der Unterschied zu finden ist...
Ich meine auch die Umsetzung in DB-Tabelles!

2.) Es ist immernoch die Frage ob es Sinn macht, eine Bannung nicht ausschließlich global durchzuführen. Ein Spammer wird wohl sein Beitragsniveau nicht nach dem Modul ändern ;)