API und Zugangsdaten

Rechte trennen#

Serverlizenz, Benutzerrechte und Upload-Tokens haben verschiedene Aufgaben. Upload-Tokens sind befristet und nur für Belege nutzbar, nicht für Panel-Verwaltung.

Fehler behandeln#

Zeitüberschreitungen und Ratenlimits ohne enge Wiederholungsschleifen behandeln. Finanzielle Änderungen mit unklarem Ausgang nicht automatisch wiederholen. Authentifizierungsheader aus URLs, Client-Code und Logs fernhalten.

Endpunkt und Berechtigung zuordnen#

Es gibt keinen universellen Schlüssel. Die Serverlizenz authentifiziert die SaaS-Bridge; Komponenten-Tokens können Scopes benötigen. Browseraktionen brauchen Kontorolle, Rechte und gegebenenfalls CSRF. Upload-Tokens gelten für Kontext, Server und Auftrag, nicht für Administration.

Das Beispiel zeigt nur den Header. Der Platzhalter ist kein gültiger Zugang; die Ressource erstellt den Protokollinhalt. Beliebiges JSON wird dadurch kein Auftrag. Authentifizierung gehört in Serverkommunikation, nicht in Browsercode, URL, Analytics oder geteilte Fehlerausgaben.

Authorization: Bearer YOUR_SERVER_LICENSE
Content-Type: application/json

• Lizenz behandeln

Auftragsstatus von HTTP unterscheiden#

Die Bridge akzeptiert POST JSON, keine frei gewählten SQL-Texte oder Tabellennamen. pending oder claimed bedeutet noch nicht fertig. Ergebnis und Endstatus prüfen, bevor eine Aktion als erfolgreich angezeigt wird.

• 401: richtigen und nicht erneuerten Schlüssel prüfen.
• 403 bridge_disabled / subscription_inactive / permission_denied: Tosun-Connect-Karte des Servers (bridge_disabled: Verbindung dort abgeschaltet), Abonnement und Rechte prüfen; Wiederholung schafft keine Rechte.
• 405 / 415: Methode und JSON Content-Type korrigieren; falsche Felder oder JSON nicht ständig erneut senden.
• 429: Retry-After beachten und warten; die Bridge begrenzt parallele Arbeit und erhöht Fehlerabstände.
• 503 / Timeout: bereinigte Zeit und Server-/Auftragsreferenz notieren, Verbindung prüfen.

• Bridge und Fehler

Mit kleiner Anfrage testen#

Testserver oder kontrollierten Charakter verwenden. Erst eine Leseanfrage, richtigen Charakter und Daten mit dem Spiel vergleichen. Feste Operationen und Pagination sind kein voller Datenbankdump. Referenz für die Unterscheidung von Aufträgen und Wiederholungen behalten.

Nur Status, Dauer und nicht geheime Referenz loggen. Tokens und persönliche Spielerdaten aus öffentlichen Meldungen entfernen. Nach Schlüssel-, Rechte- oder Paketwechsel erneut prüfen.

Nicht denselben Verwaltungstoken überall verwenden. Komponenten-Zugänge minimal berechtigen und ungenutzte widerrufen. Nach Endpunkt- oder Rechtewechsel Erfolg und Ablehnung erneut prüfen, statt alten Erfolgslogs zu vertrauen.

1. Erfolg am eigenen Zielserver und Ablehnung falscher/entzogener Zugangsdaten prüfen.
2. Fehlende Teamrechte müssen ablehnen; keine Tests an fremden Kundensystemen.
3. pending, failed, expired und done getrennt anzeigen, nicht pauschal Erfolg.
4. Bei unknown_outcome eines Geldvorgangs Live-Kontostand und Protokoll vor weiterer Änderung prüfen.

• Begrenzte Anfragen
• Frameworks

Browseranfragen und Serverprotokoll unterscheiden#

/api/tenant_db_bridge.php authentifiziert Mitarbeiter über ihre Sitzung. Erforderlich sind POST, application/json, gültiges _csrf und ein Konto desselben Mandanten; die Grenze beträgt 4096 Bytes. action ist enqueue oder result. Eine Serverlizenz erstellt keine Browsersitzung. Leserechte bedeuten keine Geldschreibrechte; die Operation wird gesondert autorisiert.

/api/server_db_bridge.php übernimmt Gesundheitsdaten, Auftragsabruf und Ergebnisse des Spielservers. Es nutzt POST JSON und eine Bearer-Serverlizenz mit 65536-Byte-Grenze. Cookie und CSRF ersetzen dieses Protokoll nicht. Klären Sie zuerst den aufgerufenen Weg; fremde Zugangsdaten lösen dessen Authentifizierung nicht. Imitieren Sie das Resource-Protokoll nicht mit beliebigem JSON.

Annahme und Abschluss auseinanderhalten#

ok=true kann eine angenommene HTTP-Anfrage bedeuten, ohne einen abgeschlossenen Spielauftrag zu bestätigen. Verfolgen Sie id, operation und status innerhalb request. pending wartet; claimed wurde vom Server übernommen. done bedeutet abgeschlossen, failed fehlgeschlagen und expired abgelaufen. Behalten Sie beim Ergebnisabruf denselben server_id- und request_id-Kontext.

Prüfen Sie Endstatus und error vor einer Erfolgsmeldung. Gleiche wartende Anfragen können einen bestehenden Auftrag zurückgeben; das ist keine unbegrenzte dauerhafte Wiederholungsgarantie. Stoppen Sie Geldschreibvorgänge bei unknown_outcome. Timeout oder ungültiges Ergebnis beweisen keine ausbleibende Änderung. Prüfen Sie Live-Guthaben, früheres Ziel und Audit-Eintrag; löschen Sie keine Nachweise für einen erneuten Versuch.

