Zugriffskontrolle

Die Zugriffskontrolle in dzbot definiert, wer was auf einem Server tun kann.

Praktisch nutzt dzbot drei Ebenen:

1. Benutzerrechte (direkte Rechte auf einem Spieler-Konto)
2. Gruppenrechte (Rechte, die über Gruppen geerbt werden)
3. Verfügbarkeit eines Abonnements (Server benötigt ein gültiges Abonnement für den dzbot-Dienst)

Fraktionsspezifische Rechte sind im Konzept Fraktionen dokumentiert.

Wie der effektive Zugriff berechnet wird

Für jeden Spieler kombiniert dzbot:

• Direkte Benutzerrechte auf den Spieler
• Rechte aus allen Gruppen, denen der Spieler angehört
• Rechte aus allen serverseitigen Standardgruppen

Namensmuster, das in Rechten verwendet wird:

• <modul>.<aktion> (z. B. players.whitelist, groups.edit_access_rights, settings.edit)

Manche Module haben zusätzlich einen Platzhalter, der jedes Recht des Moduls umfasst, auch später hinzukommende — zum Beispiel casino.* für alle Kasino-Spiele. Ein einzelnes Recht schlägt den Modul-Platzhalter, der Modul-Platzhalter schlägt den Bereichs-Platzhalter (player.*).

Manche Rechte sind unter sich noch feiner aufgeteilt. settings.edit ist so eines: darunter liegt ein Recht pro Einstellungsbereich (settings.edit.casino) und darunter eines pro einzelner Einstellung (settings.edit.whitelist_accounts.whitelistEnabled). Ein Eintrag auf Neutral folgt dem nächsten darüber. settings.edit heißt also weiterhin alle Einstellungen, und du kannst einen ganzen Bereich freigeben und darin eine Einstellung verweigern, oder nur eine einzige Einstellung vergeben und sonst nichts. Siehe Einstellungen für Moderatoren.

Benutzerrechte

Benutzerrechte sind explizite Berechtigungen, die direkt einem bestimmten Spieler zugewiesen werden.

Verwende Benutzerrechte, wenn:

• eine Person eine Ausnahme benötigt,
• du vorübergehenden erhöhten Zugriff benötigst,
• du nicht eine ganze Gruppe ändern möchtest.

Beispiele:

• players.whitelist
• restrictions.create
• players.change_access_rights

Wo verwaltet:

• Admin -> Spieler -> Spieler-Details -> Einstellungen-Tab

Wann zu verwenden:

Verwende Benutzerrechte nur bei vorübergehenden Ausnahmen, i. d. R. sind Gruppenrechte besser geeignet.

Gruppenrechte

Gruppenrechte sind die Standardmethode zur Verwaltung des Teamzugriffs.

Du definierst Rechte einmal für eine Gruppe und weist Spieler dieser Gruppe zu. Jedes Mitglied erbt diese Rechte.

Wo verwaltet:

• Admin -> Gruppen -> Gruppe -> Einstellungen-Tab -> Benutzerrechte
• Admin -> Gruppen -> Gruppe -> Spieler-Tab, um Mitglieder hinzuzufügen/zu entfernen

Bewährte Praxis:

• Rollebasierte Gruppen erstellen (z. B. Support, Moderation, Ökonomie, Inhalte)
• Benutzer-Level-Overrides minimal halten
• Gruppenänderungen für langfristige Zugriffsänderungen bevorzugen

Häufige Beispiele für Gruppenrechte:

• groups.view, groups.create, groups.edit, groups.delete
• groups.edit_access_rights
• groups.manage_all_places

Standardgruppen

Standardgruppen sind serverseitige Baseline-Gruppen, die in den Zugriffskontrollen für alle Spieler auf diesem Server berücksichtigt werden.

Dies ist nützlich für eine gemeinsame Baseline-Berechtigungsmenge, ohne jeden einzelnen Spieler manuell zu bearbeiten.

Wo verwaltet:

• Admin -> Einstellungen -> Spieler & Zugriff -> Standardgruppen

Admin-Level-Rechte

Einige Rechte werden als Admin-Level betrachtet und schalten Admin-Panel-Bereiche und -Operationen frei.

Es gibt auch eine Administrator-Berechtigungsebene mit vollen Zugriffsrechten auf Serverebene.

Verwende diese Rechte sehr vorsichtig und nur für vertrauenswürdige Mitarbeiter.

Typische Beispiele mit hohen Auswirkungen:

• orders.refund
• orders.redeliver
• server.change_plan
• players.impersonate_player
• admin.tickets.view
• admin.tickets.reply
• admin.tickets.assign

Ticket-Rechte sind zwischen Shop-Zugriff und Admin-Zugriff getrennt:

