Rollen und Berechtigungen in Yurna nachvollziehbar prüfen

„Der Bot hat doch die Rolle“ ist eine häufige Erklärung, wenn eine Verwaltungsaktion nicht funktioniert. Sie ist nur selten genau genug. Die Rolle der handelnden Person, die Rechte des Bots, die Position der Zielrolle und der konkrete Kanal können jeweils eine andere Frage beantworten. Ein einzelner grüner Haken für „Berechtigung vorhanden“ verschleiert diese Unterschiede. Für Yurna ist deshalb eine Prüfung hilfreich, die aus mehreren nachvollziehbaren Entscheidungen besteht und beim ersten Fehler einen konkreten Grund zurückgibt.

Der betrachtete Quellstand enthält getrennte Anwendungen für Bot, Dashboard und Admin-API sowie gemeinsame Hilfsfunktionen für Server- und Mitgliedsinformationen. Daraus ergibt sich eine besondere Anforderung: Dieselbe fachliche Aktion kann über verschiedene Eingänge angestoßen werden. Eine im Dashboard ausgeblendete Funktion darf nicht über einen direkt gesendeten Aufruf erreichbar werden. Umgekehrt sollte ein zulässiger Discord-Befehl nicht an einer anderen, versehentlich engeren Interpretation derselben Regel scheitern. Gemeinsame Regeln brauchen deshalb einen klaren Geltungsbereich.

Vier Fragen vor einer Rollenänderung

Zuerst wird geklärt, wer handelt. Eine angemeldete Person ist nicht automatisch berechtigt, jeden sichtbaren Server zu verwalten. Die Identität beantwortet nur die Frage nach dem Konto. Danach folgt die Zugehörigkeit zum konkreten Server und die für diese Aktion erforderliche Erlaubnis. Beide Prüfungen beziehen sich auf den aktuellen Vorgang. Eine frühere erfolgreiche Anmeldung oder ein früherer Verwaltungszugriff darf nicht unbegrenzt als Nachweis weiterverwendet werden.

Die zweite Frage betrifft das Ziel. Die gewünschte Rolle muss tatsächlich zum angegebenen Server gehören. Eine gültig aussehende Kennung genügt nicht. Ebenso muss geklärt werden, ob diese Rolle für die Funktion vorgesehen ist. Eine freiwillige Themenauswahl darf beispielsweise nur freigegebene Themenrollen vergeben. Selbst wenn der Bot technisch weitere Rollen bearbeiten könnte, folgt daraus kein fachlicher Auftrag. Die erlaubte Menge sollte deshalb ausdrücklich aus der Konfiguration hervorgehen und nicht aus dem gesamten technisch erreichbaren Rollenbestand.

Drittens werden die Fähigkeiten des Bots geprüft. Die handelnde Person kann alle erforderlichen Rechte besitzen, während der Bot die gewünschte Änderung nicht ausführen darf. Viertens kommt die Rollenordnung hinzu. Discord behandelt Berechtigungen und Rollenposition als unterschiedliche Aspekte; die offizielle Berechtigungsdokumentation beschreibt diese Grenzen. Eine hilfreiche Diagnose nennt daher nicht bloß eine fehlende Erlaubnis, sondern unterscheidet zwischen erforderlichem Recht, ungeeignetem Ziel und nicht bearbeitbarer Rollenposition.

Den Serverkontext konsequent mitführen

Viele Fehler entstehen durch Daten, die für sich genommen plausibel sind, gemeinsam aber nicht zusammengehören. Eine Mitgliedskennung stammt aus Server A, die gewählte Rolle aus Server B und die gespeicherte Einstellung aus einer früheren Ansicht. Der Aufruf ist syntaktisch gültig und fachlich widersprüchlich. Deshalb sollte der Serverkontext jeden relevanten Zugriff begrenzen. Nicht erst die abschließende Mutation, sondern bereits das Laden der Einstellung und das Auflösen des Ziels müssen denselben Kontext verwenden.

Im Datenmodell kann eine zusammengesetzte Eindeutigkeit ausdrücken, dass Mitgliedsdaten serverbezogen sind. In einer Fachfunktion kann ein einziger Kontextparameter verhindern, dass mehrere lose Serverkennungen versehentlich gemischt werden. Die konkrete Technik ist zweitrangig. Entscheidend ist, dass der Zusammenhang nicht nur in Kommentaren steht. Ein Test mit zwei künstlichen Servern und ähnlich benannten Rollen macht solche Fehler oft schneller sichtbar als viele Tests mit nur einem Server.

Ein Dashboard sollte die aktuelle Community außerdem deutlich zeigen. Das ist keine technische Sicherheitsprüfung, hilft aber gegen menschliche Fehlbedienung. Wenn zwei Server ähnliche Namen und Rollen besitzen, reicht ein kleines Symbol am Rand möglicherweise nicht. Vor einer weitreichenden Änderung sollte der Zielbereich noch einmal in verständlicher Form erscheinen. Gute Berechtigungsarbeit verbindet daher serverseitige Durchsetzung mit einer Oberfläche, die versehentliche Aktionen im falschen Kontext weniger wahrscheinlich macht.

