Berechtigungen in Lufox nachvollziehbar organisieren

Eine Rolle wie „Support“ klingt eindeutig, sagt technisch aber noch wenig aus. Darf diese Person Meldungen ansehen, andere Spieler versetzen, Gegenstände ersetzen oder Einstellungen verändern? Werden alle diese Möglichkeiten unter einem großen Sammelrecht vergeben, ist später kaum nachvollziehbar, welche Befugnis für eine konkrete Aufgabe wirklich benötigt wurde. Eine gute Rechteplanung beginnt deshalb mit Handlungen. Rollen fassen erst danach die passenden Handlungen zu einem verständlichen Arbeitsbereich zusammen.

Bei Lufox ist dieser Blick besonders sinnvoll, weil sichtbare Menüs, Befehle und räumliche Zugänge zusammenwirken können. Im vorhandenen Quelltext prüfen Wechselportale vor dem Auslösen ein Recht, das aus dem Präfix lufox.wechsel. und dem jeweiligen Ziel gebildet wird. Das ist ein konkreter technischer Prüfpunkt. Welche Gruppen dieses Recht im laufenden Betrieb besitzen, lässt sich daraus nicht ableiten. Implementierte Prüfung und tatsächlich vergebene Berechtigungen müssen getrennt untersucht werden.

Von Aufgaben zu einzelnen Befugnissen gelangen

Für jede Teamaufgabe wird zunächst eine normale Situation beschrieben. Eine Person soll eine gemeldete Störung nachvollziehen können. Dafür benötigt sie möglicherweise Einsicht in den Meldungstext und den Bearbeitungsstatus. Sie braucht nicht automatisch die Möglichkeit, Guthaben zu ändern oder Welten zu löschen. Die benötigte Befugnis ergibt sich aus der Handlung und ihrem Zweck, nicht aus einem möglichst mächtigen Rangnamen.

Anschließend werden lesende und verändernde Aktionen getrennt. Eine Übersicht anzusehen ist etwas anderes, als deren Einstellungen zu speichern. Ebenso unterscheidet sich das Prüfen eines Spielerzustands vom Ersetzen dieses Zustands. Diese Trennung erleichtert Zusammenarbeit: Mehr Personen können bei der Diagnose helfen, während folgenreiche Änderungen einem kleineren, dafür zuständigen Kreis vorbehalten bleiben.

Die Beschreibung sollte auch den Gegenstand der Handlung nennen. „Verwalten“ ist als Recht zu unbestimmt. „Eigene Meldungen ansehen“, „offene Meldungen bearbeiten“ und „Meldungen endgültig entfernen“ haben unterschiedliche Wirkungen. Nicht jedes Projekt braucht für jede denkbare Variante einen eigenen technischen Knoten. Die fachliche Unterscheidung hilft jedoch zu entscheiden, welche Grenzen tatsächlich wichtig sind und welche bewusst gemeinsam behandelt werden können.

Rollen einfach und begründbar halten

Eine überschaubare Rollenstruktur ist leichter zu prüfen als eine lange Kette historisch gewachsener Vererbungen. Für einen Entwurf könnten normale Spieler, unterstützende Teammitglieder und technische Verwaltung unterschieden werden. Jede Rolle erhält eine kurze Aufgabenbeschreibung. Zusätzliche kosmetische Ränge werden davon getrennt betrachtet, damit eine sichtbare Auszeichnung nicht versehentlich administrative Befugnisse mitführt.

Vererbung kann Wiederholung verringern, sollte aber verständlich bleiben. Wenn eine Rolle mehrere andere Rollen übernimmt, muss ihre effektive Wirkung noch nachvollziehbar sein. Besonders Ausnahmen verdienen Aufmerksamkeit. Eine einzelne direkt am Konto vergebene Freigabe kann lange bestehen bleiben, obwohl die Person ihre Teamrolle bereits abgegeben hat. Deshalb werden persönliche Sonderrechte mit einem Anlass und gegebenenfalls einem vorgesehenen Ende dokumentiert.

