LexoNETDocs
Docs 0.6.0Anmelden
Architektur und API

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

  1. In der MDT-Systemleitung unter Integrationen einen Zugang vom Typ fivem für den Testmandanten anlegen.
  2. Öffentliche Kennung und einmalig angezeigtes Geheimnis getrennt behandeln. Das Geheimnis ausschließlich in die serverseitige Konfiguration übernehmen.
  3. Mit ping Verbindung und Umgebung prüfen; Negativtests für falsche Integration, Signatur und Zeit durchführen.
  4. 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.
  5. 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

RichtlinieVoraussetzung
Web erlaubtOptional übermittelte Charakterfelder ändern keine Rechte
Web nur, wenn IC onlineZuordnung und frische Presence; gesendete Charakterkennung muss passen
Ausschließlich IC-GeräteTicket, 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.