Alumni-Benutzergruppe

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Aufgabenstellung

Für ehemalige Studenten und Mitarbeiter der Fachhochschule soll die Semantik (Rollenkonzept) für eine neue Benutzergruppe, ALUMNI, im eStudy Framework implementiert werden. Das eStudy-Framework erlaubt es, beliebige Benutzergruppen anzulegen, allerdings haben diese keine besondere Semantik. Das Rollenkonzept der Benutzergruppe soll folgende Eigenschaften aufweisen:


  • Mitglieder dieser Gruppe werden von der Löschautomation (derzeit 180 Tage) verschont.
  • Mitglieder dieser Gruppe dürfen Ihre Mailadresse ändern.
  • Mitglieder dieser Gruppe haben Studentenstatus.
  • Mitglieder dieser Gruppe erhalten ein eigenes Icon.


Zur möglichen Vorgehensweise werden keine näheren Angaben gemacht.

Ist-Zustand

Im Rechtemanagement des eStudy-Frameworks sind verschiedene Konzepte ausgeformt, durch die den Benutzern statische und temporäre Rechte zugewiesen werden können.

Benutzergruppen

Zum Zeitpunkt der Bearbeitung sind in der Tabelle usergroups vier Benutzergruppen angelegt: Die Gruppe der Administratoren Admin, der Studenten Student, der Dozenten Dozent und einen Gruppe für Angehörige der Hochschulverwaltung Sekretariat. Jede Benutzergruppe hat eine fortlaufende ID-Nummer als primary key, über die jeder Benutzer in der Tabelle user genau einer Benutzergruppe zugeordnet ist. Die jeweilige Benutzergruppen-ID wird bei der Anmeldung in der Session-Variablen usergroup abgelegt und dient fortan der Überprüfung von Zugriffsrechten innerhalb des eStudy-Portals.

Rollenkonzepte

Zusätzlich gibt es ein Rollenkonzept, in dem einem Benutzer eine oder mehrere Rollen in Abhängigkeit weiterer Umgebungsparamter zugewiesen werden. So ist die Rolle eines Tutors, also eines Studenten mit erweiterten Rechten in Bezug auf einen bestimmten Kurs, über die Tabelle assistent implementiert worden, welche Benutzer-IDs mit Kurs-IDs verknüpft. Desweiteren gibt es ein Rollenset für das Planspielmodul, das in der Tabelle roles angelegt ist. Hieraus können Benutzer in Abhängigkeit der eingestellten Planspielphase eine Rolle wählen, in der sie unterschiedliche Funktionen wahrnehmen können.

Prüfung der Zugriffsrechte

In den PHP-Modulen werden an zahlreichen Stellen die Gruppenzugehörigkeit des angemeldeten Benutzers oder einer ihm zugewiesenen Rolle überprüft. Auf diese Weise werden jedem Benutzer verschiedene Funktionen angeboten oder deren Ausführung unterbunden. Dies geschieht auf zweierlei Weise: Entweder werden dem Benutzer auf Grund seiner Gruppenzugehörigkeit zusätzliche Links zu Funktionen in einer HTML-Seite angeboten oder eine gewählte Funktion wird bei unzureichenden Rechten mit einem Hinweis an den Benutzer vorzeitig beendet.

Realisierung der Prüfungen

Zur Überprüfung der Benutzergruppe wird die ID aus der Session-Variablen usergroup herangezogen, welche mit deklarativen Konstanten verglichen werden. Die Rolleneigenschaft Tutor wird überprüft, indem das Vorhandensein der Kombination aus Benutzer-ID und der Kurs-ID des jeweils aktuellen Kurskontextes in der Tabelle assistent abgefragt wird.


Quellenanalyse

Die Quellenanalyse beschränkt sich im Folgenden auf die Identifizierung der Code-Passagen, die zur Umsetzung der geforderten Eigenschaften verändert werden müssen.

Studentenstatus

Der Studenstatus kann derzeit nur über die Zugehörigkeit zur Benutzergruppe Student geprüft werden. Dies muss an allen Code-Stellen der PHP-Module geschehen, die den Zugriff von Mitgliedern dieser Gruppe explizit erlauben oder verbieten. Da die Mitglieder der Benutzergruppe ALUMNI den Studentenstatus haben sollen liegt es nahe, eine ähnliche Überprüfung wie bei der Rollen Tutor zu implementieren und die Benutzern ansonsten als Mitglieder der Gruppe Student zu führen. Dazu könnte man eine neue Tabelle tutor anlegen, in der die Benutzer-IDs der Alumni abgelegt werden. In der Aufgabenstellung ist jedoch explizit eine zusätzliche Benutzergruppe gefordert.

Mailadresse ändern

Damit ein Alumnus seine Email-Adresse ändern kann, muss eine Prüfung in EditUser::setUserData() erweitert werden und das zughörige Edit-Feld in EditUser::editUserDialog() im Falle des Aufrufs durch einen Alumnus mit non-fixed bzw. '0' als siebtem Parameter der Funktion UserTools::getEditFormField() erzeugt werden.