Auch zeitlich begrenzte Unterstützung braucht einen klaren Abschluss. Wird jemand nur für einen Veranstaltungstag bei der Betreuung eingesetzt, sollten die erforderlichen Rechte anschließend wieder entfallen. Der genaue Mechanismus hängt vom verwendeten Rechtewerkzeug ab. Unabhängig davon braucht der Ablauf eine Prüfung nach dem Entzug. Eine entfernte Gruppenmitgliedschaft ist erst dann ausreichend, wenn keine andere Zuweisung dieselbe Befugnis weiterhin gewährt.

Sichtbarkeit und Ausführung getrennt absichern

Ein Menü kann eine nicht erlaubte Aktion ausblenden, damit die Oberfläche übersichtlich bleibt. Diese Ausblendung ist jedoch keine ausreichende Prüfung der Handlung. Ein Befehl, ein anderer Menüweg oder ein später eintreffender Klick könnte denselben Vorgang weiterhin erreichen. Deshalb wird die Berechtigung an der Stelle geprüft, an der die fachliche Aktion ausgeführt werden soll. Die Darstellung nutzt denselben Grundsatz zusätzlich für verständliche Bedienung.

Das gilt besonders für länger geöffnete Fenster. Eine Person kann ein Menü öffnen, während sie berechtigt ist, und ihre Rolle kurz darauf verlieren. Ein bereits sichtbarer Knopf darf dann nicht als dauerhafte Erlaubnis gelten. Vor der tatsächlichen Änderung wird der aktuelle Zustand erneut betrachtet. So bleibt die Entscheidung an die gegenwärtige Berechtigung gebunden und nicht an einen früheren Bildschirmaufbau.

Im Portalbeispiel von Lufox erfolgt die Prüfung unmittelbar vor dem zentralen Wechselaufruf. Für die Gesamtprüfung werden zusätzlich andere mögliche Wechselwege betrachtet. Ein korrekt geprüftes Portal sagt noch nichts über einen separaten Befehl oder einen Menüknopf aus. Die Rechteübersicht listet deshalb alle Einstiege zu derselben Handlung auf. Erst wenn sie übereinstimmen, ist das Verhalten für Spieler verlässlich.

Standardrechte bewusst prüfen

Berechtigungssysteme besitzen häufig Standardverhalten und Vererbungsregeln. Plugin-Metadaten können festlegen, wie definierte Rechte standardmäßig behandelt werden. Die Paper-Dokumentation beschreibt entsprechende Angaben in plugin.yml. Für das Projekt folgt daraus, dass nicht ausschließlich ausdrücklich vergebene Rechte geprüft werden dürfen. Auch der Ausgangszustand eines frischen Kontos und mögliche Operatorrechte beeinflussen das Ergebnis. Paper: Plugin-Metadaten

Ein Test mit einem besonders mächtigen Administrationskonto ist deshalb für gewöhnliche Spielerrechte ungeeignet. Dieses Konto kann über andere Wege bereits weitreichende Freigaben besitzen. Eine scheinbar erfolgreiche Aktion zeigt dann nur, dass das Administrationskonto sie ausführen konnte. Für die eigentliche Prüfung werden bewusst gewöhnliche Testkonten mit dokumentierten Rollen verwendet. Ihre Ausgangslage bleibt klein genug, um unerwartete Ergebnisse zu erklären.

Auch Rechte mit ähnlichen Namen werden nicht automatisch gleichgesetzt. Ein serverseitiges Grundrecht und ein eigenes Pluginrecht können unterschiedliche Prüfstellen bedienen. Die offizielle Paper-Rechteübersicht hilft bei den von Paper bereitgestellten Knoten. Für eigene Lufox-Funktionen bleibt dagegen der aktuelle Quelltext maßgeblich. Eine vollständige Prüfung verbindet beide Ebenen und vermeidet Vermutungen allein anhand von Namen. Paper: Permissions

