Authentisierung und Autorisierung
Die Integration authentisiert den Server; die Personalmitgliedschaft autorisiert den Zugriff. Eine gültige HMAC-Signatur oder ein Jobrang erteilt nicht automatisch MDT-Rechte.
#Integration einrichten und rotieren
- In der MDT-Systemleitung unter Integrationen einen Zugang vom Typ
fivemfür den Testmandanten anlegen. - Öffentliche Kennung und einmalig angezeigtes Geheimnis getrennt behandeln. Das Geheimnis ausschließlich in die serverseitige Konfiguration übernehmen.
- Mit
pingVerbindung und Umgebung prüfen; Negativtests für falsche Integration, Signatur und Zeit durchführen. - Bei Rotation das neue Geheimnis am Server hinterlegen und testen. Das alte gilt laut API-Vertrag noch 24 Stunden; die Systemleitung kann es vorher widerrufen.
- Nicht mehr benötigte Zugänge deaktivieren. Keine Schlüsselwerte in Prüfberichte übernehmen.
#Spieleridentität und Ticket
identitaet/verknuepfen löst den Einmalcode aus dem eigenen MDT-Profil ein. Vorrangige Kennung ist die vollständige license:-Kennung. Abweichende Kennungsarten müssen serverseitig ausdrücklich und für alle Aufrufe einheitlich eingerichtet sein.
sitzung/ticket prüft Mitgliedschaft, Sperren und desktop.nutzen. Das Ticket wird nur an den anfragenden Spieler weitergegeben und sofort eingelöst. Es ist kein dauerhaftes Login und darf nicht gespeichert werden.
#IC-Zugangsrichtlinien
| Richtlinie | Voraussetzung |
|---|---|
| Web erlaubt | Optional übermittelte Charakterfelder ändern keine Rechte |
| Web nur, wenn IC online | Zuordnung und frische Presence; gesendete Charakterkennung muss passen |
| Ausschließlich IC-Geräte | Ticket, serverseitige Charakterkennung und frische Presence |
Ab dem dokumentierten MDT-Vertrag 0.7.8 können charakter_id, spielwelt und spieler_ip ergänzt werden. Die Charakterkennung kommt vom Serverframework, niemals aus frei gewählten NUI-Feldern. Spielwelt und IP-Bindung müssen dem eingerichteten Vertrag entsprechen.
Gerätesitzungen enden nach 30 Minuten ohne Vordergrundnutzung; Hintergrundpolling verlängert sie nicht. Strenge IC-Modi prüfen Zuordnung und Presence fortlaufend. Offline- oder Charakterwechsel können die Sitzung sofort beenden.
#NUI und Browser
Einbettung ist nur für serverseitig freigegebene, CSP-gültige NUI-Herkünfte erlaubt. Ein Unterstrich im Hostnamen ist ungültig. Eine Umbenennung muss mit dem ausgelieferten Paket abgestimmt werden; keine Herkunft blind übernehmen.
Die dokumentierte HTTPS-NUI-Konfiguration verwendet partitionierte sichere Cookies. Systemleitung bleibt außerhalb der NUI. Eine Passwortanmeldung zählt auch im NUI als Browserweg und erfüllt „Ausschließlich IC-Geräte“ nicht.
#Typische Fehler
zugang_charakter_fehlt: Charakterkennung fehlt im strengen Gerätemodus.zugang_charakter_passt_nicht: falsche Zuordnung oder Spielwelt.zugang_ic_offline: keine frische Presence.zugang_geraet: Gerätebindung, Adresse oder Leerlaufgrenze verletzt.- Wiederholter Loginfehler: neues Ticket holen; Ticketadresse nicht protokollieren.
#Wer darf das?
Systemleitung verwaltet Integration, Mitgliedschaften und Richtlinien. Entwickler implementieren Signatur und serverseitige Identität. Spieler lösen nur den eigenen Code ein.
Unklare Stellen oder fehlende Schritte meldest du im LexoNET-Discord oder als Ticket im Kundenbereich.