sf_register für TYPO3

Warum TYPO3 ohne Registrierungs-Extension kein Nutzer-Portal werden kann

Der TYPO3-Core kennt fe_users als Datenbanktabelle und eine Standard-Login-Maske, aber keinen Weg, wie sich ein neuer Nutzer selbstständig registriert oder seine Daten pflegt; das Zurücksetzen des Passworts bringt die Login-Maske felogin schon mit. Jede Website, die mehr ist als ein reines Publikationsorgan, braucht diese Funktion: Communities, Mitgliederbereiche, geschützte Downloads, personalisierte Newsletter, kostenpflichtige Inhalte. sf_register schließt diese Lücke mit einem schlanken Extbase-basierten Ansatz, der sich genau auf Registrierung, Profil und Passwort-Änderung konzentriert und bewusst auf Features verzichtet, die in der Komplettlösung femanager mitgeliefert werden.

Typische Einsatzszenarien

Ein Fachverlag mit 3.500 Abonnenten bietet Online-Zugriff auf Fachartikel und Studien. Jeder Abonnent erhält ein Konto, das an seine Abo-Nummer gekoppelt ist. sf_register übernimmt die initiale Registrierung mit Double-Opt-In-Bestätigung per E-Mail, legt den Nutzer automatisch in der Gruppe “Abonnent” an und aktiviert den Zugriff auf die geschützten Seiten. Wenn das Abo abläuft, entfernt ein TYPO3-Scheduler-Task die Gruppenzugehörigkeit, ohne den Account zu löschen, sodass der Nutzer nach einer Vertragsverlängerung wieder Zugriff hat.

Ein zweiter Fall ist ein Fachverband mit rund 7.000 Mitgliedsunternehmen, der ein geschütztes Mitgliederportal mit Tagungsdokumentation, Normenvorschauen und Diskussionsforen betreibt. sf_register erlaubt die Erstregistrierung, löst aber gleichzeitig einen manuellen Freischaltprozess aus, bei dem ein Verbandsmitarbeiter die Zugehörigkeit zur Mitgliedsfirma prüft, bevor der Account aktiviert wird. Der Workflow kombiniert Double-Opt-In mit einer Admin-Genehmigung; beides bringt sf_register als Einstellung mit.

Der dritte Kontext sind öffentliche Einrichtungen wie Volkshochschulen oder Stadtbibliotheken, die Kursanmeldungen oder Katalog-Merklisten an einen Nutzer-Account koppeln wollen. Hier zählt vor allem die einfache Einrichtung und die geringe Komplexität: Die Extension muss keine zwanzig Profilfelder verwalten, sondern Name, E-Mail, Passwort und eine Bibliotheks-Kundennummer, mehr braucht es nicht, und sf_register liefert genau das.

Technische Architektur: Extbase, TCA und Events

sf_register ist sauber nach dem Extbase-Modell aufgebaut. Ein eigener FrontendUser-Model erweitert den Core-User, Controller-Actions behandeln Create, Edit, Confirm, Delete und das Ändern des Passworts, und das Templating läuft über Fluid-Layouts. Die Pflichtfelder werden über TypoScript-Validatoren gesteuert und lassen sich dort je Feld erweitern. Custom-Felder wie Firma, Position oder Mitgliedsnummer benötigen einen kleinen TCA-Eintrag, eine Model-Property und eine Ergänzung im Fluid-Template, was Entwicklern eine klare Struktur gibt, aber auch bedeutet, dass jede Anpassung Code-Arbeit ist.

Der Double-Opt-In-Prozess basiert auf Hash-basierten Confirmation-Links, deren Hash die Extension beim Klick aus Aktion und Benutzer-ID neu berechnet, statt ihn zu speichern; danach setzt sie den disable-Flag zurück. E-Mails versendet die Extension über das TYPO3-Mailer-Interface, das intern auf Symfony Mailer aufsetzt, wodurch auch komplexere Setups mit SMTP-Proxies oder Mailing-Services wie SendGrid problemlos funktionieren. Passwort-Hashing nutzt die TYPO3-eigenen Password-Hash-Services und ist damit automatisch mit jedem Core-Update synchron.