Eine Entscheidung mit begründeten Ergebnissen

Als Beispiel soll eine Verwaltungsperson eine Rolle für freiwillige Benachrichtigungen freigeben. Der Vorgang vergibt die Rolle noch nicht, sondern verändert zunächst die erlaubte Auswahl. Angenommen wird eine lokale Konfiguration, die nur innerhalb des ausgewählten Servers bearbeitet werden darf. Die Prüfung liefert entweder eine freigegebene Entscheidung oder einen stabilen Grund für die Ablehnung. Technische Rohfehler werden nicht unmittelbar an die Oberfläche weitergereicht, weil sie selten erklären, was die Person als Nächstes tun kann.

// Entwurf einer fachlichen Entscheidung, keine Discord-API-Implementierung.
type RolePolicyResult =
  | { allowed: true }
  | {
      allowed: false;
      reason:
        | "actor-not-authorized"
        | "wrong-guild"
        | "role-not-manageable"
        | "role-not-suitable"
        | "permission-check-unavailable";
    };

Der letzte Grund ist bewusst von einer echten Ablehnung getrennt. Wenn die Prüfung wegen eines Netzfehlers nicht möglich ist, sollte das System nicht behaupten, die Person habe keine Berechtigung. Es sollte ebenso wenig einfach weiterarbeiten. Die fachlich korrekte Aussage lautet, dass die Entscheidung derzeit nicht zuverlässig getroffen werden konnte. Das ist ein eigener Zustand mit eigener Wiederholungsstrategie. Eine spätere Wiederholung kann helfen; eine Änderung der Serverrollen wäre dagegen möglicherweise völlig unnötig.

Die Reihenfolge der Prüfungen beeinflusst Verständlichkeit und Aufwand. Ein offensichtlich falscher Serverbezug kann ohne weitere externe Zugriffe abgelehnt werden. Erst danach lohnt sich die aktuelle Prüfung der beteiligten Rollen. Gleichzeitig sollten Fehlermeldungen keine unnötigen Informationen über fremde Server offenlegen. Eine Anfrage außerhalb des erlaubten Kontextes braucht keine detaillierte Beschreibung der dort existierenden Rollen. Präzision ist für berechtigte Verwaltung hilfreich, muss aber an den passenden Adressaten gebunden bleiben.

Anzeigen ist nicht Ausführen

Im Browser ist es sinnvoll, unzulässige Aktionen auszublenden oder zu deaktivieren. Das reduziert Irrwege und erklärt fehlende Voraussetzungen früh. Trotzdem bleibt jede Darstellung eine Momentaufnahme. Während eine Seite geöffnet ist, kann die Person eine Rolle verlieren, der Bot verschoben oder die Zielrolle umbenannt werden. Die eigentliche Prüfung gehört deshalb unmittelbar vor die Mutation. Die Oberfläche verbessert die Bedienung; das Backend entscheidet über die Ausführung.

Auch ein alter Discord-Knopf ist nur eine gespeicherte Einladung zu einer neuen Prüfung. Seine Existenz beweist keine aktuelle Erlaubnis. Bei einem Klick wird die handelnde Person erneut identifiziert und der fachliche Vorgang erneut geladen. Besonders wichtig ist das bei gemeinsam sichtbaren Nachrichten. Ein Knopf, den eine Verwaltungsperson erzeugt hat, darf nicht automatisch deren Rechte an jedes klickende Mitglied übertragen. Der ursprüngliche Auftraggeber und die später handelnde Person sind zwei unterschiedliche Rollen im Ablauf.

Eine zentrale Prüffunktion kann diese Regeln über mehrere Eingänge hinweg vereinheitlichen. Sie sollte jedoch keine Antwortform erzwingen. Der Bot braucht eine kurze Meldung, das Dashboard kann betroffene Felder erläutern und die Admin-API einen maschinenlesbaren Fehler liefern. Gemeinsam bleibt die Entscheidung mit ihrem Grund. Getrennt bleiben Sprache, Darstellung und Transport. So wird die fachliche Regel einmal gepflegt, ohne die Unterschiede zwischen den Oberflächen zu verstecken.

Änderungen während eines Vorgangs

Zwischen Prüfung und Ausführung bleibt immer ein Zeitfenster. Die Zielrolle kann genau dann verschoben werden, wenn der Bot die Änderung vorbereitet. Eine vorherige erfolgreiche Prüfung ist deshalb keine Garantie für die spätere Discord-Antwort. Der ausführende Code muss die Ablehnung des externen Dienstes weiterhin behandeln und als aktuellen Zustand erklären. Vorprüfung dient der besseren Diagnose und dem Vermeiden aussichtsloser Arbeit, ersetzt aber keine Auswertung des tatsächlichen Ergebnisses.