Eine konkrete Rechteprüfung entwerfen

Als Arbeitsbeispiel wird ein zusätzlicher Abenteuerbereich angenommen. Normale Spieler sollen ihn zunächst nicht betreten, freigeschaltete Spieler schon. Das Ziel erhält im Entwurf einen eindeutigen internen Namen. Das dazu passende Wechselrecht wird nur der vorgesehenen Freischaltung zugeordnet. Die tatsächliche Benennung und aktive Vergabe müssen vor einer Umsetzung am vorhandenen Projekt geprüft werden.

Der erste Test beginnt mit einem gewöhnlichen Konto ohne Freischaltung. Es versucht den Zugang über Portal, Menü und gegebenenfalls Befehl. Alle Wege müssen dieselbe fachliche Entscheidung treffen. Die Rückmeldung darf sich an die jeweilige Oberfläche anpassen, soll aber denselben Grund erklären. Danach erhält das Konto die Freischaltung und wiederholt die Wege. Nun muss das Ziel tatsächlich erreichbar sein, sofern keine andere Voraussetzung fehlt.

Im dritten Schritt wird die Freischaltung bei geöffnetem Menü entzogen. Der alte Knopf wird anschließend betätigt. Erwartet wird eine erneute Ablehnung mit verständlichem Hinweis. Abschließend erfolgt eine Abmeldung und erneute Anmeldung. Dadurch wird geprüft, ob ein zwischengespeicherter Zustand fälschlich weiterwirkt. Der Ablauf bewertet nicht nur die positive Freigabe, sondern ebenso den zuverlässigen Entzug.

Ablehnungen verständlich formulieren

Eine fehlende Berechtigung ist aus Spielersicht zunächst eine unterbrochene Absicht. Die Rückmeldung sollte deshalb erklären, welche Handlung nicht möglich ist und ob eine Alternative besteht. Bei einem Abenteuerzugang kann ein Hinweis auf eine noch offene Voraussetzung hilfreich sein. Bei einer Verwaltungsfunktion genügt möglicherweise die Aussage, dass sie der zuständigen Teamrolle vorbehalten ist. Interne Knotennamen müssen nicht jede gewöhnliche Ablehnung begleiten.

Gleichzeitig darf die Oberfläche keine falschen Gründe erfinden. Ein nicht erreichbares Ziel ist etwas anderes als eine fehlende Freigabe. Werden beide Fälle mit derselben Nachricht beantwortet, suchen Spieler und Team an der falschen Stelle. Die technische Verarbeitung unterscheidet daher Berechtigung, Verfügbarkeit und fachliche Voraussetzungen. Eine Quest kann beispielsweise noch offen sein, obwohl das grundsätzliche Nutzungsrecht vorhanden ist.

Für die interne Diagnose können genauere Angaben nützlich sein. Sie sollten den geprüften Handlungstyp und das Ergebnis nachvollziehbar machen, ohne unnötige persönliche Daten zu verbreiten. Ein kurzer reproduzierbarer Fall ist meist hilfreicher als ein großer ungeordneter Protokollauszug. Wer meldet, welcher Zugang mit welcher Testrolle scheiterte, liefert bereits eine gute Grundlage für die Untersuchung.

Änderungen als kleine überprüfbare Pakete durchführen

Eine Rechteänderung bekommt einen konkreten Anlass und eine erwartete Wirkung. Beispielsweise soll die unterstützende Teamrolle künftig offene Meldungen markieren können, ohne andere Verwaltungsfunktionen zu erhalten. Dann werden genau diese positive Handlung und einige benachbarte verbotene Handlungen geprüft. Ein bloßer erfolgreicher Klick auf die neue Funktion reicht nicht, wenn dafür versehentlich ein großes Sammelrecht vergeben wurde.

