Generic Bearer Token (Client)

In diesem Dialog können Sie definieren, wie per HTTP-Request ein generischer Token angefordert und ausgelesen wird. Mit generischem Token ist gemeint, dass ein Server zwar Token anbietet, aber dabei nicht den standardisierten OAuth-Ablauf dafür zur Verfügung stellt. Sie konfigurieren dann nur diesen Dialog hier und keinen der OAuth-Dialoge.

Der generische Ablauf ist aktiv, sobald Sie in diesem Dialog alle Pflichtfelder füllen und diese Einstellungen speichern. Wenn Sie bereits manuell einen Token abgeholt hatten (siehe unten), wird dieser dann zur Autorisierung verwendet, wenn die Expiration Time nicht abgelaufen ist. Ist diese abgelaufen oder es wurde davor noch kein Token manuell abgeholt, dann wird das Abholen des Tokens automatisch angestoßen, wenn der Kanal verwendet wird. Hinweis: Ein vorhandener Token wird nur in diesem Dialog in (11) angezeigt und nicht in den Zusatzkennungen, wie Sie das von den beiden OAuth-Dialogen kennen.

(1) Der Server, der den Token bereitstellt. Es können die Platzhalter <server>, <user> und <password> verwendet werden für die Werte der Felder Partner Adresse, Eigene Kennung und Eigenes Kennwort (im Hauptdialog).

(2) Wenn gesetzt, dann wird der HTTP-Token-Request (1) über den DMZ-Server (falls vorhanden) gesendet.

(3) Wenn gesetzt, dann werden die Werte der Kanal-Felder Eigene Kennung und Eigenes Kennwort zur Autorisierung beim Server (1) verwendet (Basic Authentication im Header).

(4) Die für den Request (1) zu verwendende HTTP-Methode. Hinweis: Bei POST erscheinen weitere Felder für die Body-Daten und den Content Type.

(5) Hier können HTTP-Header für den Request an (1) über das Kontextmenü angelegt werden. Es können System-Konstanten verwendet werden.

(6) Hier können Sie entweder einen JSONPath-Ausdruck (siehe Screenshot), einen regulären Ausdruck oder einen Header-Namen angeben, um den Token aus der Response auszulesen.

Beispiel für regulären Ausdruck: "access_token":\s*"(.*?)",

Beispiel für Header: X-OAuth-Token

(7) Wie (6), nur für die Ablaufzeit (Expiration Time) des Tokens.

(8) Die Zeiteinheit der Ablaufzeit.

(9) Wird die Ablaufzeit des Tokens (Expiration Time) nicht ausgelesen (7), wird diese Default-Zeit verwendet.

(10) Der HTTP-Header, in den der ausgelesene Token geschrieben wird, wenn er für eine Autorisierung in einem HTTP-Request über diesen Kanal verwendet wird. In diesem Beispiel hier würde der HTTP-Header Authorization mit dem Wert Bearer 111kei... erzeugt werden. In den meisten Fällen können Sie hier die Default-Werte benutzen.

(11) Wenn Sie diesen Button klicken, erscheint der ausgelesene Token. Kommt es beim Abholen des Tokens zu einem Fehler, werden Ihnen in einem weiteren Dialog entsprechende Fehlermeldungen angezeigt. Fehlermeldungen finden Sie auch in der Datei ./logs/services/error.log.

(12) Die Expiration Time des Tokens.

(13) Hier können Sie zusätzliche Request Header definieren, die bei der Authentifizierung mit dem Token gesetzt werden. Beachten Sie bitte, dass Sie im Dialog nur den Namen des Headers angeben können. Der Wert stammt nach dem Abholen des Tokens (10) aus gleichnamigen Response Headern (wird automatisch intern ausgewertet). Beispiel: Sie haben in (13) einen Header myheader definiert. Sie klicken auf (11) und erhalten damit einen Token von (1). Dabei kam in der Response auch der Header myheader mit dem Wert 123 zurück. Ihr Header myheader in (13) hat nun ebenfalls den Wert 123. Wenn der Token nun in einer Authentifizierung über den Kanal verwendet wird, dann wird auch der Request-Header myheader mit dem Wert 123 mitgesendet.

(14) Wenn Sie zusätzlich zum Token (10) auch eine Basic Authentication verwenden möchten/müssen, können Sie diese Checkbox setzen. Es werden die Werte der Kanal-Felder Eigene Kennung und Eigenes Kennwort verwendet. Beachten Sie bitte, dass dann nicht der Token-Header Authorization in (10) verwendet werden kann.

(15) Entfernt alle Einstellungen und den Token.