Löschautomation

Damit ein Benutzer nach einer bestimmten Dauer seit seinem letzten Login nicht gelöscht wird, muss im Falle des Rollenkonzeptes nur einen Klausel in der SQL-Abfrage in UserAutomation::dailyWork() hinzugefügt werden. Wenn eine neue Benutzergruppe für die Alumni angelegt wird, muss gar nichts verändert werden, da der Query auf Mitglieder der Gruppen Student und Sekretariat beschränkt ist.

Alumnus-Icon

Um den Alumnistatus mit einem separaten Icon zu illustrieren, muss die Funktion Output::getUsergroupPicture() erweitert werden.

Implementierung der Hausübung

Vorbemerkung

Die Analyse der PHP-Quellen zeigte auf, dass die bisherige Prüfung der Rechte über die Benutzergruppenzuordnung schon mit den bestehenden vier Gruppen ein deutliches Defizit in punkto Les- und Wartbarkeit aufweist. Die Prüfungen verteilen sich auf eine Vielzahl von Dateien und sind meist als Oder-Verknüpfungen von Vergleichen mehrerer Gruppen-Konstante mit der Session-Variable usergroup implementiert. Das Hinzufügen einer zusätzlichen Gruppe verschärft diese Situation weiter. Andererseits erhöht auch das Hinzufügen eines weiteren singulären Rollenkonzeptes, wie das der Rolle Tutor, die Komplexität und erfordert neue Funktionen in den Administrationswerkzeugen. Eine Lösung, die diesen Kritikpunkten gerecht würde, besteht nur in einem Redesign des Rechtemanagements, was mit dem zur Verfügung stehenden Budget aber nicht realisierbar war.

Ansatz

Um ein zukünftiges Redesign nicht unnötig zu erschweren, wurde für die Hausübung der Versuch unternommen, eine neue Benutzergruppe hinzuzufügen und alle relevanten Prüfungen um einen zusätzlichen Vergleich zu erweitern. Dabei sollten durch Refactoring-Maßnahmen, wie dem Ersetzen von Magic Numbers durch Konstanten, die Form der Prüfungen soweit vereinheitlicht werden, dass zukünftige Ersetzungen zu einem Großteil automatisiert werden können.

Die Umsetzung gliederte sich dabei in folgende Punkte:


  • Anlegen der Benutzergruppe ALUMNI in der Tabelle usergroups
  • Anlegen einer deklarativen Konstante für die ID der Benutzergruppe (ALUMNI)
  • Automatisiertes Erweitern der Prüfungen durch Perl-Skripte durch ein Ersetzen von Vergleichen wie
$_SESSION["usergroup"] == STUDENT   ->  (($_SESSION["usergroup"] == STUDENT) || ($_SESSION["usergroup"] == ALUMNI))
  • Anpassung der Code-Stellen für das Ändern der Email-Adresse und die Erweiterung um ein neues Benutzer-Icon


Auf eine Änderung der Löschautomation konnte durch die Einführung einer neuen Benutzergruppe verzichtet werden, da nur Mitglieder der Gruppen Student und Sekretariat betroffen sind. Ein neues Icon wurde aus Zeitgründen nicht entworfen, sondern zu Testzwecken eines aus einem anderen Portal-Style verwendet.

Einschränkung

Anschließend sollten die Stellen für Refactoring-Maßnahmen dadurch gefunden werden, dass alle Fundstellen des Keywords usergroup, die nicht vorher schon Ziel einer Ersetzung waren, auf Konformität überprüft werden. Dieses Vorhaben stellte sich aber schnell als nicht mehr überschaubar dar, weil häufig Session-Variablen in andere Variablen umgeladen und darin weiter verwendet wurden.

Nachfolgende Tests und Debug-Sessions erbrachten innerhalb des gesetzten Zeitrahmens keine Lösung, die für mehr als ein Aufzeigen der Schwachstellen der bisherigen Implementierung ausgereicht hätte.


Ansätze für ein Redesign des Rechtemanagements

Ausbau des Rollenkonzeptes

Zugriffs- und Ausführungsrechte sollten komplett in Rollen abgebildet werden. Die Rechte einer Benutzergruppe definieren sich dann durch ein Set von Rollen. Die nachträgliche Anpassung von Rechten einzelner Benutzergruppen ist dadurch mit geringem Aufwand verbunden, ohne die Les- und Wartbarkeit zu beeinträchtigen.

Kombination von Rollen und Benutzergruppen

IDs von Rollen und Benutzergruppen sollten miteinander kombinierbar sein. Dazu bieten sich beispielsweise Zweierpotenzen an, die in Form von Bitfeldern zu Rollen kombiniert und mit Hilfe von Bit-Operatoren (|, &) verglichen und maskiert werden können. Auf diese Weise sind übersichtliche Vergleichsoperationen möglich bei denen die Operanden leicht angepasst werden können. Auch die Zuweisung von Benutzern zu mehreren Benutzergruppen wird dadurch ohne Redundanzen in der Datenhaltung möglich.


RGD 2008-02-29