Entwicklerfehler knapp und bereinigt melden#

Prüfen Sie bei 405 die Methode, bei 415 JSON Content-Type und bei 400 gültiges JSON sowie erlaubte Felder. Auf dem Browserweg betreffen 401 die Sitzung und 419 die CSRF-Prüfung; öffnen Sie die Seite normal neu. Bei 404 prüfen Sie Server- und Auftragskontext, ohne andere Kunden zu testen. Warten Sie bei 429 auf laufende Arbeit.

Erfassen Sie für 503 oder unklare Netzwerkergebnisse Zeit, Endpunkt, HTTP-Status, Operation und nicht geheime Referenz. Das Beispiel ist eine Supportnotiz, kein Anfragekörper. Entfernen Sie Cookies, Authorization, _csrf, Lizenzen und Spielerdaten. Beheben Sie die betroffene Stufe statt schneller Wiederholungen und validieren Sie zuerst mit einem kontrollierten Leseauftrag.

Endpoint: /api/tenant_db_bridge.php
Method: POST
HTTP status: 419
Error: csrf_failed
Operation: players.list
Reference: YOUR_REQUEST_REFERENCE
Time: YOUR_ERROR_TIME

Eine Spielerseite mit zwei geprüften JSON-Nachrichten lesen#

Dieses Beispiel liest die erste Spielerseite in einem Browser, der bereits im Panel Ihres Kontos angemeldet ist. Server 123 und die Anfrage-ID sind erfunden: Verwenden Sie Ihren eigenen Server und request.id aus der enqueue-Antwort. Ersetzen Sie CURRENT_PAGE_CSRF durch den gültigen Wert der aktuellen Seite. Dieser Wert ist keine Serverlizenz und gehört nicht in eine Supportnachricht. Erforderlich sind ein POST an denselben Ursprung, application/json und die Browsersitzung. Lesen setzt servers.manage oder players.view voraus; im schreibgeschützten Demomodus wird enqueue abgelehnt.

Die erste Nachricht enthält nur einen leeren cursor; der Vorgang liefert höchstens 25 Datensätze pro Seite. Fügen Sie weder limit noch SQL, Tabellennamen, Verbindungszeichenfolgen oder Geldparameter hinzu. Bei pending fragen Sie mit der zweiten Nachricht denselben Auftrag ab, statt einen weiteren einzureihen. Bei done lesen Sie request.result.items. Ist request.result.has_more wahr, verwenden Sie request.result.next_cursor beim nächsten bewussten Seitenaufruf. Eine leere Liste ist nur zusammen mit einem erfolgreich abgeschlossenen Status zu beurteilen. Die Vorlagen enthalten keine gültigen Zugangsdaten. Beschränken Sie den ersten Test auf einen Lesevorgang auf Ihrem eigenen Testserver; öffentliche Browsererweiterungen sollten dadurch keinen Administratorzugriff erhalten.

POST /api/tenant_db_bridge.php
Content-Type: application/json

Enqueue:
{
  "_csrf": "CURRENT_PAGE_CSRF",
  "server_id": 123,
  "action": "enqueue",
  "operation": "players.list",
  "params": {"cursor": ""}
}

Result (use request.id from the enqueue response):
{
  "_csrf": "CURRENT_PAGE_CSRF",
  "server_id": 123,
  "action": "result",
  "request_id": "00112233445566778899aabbccddeeff"
}

• MySQL-Brücke
• Panel- und Kontozugriff

HTTP-Zeitüberschreitung und Auftragsfrist auseinanderhalten#

Angenommen, enqueue wurde um 14:03:10 angenommen und request.id gespeichert, doch eine spätere result-Abfrage verliert die Netzwerkverbindung. Eine einzelne HTTP-Anfrage des Panels kann nach zwölf Sekunden abbrechen; der eingereihte Auftrag läuft 120 Sekunden nach seiner Erstellung ab. Ein Browserabbruch storniert diesen serverseitigen Auftrag nicht. Melden Sie „keine Antwort“ daher nicht als expired oder failed. Bewahren Sie die bekannte ID auf und lesen Sie result nach Wiederherstellung der Verbindung mit derselben server_id. Das normale Panel prüft ausstehende Ergebnisse alle drei Sekunden; ergänzen Sie keine eng getaktete Abfrageschleife.

Endet der reine Leseauftrag players.list mit expired und request_expired, protokollieren Sie den Fehler, beheben Sie die Verbindung und starten Sie anschließend einen neuen bewussten Lesevorgang. Bei player.money.set können ein Ablauf nach claimed oder ein ungültiges Ergebnis unknown_outcome erzeugen: Das belegt keinen unveränderten Kontostand. Stoppen Sie weitere Schreibvorgänge und prüfen Sie den aktuellen Stand sowie den vorhandenen Vorgang. Ergebnisse sind kein unbegrenztes Archiv; abgelaufene Datensätze werden später schrittweise bereinigt. Ist der Datensatz nicht mehr auffindbar, erraten Sie seinen Ausgang nicht durch eine weitere Geldänderung. Für den Support reichen nicht geheime Referenz, Zeitpunkt, operation und letzter bekannter Status.

Illustrative observations; not an API request body:
14:03:10  enqueue accepted; save request.id
14:03:22  HTTP timeout; job outcome is not established
Later     result with the same server_id + request_id

Read:  expired + request_expired -> investigate before a new read
Write: expired + unknown_outcome -> stop writes and reconcile

• MySQL-Brücke
• Leistung und Warteintervalle