• player.tickets.view erlaubt Spielern, Shop -> Tickets zu öffnen und ihre eigenen Tickets zu sehen.
• player.tickets.create, player.tickets.send_message, player.tickets.close und player.tickets.archive steuern Spieleraktionen im Shop-Ticketablauf.
• admin.tickets.view schaltet schreibgeschützten Zugriff auf Server Admin -> Tickets frei.
• admin.tickets.reply, admin.tickets.internal_message, admin.tickets.assign und admin.tickets.change_status sind reine Admin-Ticketrechte und zählen ebenfalls als Admin-Panel-Zugriff.
• admin.tickets.change_level erlaubt das Verschieben eines Tickets zwischen Support-Levels; admin.tickets.manage_levels erlaubt die Verwaltung der Level selbst. „Darf Level verschieben" ist eine andere Frage als „welche Level sehe ich".
• admin.tickets.manage_categories erlaubt das Bearbeiten der Anliegensarten und ihrer Aufnahmeformulare sowie das Veröffentlichen ihrer Discord-Panels. Absichtlich getrennt von admin.tickets.manage_levels: „darf das Fraktionsanmeldungs-Formular bearbeiten“ ist eine deutlich schwächere Berechtigung als „darf die Sichtbarkeit von Support-Levels umbauen“.

Hauptschalter

Ein paar Rechtefamilien sind keine flache Liste. Ein Recht wirkt als Hauptschalter, und die Rechte darunter brauchen ihn zusätzlich — eine Facette allein zeigt nichts an. Ein entzogener Hauptschalter wirkt absolut: Er wird außerhalb der Rechtetabelle geprüft, kein anderes Recht hebelt ihn aus.

Derzeit gibt es zwei:

• admin.players.see_position über admin.players.see_places, .see_routes und .see_contacts
• admin.factions.see_locations über admin.factions.see_base_locations, .see_base_alarms, .see_spawn_positions und .see_markers

Beide existieren aus demselben Grund: Alles darunter verrät, wo jemand war — und das ist eine andere Frage als die, ob jemand Spieler oder Fraktionen verwalten darf.

Rechte, die kein Backfill vergeben hat

Wenn ein Feature ein bestehendes Recht feiner aufteilt, gibt ein Backfill-Befehl die neuen Schlüssel üblicherweise an alle weiter, die das alte hielten — damit niemand eine Seite verliert, die er hatte. Die Ortsrechte oben wurden davon bewusst ausgenommen, ebenso die Rechte für vollständig neue Features.

Eine Gruppe mit einzelnen admin.*-Rechten statt des admin.*-Platzhalters braucht diese also von Hand:

Rechte	Feature
admin.players.see_position, .see_places, .see_routes, .see_contacts	Spielerdetails, Spielerüberwachung
admin.factions.see_locations, .see_base_locations, .see_base_alarms, .see_spawn_positions, .see_markers	Fraktionen
admin.events.access, .manage, .run, .payout, .manage_templates	Events
admin.game_audit.view, .edit	Server-Diagnose
admin.audit.view, org.audit.view	Audit-Trail
admin.tickets.send_embed	Ein Anliegensart-Panel nach Discord veröffentlichen
admin.players.cheating_index	Seite Cheating-Index und der Index im Spieler-Dossier

admin.audit.view ist davon das stärkste: Wer es hält, sieht Audit-Einträge aus allen Bereichen, unabhängig von seinen sonstigen Rechten. Es steckt bewusst in keiner Standardgruppe.

Meldet ein Kollege, dass eine Seite nach einem Update verschwunden ist, ist diese Tabelle die erste Anlaufstelle.

Öffentliche Spielerprofile

player.public_profiles.access erlaubt eingeloggten Spielern, die öffentlichen Profile anderer Spieler zu öffnen, und ergänzt Spieler in ihrer Navigation. Das Recht ist neu und wurde keiner Gruppe gegeben — außer dass Gruppen mit dem Platzhalter player.* es automatisch haben. Soll ein solcher Server keine Profile zeigen, setze das Recht in diesen Gruppen auf Verweigern. Gäste steuert getrennt davon der Schalter für öffentliche Spielerprofile bei den Gastseiten.

Wiki

player.wiki.access zeigt eingeloggten Spielern das Wiki des Servers und ergänzt Wiki in ihrer Navigation. Gruppen mit dem Platzhalter player.* haben es automatisch; Gruppen, die player.map.access einzeln vergeben, haben es mit dem Release bekommen, das es eingeführt hat. Gäste steuert getrennt davon der Schalter Wiki bei den Gastseiten. Ob das Wiki deinen eigenen Loot oder Vanilla-Werte zeigt, regelt Loot-Einstellungen teilen.

Support-Level-Rechte (serverabhängig)

