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.)
- 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.
- 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.
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 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
- 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.