Backend-Berechtigungen: Bug oder bin ich blöd?
- crimle
- Autor
- Offline
Meine Webseite soll von Redaktor A, Redaktor B, ... Redaktor Z betreut werden.
Es gibt Beiträge in der Kategorie A, Kategorie B, ... Kategorie Z die nur vom jeweiligen Redaktor bearbeitet werden dürfen.
Ich habe also Benutzergruppe A, Benutzergruppe B, ... Benutzergruppe Z eröffnet. Übergeordnete Gruppe ist "Öffentlich".
Dann habe ich Benutzer A, Benutzer B, ... Benutzer Z ertstellt und sie der jeweiligen Benutzergruppe zugewiesen.
Nun bin ich dabei, die Kategorieberechtigungen zu definieren. Das heisst:
MENÜ Inhalt > Kategorien > Kategorie öffnen > Kategorieberechtigungen.
Jede meiner 25 Gruppen hat hier bei allen 5 Aktionen bereits "Neue Einstellung" = "Vererbt" und "Errechnete Einstellung" = "Erlaubt".
a) ist das unlogisch, denn die übergeordnete Gruppe ist ja "Öffentlich". Die Vererbung müsste ja von dieser Gruppe stammen, und diese hat "Nicht erlaubt".
b) gibt das eine Wahnsinnsarbeit, denn ich muss bei
- 25 Benutzergruppen
- 25 Kategorien
- 5 Aktionen
manuell in "Verweigert" ändern. Das sind 25 * 25 * 5 = 3125 Mausklicks!!!
Das kann's doch irgendwie nicht sein?!
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- Chris Hoefliger
- Offline
Ebenfalls lesenswert, und dabei vielleicht näher an demm, was du im Sinn hast, ist der Artikel von Randy Carey (ebenfalls Joomla Magazine August/2012) über 'A Case for Role-Based ACL' , wo es drum geht, die eingebaute ACL bis auf Super User und Public über Bord zu werfen und von Grund auf selber was eigenes aufzubauen
Wer nicht über den Anstand verfügt, ein kleines "Thänx" auszusprechen, muss sich nicht wundern, künftig ignoriert zu werden!
Kein Support via PM oder Mail. Entsprechende Anfragen werden ignoriert.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- crimle
- Autor
- Offline
Warum nicht? Ich habe das nicht selbst erfunden, sondern in einem Tutorial wurde das überzeugend empfohlen. Wir sind uns doch einig, dass die Rechte der übergeordneten Gruppe vererbt werden? Wenn man also nicht möchte, dass die Redaktoren irgendwelche Rechte erben, sondern sie lieber explizit setzen will, dann nimmt man als übergeordnete diejenige Gruppe die am wenigsten Rechte hat und das ist die Gruppe "Öffentlich". Die hat nämlich keine: Überall ist "nicht erlaubt". Alle untergeordneten Gruppen haben aber "vererbt" und "Errechnete Einstellung" = "Erlaubt". Da kann irgendwas nicht stimmen.Wenn du eine neue Gruppe erstellst, wirst du gefragt, welches denn die übergeordnete Usergruppe sein soll - da wählst du dann sicherlich nicht 'öffentlich'.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- Chris Hoefliger
- Offline
Prinzipiell denke ich, dass du die Sache viel zu kompliziert machen willst. Ich hatte in einem früheren Berufsleben mit einer Windows Domäne zu tun, die Domäne hatte Verzeichnisse für Projekte und Dokumentationen (unter anderem) Jetzt ging es darum, besimmte Verzeichnisse für bestimmte Gruppen zum Lesen oder zum Lesen/Schreiben zugänglich zu machen.
Es handelte sich um so 20 etwa Verzeichnisse und um die rund 200 Mitarbeiter. Nachdem man dann bei 15 Gruppen angekommen war (ein Mitarbeiter konnte durchaus in mehreren Gruppen sein), wurde die Sache so unübersichtlich, dass keine Sau mehr den Durchblick hatte. Leute kamen, gingen, wechselten den Job oder die Funktion.... es war eine durchaus dynamische Angelegenheit. Was will man mehr, das Bordell war komplett und die Kacke voll am Dampfen.
Die Lösung war schliesslich: Es gibt 3 Gruppen: kein Recht, Lesen, Lesen/Schreiben; Basta. Mit deinen 50 Gruppen bist du auf alle Fälle jenseits von Gut oder Böse. Das wird nicht funktionieren, bestenfalls sperrst du dich selber irgendwann aus.
Ich mache jede Wette, wenn du mit deinem Setup zu einem Drittel durch bist, gibst du auf. Oder du hast keine Übersicht mehr. Oder beides. Oder du willst mit Joomla nichts mehr zu tun haben.
Wer nicht über den Anstand verfügt, ein kleines "Thänx" auszusprechen, muss sich nicht wundern, künftig ignoriert zu werden!
Kein Support via PM oder Mail. Entsprechende Anfragen werden ignoriert.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- crimle
- Autor
- Offline
Diese Redaktoren sind nicht sehr talentiert im Umgang mit der [Delete] und anderen Tasten. Deshalb möchte ich deren Backend so weit wie möglich abdichten, vor allem untereinander. Es wird also keine verschachtelten Gruppen und keine gegenseitigen Berechtigungen geben. Diese flache Berechtigungsstruktur scheint mir trotz der Menge der Redaktoren überschaubar. Es sind übrigens nicht 50 sondern "nur" ca. 25. Aber egal wie viele Gruppen: die Rechte-Vererbung sollte doch logisch sein. Nochmals:
- Jede Gruppe erbt die Rechte der übergeordneten Gruppe. Einverstanden?
- Die Gruppe "Öffentlich" besitzt keine Backend-Rechte. Einverstanden?
- Wieso hat dann jede neue Gruppe die ich unterhalb der Gruppe "Öffentlich" erstelle automatisch alle Rechte?
Oder anders gesagt: mein Vater enterbt mich und ich bekomme trotzdem sein ganzes Vermögen?
Könntest Du das vielleicht mal ausprobieren ob das bei Dir auch so ist? Ich meine nicht die Sache mit dem Vater, sondern erstelle mal eine neue Gruppe, ordne sie der Gruppe "Öffentlich" zu und berichte, welche Rechte die neue Gruppe hat. Das wäre sehr nett! Danke!
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- Chris Hoefliger
- Offline
Die übergeordnete Gruppe ist Öffentlich, die Gruppe Test erbt die Einstellungen von der öffentlichen Gruppe, darf also garnix.
Bei Joomla 3 sieht die Sache ähnlich aus (Joomla 3.1 Beta2, aktuelle Testversion, wird mit Github synchronisiert):
Wer nicht über den Anstand verfügt, ein kleines "Thänx" auszusprechen, muss sich nicht wundern, künftig ignoriert zu werden!
Kein Support via PM oder Mail. Entsprechende Anfragen werden ignoriert.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- crimle
- Autor
- Offline
Öffentlich | Vererbt | Nicht erlaubt
Meine Gruppe A | Erlaubt | Erlaubt
Meine Gruppe B | Erlaubt | Erlaubt
...
Meine Gruppe Z | Erlaubt | Erlaubt
Jetzt wird's spannend: bei Dir auch? Falls ja bedeutet das, ich muss
- 25 Kategorien erstellen
- Bei jeder Kategorie ist die Default-Einstellung "Erlaubt" für 1 Gruppe richtig und für 24 falsch.
- Pro Kategorie gibt es 5 Aktionen (Erstellen, Löschen, Bearbeiten, Status bearbeiten, Eigene Inhalte bearbeiten)
- Ich muss also anscheinend bei jeder Kategorie die Kategorieberechtigungen für 24 Gruppen abändern.
- Wäre die Default-Einstellung umgekehrt (nicht erlaubt), müsste ich nur je 1 Gruppe ändern.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- Tribal6
- Offline
Wäre die Default-Einstellung umgekehrt...
Die Default-Einstellung müsste sich eigentlich umkehren lassen, rsp. deren Interpretation im Code. Das erreichst du, indem du in einem Override der entspr. Ansicht überall da, wo der Code fragt 'ist erlaubt' die Interpretation des Statements umkehrst in 'ist nicht verboten':
Z.b. aus
if($user->autorise('core.edit.state'))....
machst du
if(false !== $user->autorise('core.edit.state'))....
Die Einschränkung dabei ist halt, du kommst mit einem Override nur an die Abfragen in der Template-Datei ran.
Tue das, was du kannst, mit dem was du hast, da wo du bist.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- crimle
- Autor
- Offline
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- Chris Hoefliger
- Offline
- könntest du 'Editor' als Wurzel deiner Gruppen nehmen, oder vielleicht 'Author'. Dann wärst du schon ziemlich in der Nähe von dem, was du willst.
- Wenn dir das noch nicht nahe genug ist, machst du deine eigene Gruppe, nur als Wurzel zu deinen 50 oder so Gruppen, und gibst der Gruppe Rechte, die am Nahesten von dem sind, was du möchtest.
Dann kannst du nach Belieben spielen mit deinen Kategorieberechtigungen.
Wer nicht über den Anstand verfügt, ein kleines "Thänx" auszusprechen, muss sich nicht wundern, künftig ignoriert zu werden!
Kein Support via PM oder Mail. Entsprechende Anfragen werden ignoriert.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.