BlackCat CMS Version 2.0

Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

BlackCat CMS Version 2.0

Beitrag von shadowcat »

Ich habe mal angefangen, mich mit "dem großen Wurf" zu befassen, also einer Version 2.0 mit komplett neuem Berechtigungskonzept.

Vorweg: Bis auf weiteres geben wir keinen geplanten Release-Termin an, da wir alle über nur sehr eingeschränkte Zeitressourcen verfügen und dieser Schritt wirklich extrem aufwendig wird.

Einige Grundlagen wurden bereits hier dargelegt: http://forum.blackcat-cms.org/viewtopic.php?f=6&t=48


Das auf WB basierende Rechtesystem und die damit verbundenen Probleme / Einschränkungen

Abgesehen davon, daß wir das Rechtesystem bisher (bewußt) stiefmütterlich behandelt haben und schon allein daher einige Probleme herrühren, versuche ich mal zu beschreiben, wie es funktioniert und was die Vor- und Nachteile sind. Dazu muß man wissen, daß WB ursprünglich ganz ohne Rechtesystem entwickelt wurde.

Das WB-Rechtesystem basiert auf Benutzern und Gruppen. Nur Gruppen können Rechte erhalten. Ein Benutzer kann Mitglied in mehreren Gruppen sein und erhält über diese Mitgliedschaften seine Rechte.

Die Hauptnachteile:
  • Die Liste der verfügbaren Berechtigungen ist nicht erweiterbar, bzw. Erweiterungen erfordern Änderungen im Core.
  • Module können sich die verfügbaren Benutzer und Gruppen nicht oder nur sehr eingeschränkt zunutze machen. Daher verfügen Module, die mit Rechten arbeiten, zumeist über ein eigenes Rechtesystem. (z.B. Bookings, KeepInTouch) Das wiederum führt zu einem Wildwuchs an Berechtigungssystemen und Stellen, an denen Rechte vergeben werden können bzw. müssen.
  • Es ist nicht möglich, Rechte zu verschachteln.
  • Die Art, wie die Berechtigungen eines Benutzers gespeichert werden. (Ohne da jetzt genauer drauf eingehen zu wollen.)
Die Hauptvorteile:
  • Relativ einfach zu administrieren und zu durchschauen. (Eingeschränkt durch o.g. Wildwuchs.)

Das geplante Rechtesystem

Wir planen ein erweiterbares Rechtesystem basierend auf einer rollenbasierten Zugriffskontrolle. Hierbei kommen zu den o.g. Ressourcentypen "Benutzer" und "Gruppe" zwei weitere hinzu, nämlich "Rollen" und "Rechte". (Genau genommen gibt es die Rechte natürlich auch schon im alten System, dort sind sie aber "hartverdrahtet" und somit nicht erweiterbar.)

Eine Rolle beschreibt im Prinzip eine Aufgabe, die ein Benutzer erfüllen soll, also z.B. das Erstellen von Beiträgen / Inhalten ("Redakteur"). Hierzu wird die Rolle mit den dafür notwendigen Rechten verknüpft, z.B. "Seite anlegen", "Sektionen verwalten", "Inhalte ändern" usw. Die so konfigurierte Rolle kann nun Benutzern bzw. Gruppen zugeordnet werden, so daß sich die damit verknüpften Rechte entsprechend auswirken können.

Die Hauptvorteile:
  • Die vorhandenen Rechte können jederzeit - z.B. durch Module - erweitert werden.
  • Die Rollen können passend zum Projekt (Anforderungen des Kunden) auf Basis der umzusetzenden Workflows gestaltet werden, ohne eventuelle Vorgaben durch BC berücksichtigen zu müssen.
  • Rechte können weitaus granularer ausgestaltet werden als bisher.
  • Es können Abhängigkeiten definiert werden, z.B. daß das Recht "Inhalte ändern" mindestens auch die Rechte "Zugang zum Backend" und dort "Seitenbaum sehen" benötigt.
Die Hauptnachteile:
  • Aufgrund der Erweiterbarkeit ist das System auch komplexer und kann ggfs. sehr unübersichtlich werden.
  • Es ist prinzipiell möglich, Rechtekombinationen zu vergeben, die unzureichend oder unlogisch sind (z.B. wenn ein Redakteur Seiten anlegen, aber dann nicht bearbeiten kann). Dies soll durch die Definition der o.g. Abhängigkeiten weitestgehend vermieden werden.
Anmerkung: Alle o.g. Rechte sind als Beispiele zu verstehen, die letztendliche Namensgebung wird sich im Lauf der Entwicklung ergeben.


Die Herausforderung