Die meisten Rechte sind auf jedem Server gleich. Support-Level sind die Ausnahme: Jedes Level jedes Servers bringt sein eigenes Recht mit, benannt nach der Datenbank-ID des Levels.

• Der Schlüssel lautet admin.tickets.level_<id> und erscheint in den Gruppen- und Spieler-Rechteeditoren, beschriftet mit Position und Name des Levels.
• Weil der Schlüssel an der ID und nicht an der Position hängt, verschiebt ein Umsortieren nie eine Berechtigung.
• Die Auflösung ist kumulativ: Die höchste Levelposition, die ein Mitarbeiter auflöst, gewinnt, und alle Level auf oder unter dieser Position sind sichtbar. Das ist Absicht — eine nicht kumulative Auflösung würde hochgereichte Tickets still verlieren, sobald jemand eine Checkbox vergisst.
• Die admin.*-Wildcard deckt Level-Rechte wie jeden anderen Admin-Schlüssel ab, Voll-Admins brauchen also keine Einzelvergabe.
• Ein neu angelegtes Level hat niemand. Seine Tickets sind unsichtbar, bis das Recht vergeben wird, und der Level-Verwaltungs-Drawer warnt solange. dzbot schreibt niemals Rechte für jemanden mit.
• Beim Löschen eines Levels wird der nun tote Schlüssel aus jeder Gruppe, jedem Spieler und jedem Developer-API-Key dieses Servers entfernt.
• Ein Level-Recht ist für sich kein Admin-Panel-Zugriff: es sagt, welche Tickets du siehst — eine Gruppe mit nur einem Level-Recht braucht weiterhin ein gewöhnliches admin.tickets.*-Recht, um die Warteschlange zu öffnen.
• Umsortieren und Auflösen von Leveln ändern, was ein bestehendes Recht auflöst (die Regel ist positionsbasiert), deshalb erfordern beide Zugriff auf alle Level — admin.tickets.manage_levels allein genügt nicht.
• Impersonation vergleicht die Level-Reichweite statt exakter Schlüssel: Level 3 deckt ein Ziel auf Level 1 ab.

Verknüpfung zu Hilfslinks der Dokumentation

Die Breadcrumb-Leiste im Admin-Bereich kann einen Hilfslink anzeigen, der die entsprechende Dokumentationsseite öffnet.

Dies wird durch ein dediziertes Zugriffsrecht gesteuert:

• documentation.view

Bewährte Praxis:

• Weise documentation.view jeder Gruppe zu, die Admin-Panel-Zugriff hat (z. B. Moderatoren, Support, Volladmins)
• Halte es aus Spielergruppen fern, um zu vermeiden, dass interne Hilfsdokumentationen im Shop-Frontend offengelegt werden

Abonnementprüfung vs. Rechte

Rechte allein reichen nicht immer aus. Admin- und Shopzugriffe erfordern auch ein aktives Abonnement.

Zugriffe können daher aus zwei Gründen fehlschlagen:

1. Fehlendes Berechtigungsrecht
2. Inaktives oder abgelaufenes Abonnement (Admin-Routen leiten zu Stripe Manage weiter)

Wenn Mitarbeiter sagen: „Ich habe das Recht, aber keinen Zugriff“, überprüfe zuerst den Abonnementstatus. Admin-Seiten leiten bei Inaktivität zu Stripe Manage um.

Checkliste für Zugriffsprüfungen

Verwende diese Schnell-Checkliste, wenn der Zugriff nicht wie erwartet funktioniert:

„Ich sehe keinen Menüeintrag“

• Überprüfe Gruppen-/Benutzerrechte für das zugehörige Modul/Aktion.
• Überprüfe, ob das Serverabonnement aktiv ist.

„Ich kann eine Seite öffnen, aber keine Aktionen ausführen“

• Anzeigerechte und Bearbeitungs-/Lösch-/Ausführungsrechte sind separate Rechte.
• Erteile das spezifische Aktionsrecht (nicht nur Modul-Anzeigerechte).

„Ein neuer Spieler hat zu viel/zu wenig Zugriff“

• Überprüfe Standardgruppen in den Servereinstellungen.
• Überprüfe, ob der Spieler direkte Benutzerrechte-Overrides hat.

Empfohlener Admin-Workflow

1. Erstelle eine kleine Anzahl rollenbasierter Gruppen — die Gruppen-Vorlagen sind ein fertiger Startpunkt.
2. Weise Modul-/Aktionsrechte diesen Gruppen zu.
3. Verwende Standardgruppen für die Basisberechtigung beim Onboarding.
4. Verwende direkte Benutzerrechte nur für Ausnahmen.
5. Überprüfe hochprivilegierte Berechtigungen (Vollzugriffs-Admin, Rückerstattungen, Einschränkungen, größere Konfigurationsänderungen) regelmäßig.