Häufige Probleme und Lösungen

Das erste Problem sind Spam-Registrierungen. Jede öffentliche Registrierungs-Seite zieht Bots an, die automatisiert Accounts anlegen, um über das Passwort-Reset-Formular E-Mails an Dritte zu senden oder Trackback-Spam in Community-Features zu platzieren. Eine saubere Lösung kombiniert sf_register mit einer CAPTCHA-Extension wie sr_freecap oder einem Honeypot-Feld, ergänzt um ein Rate-Limiting auf der Registrierungs-URL im Reverse-Proxy.

Das zweite Problem betrifft die E-Mail-Zustellung. Bestätigungsmails landen regelmäßig im Spam-Ordner, wenn der TYPO3-Server ohne SPF-Eintrag, DKIM-Signatur oder Reverse-DNS betrieben wird. Die Extension versendet die Mail korrekt, aber der Empfänger-Server verwirft sie stumm. Die Lösung liegt nicht in sf_register, sondern in der Mail-Infrastruktur: Ein dedizierter Sendedienst mit etablierter Domain-Reputation senkt die Bounce-Rate spürbar.

Das dritte Thema ist Datenschutz. Registrierte Nutzer müssen jederzeit ihre Daten einsehen, korrigieren und löschen können, und die Löschung muss tatsächlich kaskadierend greifen, also auch Downloads und andere verknüpfte Datensätze umfassen; Bestellungen dürfen bleiben, solange Aufbewahrungspflichten gelten. sf_register liefert Edit-Formulare und ein Plugin zum Löschen des eigenen Kontos, aber keinen Löschprozess für abhängige Daten. Dieser muss als eigener Workflow ergänzt werden, bei dem die Account-Löschung entweder sofort oder nach einer Übergangsfrist die abhängigen Daten anonymisiert.

Ein viertes typisches Problem betrifft Passwort-Richtlinien. sf_register akzeptiert per Default auch schwache Passwörter, und Nutzer neigen dazu, kurze oder triviale Kombinationen zu verwenden. Die TYPO3-Password-Policies wendet sf_register nicht an; Mindestlänge und gesperrte Wörter prüfen seine eigenen Validatoren, die sich per TypoScript um Regeln wie Zeichenklassen ergänzen lassen, ohne dass die Extension selbst angepasst werden muss.

Migration und Versions-Kompatibilität

sf_register gibt es mit einer eigenen Reihe je TYPO3-Version, aktuell 13.2.4 für v13 und 14.0.2 für v14, und es hat in der Community den Ruf einer soliden, wartbaren Alternative zu femanager. Die Unterstützung neuer Versionen ist in der Regel zeitnah nach Release eines neuen TYPO3-Cores verfügbar, erfordert bei Custom-Extensions jedoch ein Review der Extbase-Annotation-Syntax, die zwischen den Versionen kleinere Anpassungen gesehen hat.

Wer von femanager auf sf_register migriert, spart Komplexität, muss aber prüfen, welche Features tatsächlich verwendet wurden: femanager bietet zusätzlich eine Backend-Moderation out-of-the-box, die sf_register nur über zusätzlichen Code nachbaut; Admin-Bestätigung und Profilbild-Upload bringen beide mit. Umgekehrt ist der Migrationspfad von sf_register zu femanager einfacher, weil die Datenstruktur weitgehend kompatibel ist. Gosign übernimmt solche Migrationen inklusive Mail-Template-Portierung und Abgleich der Benutzergruppen, sodass bestehende Nutzer sich auch nach dem Wechsel problemlos anmelden.

Wer ein Projekt neu aufsetzt, sollte vor der Auswahl die realen Anforderungen des Portals durchdenken: Braucht der Betreiber eine Backend-Moderation oder komplexe Rollen-Zuordnungen? Dann ist femanager der schnellere Weg. Genügt eine schlanke Self-Service-Registrierung mit sauberem Extbase-Fundament und wenig Overhead? Dann ist sf_register die passende Wahl. Die Entscheidung fällt selten knapp aus, sobald man den Katalog an benötigten Funktionen einmal durchgegangen ist, und sie spart später erheblichen Nachbau-Aufwand.