Get the MOST

Im Rahmen der Schlankheitskur vom Zikula Core sind einige Altlasten bereits entfernt worden. Das Admin-Interface baut nun auf dem EasyAdminBundle auf.

Ein größerer Knoten, den es noch zu entwirren gilt, betrifft die miteinander zusammenhängenden Themen Benutzer, Gruppen, Rechte, Rollen, Security. Dieser Beitrag beleuchtet unsere damit einhergehenden Gedankengänge und zeigt auf, welchen Plan wir für die nächsten Schritte verfolgen wollen.

Wo kommen wir her?

Seither wurden die relevanten Funktionen in Zikula durch folgende Bausteine bereitgestellt:

• GroupsBundle: erlaubt die Verwaltung von Benutzergruppen; beinhaltete früher auch Möglichkeiten zur Bewerbung bei einer Gruppe, welche kürzlich entfernt wurden. Ob Gruppen notwendigerweise UI-basiert verwaltet werden müssen, sei auch einmal dahingestellt. In Zikula werden Gruppen vor allem benötigt, um Zugriffsrechte zu definieren.
• LegalBundle: ist für die Integration rechtlicher Dokumente zuständig inklusive der Funktionalität, dass Benutzer ihr Einverständnis zu bestimmten Policies abgeben müssen.
• PermissionsBundle: dient der Verwaltung von Zugriffsrechten für die vorhandenen Komponenten. Hier wird noch ein eigenes Berechtigungssystem an Stelle der rollenbasierten Vorgehensweise in Symfony verwendet.
• Profile: stellt Benutzerprofile sowie Avatar-Management zur Verfügung und bietet die Möglichkeit, die Profilfelder dynamisch zu konfigurieren.
• UsersBundle: die Benutzerverwaltung mit jeglichen Basisfunktionen wie Login, Registrierung und so weiter ist der zentrale Ankerpunkt für die übrigen Bundles. Auch ein eigenes System für unterschiedliche Authentifizierungsmethoden ist hier beheimatet.
• ZAuthBundle: implementiert die internen Authentifizierungsmethoden, um einen Benutzer anhand Benutzernamen und/oder Mailadresse anmelden zu können. Beinhaltet unter anderem Verifizierungen und Mappings, um einen Benutzer mit seinen Login-Informationen zu verbinden. Auch Funktionen wie die Veränderung von Mailadresse oder Kennwort, das Zusenden eines neuen Kennwortes etc. sind Teil dieses Bundles.

Wo wollen wir hin?

Die Devise für Zikula 4 gilt natürlich weiter: weniger Eigenbau, sondern Symfony first! Einige offensichtliche Punkte für einen Rückbau sind oben schon angedeutet.

Zum Beispiel macht es keinen Sinn, dass Zikula ein eigenes System zur Implementierung von Authentifizierungsmethoden hat - das Security-Bundle von Symfony stellt eine sehr solide Basis dar: hier kann man einen Authenticator mit einem UserProvider implementieren, womit sich beliebige Wünsche umsetzen lassen. Neben den sechs beschriebenen Bundles gab es auch noch das OAuthBundle welches bereits entfernt worden ist, denn es gibt schon diverse OAuth-basierte Authentifizierungsmöglichkeiten für Symfony.

Auch ein eigenes System für Zugriffsrechte macht aus der Warte betrachtet keinen Sinn mehr, denn wir wollen ja Bundles, welche voll kompatibel zu Symfony sind.

Eine weitere Anforderung neben einem schlanken Ansatz ist, dass das User-System gut mit dem EasyAdminBundle kombiniert werden kann. Das EAB bietet Ankerpunkte, um z. B. ein Benutzermenü einzubinden mit den dazugehörigen Service-Links. Auch die Administration selbst sollte entsprechend über EAB funktionieren, hierfür muss Zikula-seitig ggf. ein kleines Integrationslayer gebaut werden.

Was soll ins Gepäck?

Ausgangspunkt der Recherche

Wir hatten uns einmal unterschiedliche mögliche Lösungen angeschaut, die theoretisch als Basis eingesetzt werden könnten. Damals stand noch nicht fest, dass wir in Sachen Admin-Interface auf das EAB setzen wollen. Auf Grund seiner Popularität und aktiven Entwicklung war es aber schon ein Wunsch von uns auf das EasyAdminBundle bauen zu können, auch weil es gut zum modellgetriebenen Ansatz von ModuleStudio passt. Wichtig war es uns weiterhin, möglichst nah an plain Symfony zu bleiben, damit wir nicht vom Regen in die Traufe geraten, was die zu hohe Kopplung an zusätzliche Konzepte und Mechanismen betrifft.

Angewendetes Ausschlussverfahren

Folgende Ansätze haben wir uns zwar angeschaut, schienen uns aber relativ schnell als für Zikula nicht tragfähig:

• Das Content Management System Sulu stellt ein SuluCommunityBundle bereit. Das bietet Funktionen wie Registrierung und die Handhabung vergessener Kennwörter, ist allerdings eng mit dem Komplettsystem von Sulu sowie dessen eigener Security-Komponente verzahnt und somit für eine anderweitige Nutzung nicht wirklich geeignet.
• Das Kunstmaan CMS besteht aus einer Reihe von Bundles, darunter auch das KunstmaanUserManagementBundle. Das hängt auch nicht vom kompletten CMS ab, wohl aber vom KunstmaanAdminBundle und KunstmaanAdminListBundle. Das war also durchaus eine Option, hätte aber nur im Verbund mit dem Kunstmaan-basierten Admin-Interface - alternativ zum EasyAdminBundle - Sinn gemacht.
• Das Sonata-Projekt bietet ebenfalls mehrere Bundles an, darunter einige Dinge, die es in Zikula ebenfalls lange gab, wie etwa ein Blocksystem. Das SonataUserBundle wäre auch hier verbunden mit dem SonataAdminBundle und darüber mit einer Hand voll weiterer Dependencies aus dem Sonata-Ökosystem. Das war ebenfalls erst einmal eine Option, wenn auch eine eher schwergewichtige.
• Früher war das FOSUserBundle lange Zeit das Mittel der Wahl, wenn es um die Integration von Benutzerfunktionen in Symfony geht. Die Entwicklung ist allerdings mittlerweile heruntergefahren worden und es wird daher für neue Projekte nicht mehr empfohlen. Statt dessen zeigt die Readme teilweise auf andere Bundles für spezifische Funktionen, wie etwa zur Verifikation von E-Mail-Adressen und dem Zurücksetzen von Kennwörtern. Dieser Ansatz, die ganze Basis weiter in Zikula selbst zu pflegen und nur zwei drei spezielle Funktionen auszulagern, erschien uns dann wiederum zu kleinteilig.

Nucleos to the rescue

Glücklicherweise sind wir dann aber noch auf weitere, sehr vielversprechende Bundles aufmerksam geworden:

• Das NucleosUserBundle ist aus dem FOSUserBundle entstanden. Es erlaubt eine datenbankgestützte Verwaltung von Benutzern und bietet grundlegende Funktionen wie Login via Benutzername und/oder E-Mail-Adresse, Logout, Aktivieren und Deaktivieren von Nutzern, das Zurücksetzen von Kennwörtern oder das Versenden von Mails. Des Weiteren integriert sich das Bundle mit dem Rollenkonzept von Symfony. Auch Benutzergruppen können verwendet werden, um eine wiederkehrende Menge von Rollen einfacher zu handhaben - aus Performancegründen wird jedoch empfohlen eher auf die Vererbung von Rollen zu setzen. Schließlich bietet das Bundle auch die Möglichkeit eine Funktion freizuschalten, mit der sich Accounts löschen lassen.
• Das NucleosProfileBundle setzt zusätzlich noch Funktionen zur Profilverwaltung, Registrierung und Freigabe neuer Nutzer sowie zur Veränderung der Mailadresse obendrauf.

Beide Bundles sind technisch auf aktuellem Stand und können mit Symfony 5.4 oder auch 6.x benutzt werden. Sie bilden ein flexibel erweiterbares, leichtgewichtiges Grundgerüst. Gleichzeitig decken sie zusammen betrachtet in Sachen Funktionsumfang auch schon eine Menge Funktionen ab und bringen dennoch keine großen weiteren Abhängigkeiten mit. Dank zahlreicher Events lassen sie sich auch mit anderen Bausteinen verknüpfen.

Es gibt übrigens auch ein NucleosUserAdminBundle, das aber gegenwärtig noch eine Abhängigkeit zum SonataAdminBundle mitbringt. Es gibt grundsätzlich Bestrebungen, auch andere Admin-Backends zu unterstützen. Für den Anfang reicht es aber wohl aus, erst einmal eine kleine Einbindung in das Admin-Dashboard von Zikula vorzunehmen.

Alles in allem scheint uns das ein guter Ausgangspunkt zu sein, die oben beschriebenen alten Bundles zu verschlanken und teilweise abzulösen.

Ausblick

Nachdem wir nun eine Idee entwickelt und den Scope einer Integration der Nucleos-Bundles in Zikula (und EAB) einigermaßen umrissen haben, werden wir hier versuchen im nächsten Schritt den Fuß in die Tür zu kriegen. Das wird am Anfang etwas holprig werden, weil die Ablösung etablierter Konzepte (wie etwa des bisherigen Berechtigungssystems) entsprechende Kreise zieht, aber wir sind optimistisch, dass die Aufwände insgesamt überschaubar bleiben.

Spezielle Aspekte, wie etwa die dynamischen Felder für das Profilmanagement, werden entsprechend hinten angestellt. Hier sehen wir übrigens perspektivisch eine Integration mit dem relativ neuen DynamicFormBundle, das aber noch ins Monorepo überführt werden muss.