Da das Rechtesystem - obwohl ursprünglich irgendwann mal "dazugebastelt" - inzwischen so tief in den BC-Kern verwoben ist, muß das gesamte Framework (gleichnamiger Ordner) angepaßt werden. Zudem muß eine Art "Kompatibilitätsschicht" geschaffen werden, damit "alte" Module, die das neue System noch nicht kennen, weiterhin funktionieren.

Aufgrund des Umfangs und der Komplexität der Änderungen macht es Sinn, im gleichen Zug weitere Schritte zu unternehmen, die notwendig und zum Teil überfällig sind.
  • Der bisherige framework-Ordner wird aufgespalten. Alle Komponenten, die für BC neu entstanden sind - im wesentlichen das CAT-Unterverzeichnis mit all seinen Helper-Klassen - werden ausgelagert. Der framework-Ordner beinhaltet dann nur noch die WB-Kompatibilitätsschicht.
  • Sämtliche Unterverzeichnisse des backend Verzeichnisses werden gestrichen. Mehr dazu weiter unten.
  • Die Kennwort-Verschlüsselung wird auf einen sichereren Mechanismus - z.b. SHA1 - umgestellt.
Das hat zur Folge, daß BC Version 2.0 voraussichtlich erst mal nur als Vollversion, aber nicht als Upgrade für Version 1.x verfügbar sein wird. Ein Migrationsweg (Update) macht erst Sinn, wenn Version 2.0 weitestgehend stabil ist. Aufgrund der vielen grundlegenden Änderungen handelt es sich bei Version 2.0 beinahe um ein neues CMS.


Das backend-Verzeichnis und warum es weg soll

Bisher ist die Logik des Backends in etlichen Einzelscripten verstreut. Hinzu kommen wiederum etliche Scripten, die per AJAX aufgerufen werden und daher eine Sonderbehandlung (class.secure.php) brauchen. Das hat unter anderem zur Folge, daß
  • Code immer wieder dupliziert wird (z.B. "erst prüfen ob der Benutzer überhaupt in diese Backend-Sektion darf, dann prüfen ob er diese Aktion durchführen darf, ...")
  • diverse index.php Dateien existieren, die von Hackern besonders gern kompromittiert werden
Künftig wollen wir mit der sogenannten Redirect Engine arbeiten. Wer etwa das kitFramework kennt, hat das vermutlich schon verwendet. Im Kern funktioniert das so, daß mit Hilfe einer Datei .htaccess im backend-Verzeichnis - das es zwar noch gibt, das aber weitestgehend leer ist - alle Anfragen an einen sogenannten Controller umgeleitet werden. Das hat eine Reihe von Vorteilen:
  • Sobald der Backend-Folder - egal wie er heißt - in der URL auftaucht, werden alle Anfragen über den Controller (die Klasse) CAT_Backend geführt und von dort aus weiter aufgelöst.
  • Die Klasse kann an zentraler Stelle sicherstellen, daß der Benutzer angemeldet ist und die passenden Zugriffsrechte besitzt. Das mußte bisher immer in jedem einzelnen Script in jedem einzelnen Unterverzeichnis passieren.
  • Die komplette Logik aller Backend-Funktionen ist in Klassen hinterlegt, nicht in X einzelnen Dateien.
  • Viele Hackerangriffe fokussieren die index.* Dateien. Die gibt es dann fast nicht mehr. Nur noch eine im Rootverzeichnis für das Frontend und eine im Backendverzeichnis für das Backend. Diese sind leicht zu überwachen und im Notfall schnell wiederhergestellt.
  • AJAX-Zugriffe können ebenfalls von den Controller-Klassen behandelt werden, so daß weniger "Sonderlocken" notwendig sind.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Um Euch mal einen kleinen Eindruck zu verschaffen, wie BC 2.0 in meiner lokalen Entwicklungsumgebung aussieht, hier mal ein paar Screenshots.
Anmeldemaske
Anmeldemaske
screenshot-2016-06-09-15-46-57.png (14.04 KiB) 6917 mal betrachtet
Dashboard
Dashboard
screenshot-2016-06-08-18-41-47.png (55.2 KiB) 6917 mal betrachtet
Rollenverwaltung
Rollenverwaltung
screenshot-2016-06-08-19-39-46.png (18.59 KiB) 6917 mal betrachtet
Anmerkung zum Backend Theme: Es ist denkbar, daß wir ein alternatives BE Theme mit Release 2.0 zur Verfügung stellen, in erster Linie dient es mir aber als Erleichterung. Zum einen kann ich durch die Entwicklung eines neuen Themes besser erkennen, wo wir noch zu enge Beziehungen zwischen Theme und Core haben; zum anderen kann ich mich auf das konzentrieren, was ich gerade bearbeite, ohne mich dabei um das FreshCat Theme kümmern zu müssen. Vor allem ersteres ist mir wichtig.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Kleine Erweiterung (derzeit umgesetzt für Rollen und Gruppen):
  • Inline Editing von Name und Beschreibung
  • Anlegen einer neuen Rolle/Gruppe
