Zeitalter3 – Browsergames Entwicklerblog

Die Benutzerverwaltung ist fertig. Es ist seltsam, aber jedes von mir geplante System zur Benutzerverwaltung wird automatisch wesentlich komplexer, als ursprünglich angenommen. Warnung: es folgt Tech-Talk. Nicht-Programmierer dürfen den Artikel überspringen.

Grundsätzlich ist Benutzerverwaltung eine einfache Sache: ein Benutzer gibt seinen Nutzernamen und das Passwort ein. Anschließend ist er eingeloggt, bis er sich ausloggt oder seine Session abläuft. Hinter den Kulissen läuft jedoch mehr ab. Sehr viel mehr. Da das Framework, welches bei Zeitalter3 zum Einsatz kommt, auch für andere Projekte eingesetzt werden soll, wurde es entsprechend komplex. Fragen wie “Was brauche ich wirklich?” bis hin zu “Was sind konkrete Anwendungsfälle des Frameworks?” mussten zunächst einmal geklärt werden. Mit folgendem Ergebnis:

• Das Framework soll für alle Arten interaktiver Webapplikationen geeignet sein.
• Angaben über Benutzer sollen pro Projekt einfach zu konfigurieren sein.
• Das Benutzersystem soll über ein Rechtemanagement verfügen.
• Rechte sollen sich in Rollen bündeln lassen.
• Sicherheitskonzepte sollen transparent im Benutzersystem integriert sein.

Im Detail bedeutet das:

Das Framework soll nicht nur auf Spiele ausgelegt sein, sondern auf alle Arten webgestützte Mehrbenutzerapplikationen. Dies schließt zum Beispiel Communities, eLearning-Systeme und dergleichen mit ein. Daumenregel: alle Systeme mit vielen Nutzern gleichzeitig.

Bei verschiedenen Projekten sind die Daten, die ein Benutzer über sich angeben kann/muss unterschiedlich. Nutzerangaben sollen einfach pro Projekt definiert werden können. Darüber hinaus sollen für jeden Benutzer Rechte für bestimmte Aktionen definiert werden können. Eine Rolle definiert ein festgelegtes Set von Rechten, die ein Benutzer haben kann.

Und schließlich: Sicherheitskonzepte in jeder Komponente müssen für die möglichst manipulationssichere Funktionsweise sorgen – völlig transparent, ohne dass sie der Anwender des Framework je zu Gesicht bekommen muss.

Diese schlappen 5 Punkte kosteten mich etwas über ein Woche. Folgende Komponenten entstanden in dieser Zeit:

Grundlage von allem ist der Session Handler. Dieser verwaltet eine Session, nimmt eventuell vorhandene Session-Cookies des Benutzers auf, prüft Session-IDs gegen die IP und einen Zufallsschlüssel und startet vorhandene und verifizierte Sessions. Die Klasse kümmert sich ebenso um das Auslesen und Speichern von Session-Variablen. Laufende Sessions werden in der Datenbank und nicht als Datei auf dem Server abgelegt.

Von der Seite des Frameworks gibt es eine User-Klasse. Diese verwaltet für die Applikation alles, was mit den Benutzern zu tun hat: Ein- und Ausloggen, Verifizieren des Benutzers aus der Session, Auslesen, Ändern und Speichern von Benutzerdaten, Rechten und Rollen etc. Für Letzteres greift die Klasse ihrerseits auf zwei Helferklassen zurück: eine für die Rechte- und Rollenverwaltung und eine für die Benutzerdaten. Diese sind vor der Applikation im Grunde verborgen, nur die User-Klasse greift darauf zu. Alle Funktionalitäten haben in den jeweiligen Klassen Sicherheitsmaßnahmen, Validitätsprüfungen und fangen eventuell auftretende Fehler ab.

Alles in allem ziemlich “Enterprisey”, wie es ein Entwicklerkollege bezeichnete. Wie aber bereits geschildert soll das Framework in der Lage sein, möglichst viele Aspekte von webbasierten Mehrbenutzersystemen abzudecken. In diesem Fall sind Rechte und Rollen für ein browserbasiertes Spiel eher ungewöhnlich, für Community- und eLearning-Systeme allerdings nicht. Durch die Konfiguration in dem zu dem Framework gehörende Entwickler-Backend wird es möglich sein, die Leistung der Benutzerverwaltung auf die Bedürfnisse der Applikation anzupassen.

Als nächstes ist endlich der Eventhandler dran und dann folgen langsam aber sicher die ersten Prototypen und begleitenden Anwendungen.