Manuals

Deutsch

English

Deutsch

English

Appearance

Authentifizierung ​

Jede Anfrage an die iorder POS API erfordert eine Authentifizierung. Das System verwendet die API-Schlüssel-Authentifizierung, bei der der Schlüssel eine Service-Geräte-Sitzung identifiziert.

API-Schlüssel ​

Der API-Schlüssel ist eine Zeichenkette, die eine Service-Geräte-Sitzung identifiziert. Er muss in jeder API-Anfrage enthalten sein.

So erhalten Sie einen API-Schlüssel ​

Bitten Sie einen Restaurantadministrator, unter API-Schlüssel einen Schlüssel für den vorgesehenen Standort zu erzeugen. Verwenden Sie einen Dienstschlüssel für die Integration, getrennt vom persönlichen Passkey zur Anmeldung. Bewahren Sie ihn vertraulich auf und klären Sie die Basis-URL mit dem Betreiber.

Senden des API-Schlüssels ​

Übergeben Sie den API-Schlüssel auf eine der beiden folgenden Arten:

Header (empfohlen):

text
api_key: <ihr-api-schluessel>

Query-Parameter:

text
?api_key=<ihr-api-schluessel>

Der Server prüft zuerst den api_key-Header und falls dieser fehlt, den Query-Parameter.

Beispiele ​

Header-basierte Authentifizierung:

bash
curl -i -H "api_key: abc123-def456-ghi789" \
  "https://{host}/orders/location"

Query-Parameter-Authentifizierung:

bash
curl -i "https://{host}/orders/location?api_key=abc123-def456-ghi789"

Sitzungslebenszyklus ​

Der Schlüssel identifiziert eine serverseitige Sitzung mit Geräte- und Standortzuordnung. Prüfen Sie die Authentifizierung bei jeder Anfrage, auch beim erneuten Öffnen eines Ereignisstroms. Eine offene SSE-Verbindung garantiert keine Berechtigung späterer Anfragen.

Prüfen Sie bei 401 den konfigurierten Host und Schlüssel mit dem Administrator. Erzeugen Sie nach einem Serverneustart nicht automatisch einen neuen Schlüssel; prüfen Sie zunächst den vorhandenen.

Nicht autorisierte Antworten ​

Es gibt zwei verschiedene 401-Antwortformate, abhängig davon, wie die Anfrage fehlschlägt:

AuthorizationInterceptor (fehlender oder ungültiger API-Schlüssel) ​

Wenn der API-Schlüssel fehlt, leer ist oder keiner aktiven Sitzung entspricht, gibt der AuthorizationInterceptor Folgendes zurück:

http
HTTP/1.1 401 Unauthorized
Content-Type: text/plain

{"error" : "Session not valid."}

Der Server fügt absichtlich eine zufällige Verzögerung zwischen 500 ms und 1499 ms hinzu, bevor er antwortet. Rechnen Sie bei jedem fehlgeschlagenen Authentifizierungsversuch mit dieser Verzögerung.

GlobalExceptionHandler (abgelaufene oder nicht autorisierte Sitzung) ​

Wenn der API-Schlüssel erkannt wird, die Sitzung aber nicht mehr gültig ist (z. B. abgelaufen oder falscher Sitzungstyp), gibt der UnAuthorizedException-Handler Folgendes zurück:

http
HTTP/1.1 401 Unauthorized
Content-Type: application/json

{"message": "Unauthorized", "uid": null}

Diese Antwort enthält ebenfalls eine zufällige Verzögerung zwischen 500 ms und 1499 ms.

Umgang mit 401-Antworten ​

Prüfen Sie immer auf beide Antwortformate:

bash
curl -i -H "api_key: invalid-key" "https://{host}/orders/location"

Beispielausgabe:

http
HTTP/1.1 401 Unauthorized
Content-Type: text/plain

{"error" : "Session not valid."}

Hinweise zur Ratenbegrenzung ​

Behandeln Sie 401 als Problem mit Zugangsdaten oder Konfiguration. Stoppen Sie die automatische Verarbeitung und lassen Sie Schlüssel, Host und Standort vom Betreiber prüfen. Setzen Sie die Verarbeitung nach der Korrektur fort. Prüfen Sie vor dem Parsen den HTTP-Status, da der Body Klartext oder JSON enthalten kann.

Verwenden Sie bei vorübergehenden Netzwerk- und Serverfehlern begrenzte Wiederholungen gemäß Fehlerbehandlung.

Nächste Schritte ​