2016-06-09 18_16_08.png
2016-06-09 18_16_08.png (26.67 KiB) 6911 mal betrachtet
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
Morpheus
Beiträge: 1050
Registriert: Do 8. Aug 2013, 10:49
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von Morpheus »

Gefällt schon mal.

Sieht modern aus
Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen!
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Naja, die Basis ist ein freies Bootstrap-Theme, ich bin ja kein Designer...
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Aktuelle Darstellung für Benutzer.

Edit: Achso, blau (Bootstrap CSS Klasse text-primary) ist die Primärgruppe des Benutzers.
Dateianhänge
2016-06-10 14_31_55.png
2016-06-10 14_31_55.png (17.95 KiB) 6900 mal betrachtet
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Bearbeitung der Gruppenmitglieder: Beim Anklicken des blauen "Gruppenmitglieder bearbeiten" Icons wird die Liste der Benutzer per Ajax geladen und im Fuel UX Control "Repeater" dargestellt. Hat der angemeldete Benutzer das Recht, Gruppenmitglieder zu verwalten, kann er aufgelistete Mitglieder löschen. Ausnahme: Der Benutzer mit der ID 1 (das ist immer noch der "Superadmin", also der Benutzer, der BlackCat initial installiert hat).
2016-06-13 19_33_02.png
2016-06-13 19_33_02.png (22.58 KiB) 6880 mal betrachtet
Bei der Benutzerverwaltung kann man umgekehrt jetzt die Gruppe durch Anklicken entfernen. (Auch hier: Berechtigung vorausgesetzt.)
2016-06-13 19_36_17.png
2016-06-13 19_36_17.png (14.1 KiB) 6880 mal betrachtet
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Ist das halbwegs verständlich erklärt?

Rollenbasierte Zugriffskontrolle - Role Based Access Control, RBAC

Einführung: https://de.wikipedia.org/wiki/RBAC

Bei einem rollenbasierten Rechtesystem werden Rollen definiert, die sich an die jeweiligen Aufgaben eines Benutzers orientieren. Eine Rolle könnte z.B. "Redakteur" heißen und Rechte zum Anlegen von Seiten und Ändern von Inhalten beinhalten. Einem Benutzer können nun beliebig viele Rollen zugewiesen werden, aus denen sich die effektiven Rechte ergeben.

Begriffe

Rollen

Eine Rolle beschreibt im Prinzip eine Aufgabe, die ein Benutzer erfüllen soll, also z.B. das Erstellen von Beiträgen bzw. Inhalten. Hierzu wird die Rolle mit den dafür notwendigen Rechten verknüpft, z.B. "Seite anlegen", "Sektionen verwalten", "Inhalte ändern" usw. Die so konfigurierte Rolle kann nun Benutzern bzw. Gruppen zugeordnet werden, so daß sich die damit verknüpften Rechte entsprechend auswirken können.

Rechte

Rechte oder Berechtigungen werden ausschließlich mit Rollen verknüpft. Ein Recht könnte z.B. sein, daß ein Benutzer im Backend den Seitenbaum sehen oder sich überhaupt erst im Backend anmelden darf.

Benutzer

Benutzer sind in BlackCat CMS in erster Linie für den Zugriff auf das Backend relevant. Es ist aber auch denkbar, daß man bestimmte Bereiche der Webseite nur bestimmten Besuchern zugänglich machen möchte. Dies erfordert, daß sich der Besucher gegenüber dem CMS autorisieren (anmelden) kann - er braucht also eine Benutzerkennung samt Kennwort.

Gruppen

Benutzer können zu Gruppen zusammengefaßt werden. Diesen Gruppen können wiederum Rollen zugeordnet werden. Über die Gruppenmitgliedschaft erhält der Benutzer dann die Berechtigungen, die in den Rollen definiert sind.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
Morpheus
Beiträge: 1050
Registriert: Do 8. Aug 2013, 10:49
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von Morpheus »

Ja, logisch
Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen!
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: BlackCat CMS Version 2.0

Beitrag von shadowcat »

Mal wieder ein Screenshot...
2016-07-25 19_38_00.png
2016-07-25 19_38_00.png (24.34 KiB) 6584 mal betrachtet
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Gesperrt