Vor der Änderung wird der bisherige Zustand dokumentiert oder exportiert, soweit das eingesetzte Werkzeug dies unterstützt. Danach folgt die begrenzte Anpassung und der Test mit dem passenden Konto. Wenn das Ergebnis nicht stimmt, kann die Änderung gezielt zurückgenommen werden. Mehrere gleichzeitig umgebaute Rollenhierarchien wären wesentlich schwerer zu beurteilen. Kleine Pakete machen auch die spätere Erklärung gegenüber dem Team einfacher.

Die Prüfung betrifft zudem vorhandene Arbeitsabläufe. Ein entzogener Knoten kann eine Funktion betreffen, die an anderer Stelle noch gebraucht wird. Deshalb wird bei größeren Bereinigungen nicht nur die neue Zielrolle getestet, sondern auch eine typische Aufgabe benachbarter Rollen. So entstehen weniger Überraschungen, wenn eine scheinbar überflüssige Vererbung tatsächlich einen alltäglichen Zugang vermittelt hatte.

Regelmäßige Überprüfung ohne Verwaltungsballast

Eine gelegentliche Rechteprüfung kann kurz bleiben, wenn die Struktur vorher übersichtlich ist. Betrachtet werden aktive Teamrollen, persönliche Ausnahmen und besonders weitreichende Befugnisse. Für jede Ausnahme wird gefragt, ob ihr Anlass noch besteht. Alte Hilfsrechte aus Testphasen werden entfernt, sofern sie keinen aktuellen Zweck mehr erfüllen. Die Prüfung endet mit tatsächlichen Handlungstests für die wichtigsten Grenzen.

Neue Funktionen erweitern diese Übersicht von Anfang an. Eine zusätzliche Verwaltungsseite benötigt nicht automatisch dieselbe Freigabe wie die gesamte technische Verwaltung. Der Entwurf benennt ihre Handlung und ordnet sie einer passenden Rolle zu. Damit bleibt die Rechteplanung Teil der Funktionsentwicklung. Sie wird nicht erst nach einer Veröffentlichung nachgeholt, wenn bereits unklare Zugriffsmöglichkeiten entstanden sind.

Für Lufox entsteht so ein System, das sich in gewöhnlicher Sprache erklären lässt: Diese Rolle darf diese Handlung in diesem Zusammenhang ausführen, und die Entscheidung wird am tatsächlichen Ausführungspunkt geprüft. Menüs unterstützen das Verständnis, Tests belegen Freigabe und Entzug, und Ausnahmen bleiben begründet. Berechtigungen werden dadurch zu einem nachvollziehbaren Bestandteil des Projekts, statt zu einer Sammlung schwer erklärbarer Schalter.

Ein weiterer Testfall betrifft mehrere gleichzeitig vorhandene Rollen. Eine Person kann sowohl eine gewöhnliche Spielrolle als auch eine zeitweise Teamrolle besitzen. Nach dem Entfernen der Teamrolle müssen die normalen Spielmöglichkeiten bestehen bleiben, während ausschließlich die zusätzlichen Befugnisse entfallen. Dieser Fall deckt ungewollte Abhängigkeiten auf, bei denen alltägliche Rechte versehentlich nur über eine Verwaltungsrolle gewährt wurden.

Für die Zusammenarbeit hilft außerdem eine gemeinsame Benennung von Rollen und sichtbaren Titeln. Ein dekorativer Titel kann frei gestaltet sein, sollte aber keine Verantwortung suggerieren, die das Konto nicht besitzt. Wer als Ansprechpartner erkennbar ist, braucht einen tatsächlichen Weg zur Bearbeitung der entsprechenden Anliegen. Umgekehrt muss nicht jede technische Berechtigung als öffentlicher Rang erscheinen. Die sichtbare Darstellung unterstützt die Orientierung; die fachliche Zuständigkeit bleibt der Maßstab für die Rechtevergabe.