Bei besonders weitreichenden lokalen Änderungen kann zusätzlich eine Konfigurationsversion helfen. Wird die Liste freigegebener Rollen zwischen Öffnen und Speichern verändert, überschreibt ein alter Browserstand nicht still den neuen. Stattdessen wird ein Konflikt angezeigt. Diese Versionsprüfung betrifft eine andere Art von Berechtigung: die Gültigkeit der bearbeiteten Grundlage. Sie ergänzt die Frage, ob jemand handeln darf, um die Frage, ob noch derselbe Zustand bearbeitet wird.

Zwischengespeicherte Rechte sollten nach ihrer Verwendung bewertet werden. Für die Anzeige einer Navigation kann eine kurze Verzögerung akzeptabel sein. Für eine Rollenvergabe oder die Änderung einer sensiblen Einstellung ist ein veralteter Nachweis viel problematischer. Deshalb braucht nicht jeder Zugriff dieselbe Aktualitätsstrategie. Eine allgemeine Cache-Dauer für sämtliche Serverinformationen wirkt einfach, verwischt aber die unterschiedlichen Folgen einer veralteten Information. Das Fachrisiko sollte die Entscheidung bestimmen.

Ablehnungen so formulieren, dass sie helfen

Eine brauchbare Meldung besteht aus dem nicht ausgeführten Vorgang, dem verständlichen Grund und einer passenden nächsten Handlung. „Die Themenrolle wurde nicht freigegeben, weil Yurna sie derzeit nicht verwalten kann“ ist bereits nützlicher als „Forbidden“. Ein ergänzender Hinweis kann die Serververwaltung zur Prüfung der Rollenposition führen. Dabei sollte der Bot keine pauschale Vergabe umfassender Administratorrechte empfehlen. Die Lösung sollte zur fehlenden Fähigkeit passen und nicht sämtliche Schutzgrenzen beseitigen.

Für Mitglieder ist weniger technische Tiefe oft angemessen. Bei einer freiwilligen Rollenwahl genügt der Hinweis, dass die Rolle momentan nicht verfügbar ist und die Verwaltung informiert werden kann. Die Verwaltung erhält dagegen eine genauere Diagnose in ihrem geschützten Bereich. Diese abgestufte Erklärung verhindert, dass gewöhnliche Mitglieder mit internen Begriffen überfordert werden, ohne den Verantwortlichen die nötigen Informationen vorzuenthalten. Beide Texte beruhen auf demselben strukturierten Fehlergrund.

Prüfprotokolle sollten den Vorgang nachvollziehbar machen, ohne unnötig vollständige Berechtigungsobjekte zu speichern. Für eine Ablehnung reichen häufig Zeitpunkt, Aktion, betroffener Kontext, Ergebnis und ein stabiler Grund. Zugriffstoken oder vollständige Sitzungsdaten gehören dort nicht hinein. Wenn ein Fehlerbericht später weitergegeben wird, bleibt er dadurch verständlich, ohne gleichzeitig eine Sammlung fremder Kontoinformationen zu werden. Gute Diagnose entsteht durch gezielte Felder und nicht durch wahlloses Mitschreiben.

Eine kleine, aussagekräftige Testmatrix

Der Rollenentwurf lässt sich mit wenigen gezielten Kombinationen prüfen. Eine berechtigte Person und eine bearbeitbare Themenrolle bilden den Erfolgsfall. Danach wird jeweils genau eine Voraussetzung verändert: fehlende Nutzererlaubnis, fremder Serverbezug, ungeeignete Rolle, fehlende Bot-Fähigkeit oder unterbrochene externe Prüfung. Jeder Test erwartet einen anderen Grund und bestätigt zusätzlich, dass keine Konfiguration verändert wurde. So wird nicht nur die Ablehnung, sondern auch ihre Nebenwirkungsfreiheit geprüft.

Anschließend folgen zeitliche Fälle. Die Berechtigung wird nach dem Laden der Seite entfernt. Die Rolle wird nach einer Vorschau verschoben. Zwei Verwaltungspersonen speichern verschiedene Auswahlen auf derselben Grundlage. Ein alter Knopf wird durch ein anderes Mitglied verwendet. Diese Abläufe prüfen die Stellen, an denen eine anfangs korrekte Information später unzutreffend wird. Gerade dort versagen Systeme, die Berechtigungen nur beim Anzeigen einer Seite auswerten.

Die Discord-Dokumentation zu Application Commands beschreibt auch Einstellungen der Befehlsverfügbarkeit. Diese sind ein zusätzlicher Teil der Plattformoberfläche. Für Yurnas Fachlogik bleibt dennoch entscheidend, jede konkrete Wirkung am eigenen Eingang zu prüfen. Wer darf handeln, was darf verändert werden und kann der Bot es tatsächlich ausführen? Wenn diese drei Fragen getrennt beantwortet werden, wird aus einer unklaren Fehlermeldung ein nachvollziehbarer und wartbarer Ablauf.