Einführung: HTTP und Lobster_data.

Siehe auch: Kanal-Einstellungen allgemein, HTTP (Eingangsagent), HTTP (Eingangsagent Cron) und Antwortweg HTTP(S).

(1) Für den Untertyp HTTPS (HTTP über SSL) werden zusätzlich Zertifikate benötigt. Hinweis: Zusätzlich kann für die ausgehende HTTP(S)-Verbindung ein Client-Zertifikat erforderlich sein. Dazu wird ebenfalls das eigene Zertifikat (1) verwendet. Siehe auch Abschnitt Authentifizierung durch Client-Zertifikat.

(2) Der Realm ist ein frei wählbarer Name, der zusammen mit der URL einen HTTP-Bereich beschreibt, der eine Authentifizierung verlangt. Damit wird also eine Menge von HTTP-Ressourcen beschrieben, für die die selben Zugangsdaten gelten. Siehe hierzu den Begriff "Basic Authentication" im Abschnitt Preemptive Authentication.

(3) Siehe Abschnitt Eigener Zugang (Ich zum Partner).

(4) Siehe Abschnitt DATEV OAuth2 Hybrid Flow für eine spezielle OAuth2-Variante von DATEV.

(5) Siehe Abschnitt Preemptive Authentication.

(6) Es kann eine Authentifizierung per OAuth konfiguriert werden. Das Ziel ist dabei das manuelle Abholen eines Access Tokens (und gegebenenfalls auch eines Refresh Tokens). Siehe Abschnitte OAuth 1.0 (Client) und OAuth 2.0 (Client). Der empfangene Access Token wird dann intern im Kanal hinterlegt, siehe auch (9) und (7), und bei einem Request an den (Resource) Server verwendet. Hinweis: Sobald über die Buttons etwas eingetragen ist, ist OAuth aktiviert (erkennbar auch an einem dann erscheinenden Ausrufezeichen), d. h. wenn der Kanal als Client auftritt, initiiert er die Anmeldung am Server über den OAuth-Ablauf.

Hinweis: In den Zusatzkennungen sieht man einen Access Token in einem Eintrag mit dem Namen SYS_HTTP_OAUTH2 (bzw. SYS_HTTP_OAUTH1) und einen Refresh Token in einem Eintrag mit dem Namen SYS_HTTP_OAUTH2_REFRESH. Siehe auch Funktion change OAUTH2 access token(a,b).

(7) Ist hier ein gültige Refresh-URL eingetragen und es ist ein Refresh Token vorhanden, dann wird bei jedem HTTP-Zugriff über diesen Kanal automatisch ein neuer Access Token abgerufen (und im Kanal hinterlegt), falls (9) abgelaufen ist (bzw. schon 20 Sekunden davor). Dabei wird auch (9) neu gesetzt. Zudem wird dabei auch der Refresh Token aktualisiert. Verwenden Sie dazu die folgende URL: https://<server>/oauth/token?grant_type=refresh_token&refresh_token=<refreshToken>&client_id=<clientId>&client_secret=<clientSecret>

Es sind in der URL auch System-Konstanten erlaubt. Die entsprechenden Werte für die Platzhalter (siehe Tooltip in GUI) werden aus (6) entnommen oder wie bei <server> aus dem Feld Partner-Adresse. Der Wert für <server> muss der Endpoint URL entsprechen, ersetzen Sie den Platzhalter also im Bedarfsfall in der URL manuell mit diesem Wert.

Hinweis: Sie können den Zusatz &useCredentialsInHeader angeben, damit die Credentials (client_id und client_secret) im Header statt im Body angegeben werden. Sie können den Zusatz &useJSON angeben, dann wird die HTTP-Methode POST verwendet mit Content-Type application/json. Alle Einträge &param=value in der Query werden dann zu {"param": "value", ...} umgebaut. In diesem Fall sollten die Werte auf keinen Fall URL-encoded sein!

Hinweis: Nicht alle Authorization Server liefern einen Refresh Token (ist optional). Beim Grant Type Client Credentials ist laut RFC sogar explizit kein Refresh Token vorgesehen. Wenn nun tatsächlich vom Authorization Server kein Refresh Token geliefert wird, funktioniert die oben angegebene URL natürlich auch nicht. Wenn nun der initial abgeholte, siehe Abschnitt OAuth 2.0 (Client), Access Token abläuft, kann man dieses Feld auch verwenden, um automatisiert erneut einen "initialen" Access Token abholen zu lassen. Beim Grant Type Authorization Code funktioniert das aber nicht, da hier Sie hier ja auf einer externen Seite manuell Zugangsdaten eingeben müssen. Verwenden Sie zu diesem Zweck folgende URLs.

Client Credentials: https://<server>/oauth/token?grant_type=client_credentials&client_id=<clientId>&client_secret=<clientSecret>

Password Credentials: https://<server>/oauth/token?grant_type=password&client_id=<clientId>&client_secret=<clientSecret>&username=xxxxx&password=xxxxx

(8) Hier kann der Refresh (7) zu Testzwecken manuell ausgelöst werden. Siehe auch Funktion refresh OAUTH2 access token(a,b,c,d,e,f,g,h,i). Hinweis: Siehe auch https://www.rfc-editor.org/rfc/rfc6749#section-1.5 und https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/.

(9) Wurde über (6) oder (8) ein OAuth2 Access Token abgerufen, dann wird hier automatisch die Ablaufzeit eingetragen.

(10) Siehe Abschnitt Partner-Zugang (Partner zu mir).

(11) Siehe Abschnitt Partner-Kontakt.

(12) Siehe Abschnitt Zusatzkennungen (im Kanal).

(13) Wenn Lobster_data als HTTP-Server auftritt, ist eine Authentifizierung des Clients per OAuth2 möglich. Hinweise: Kann abgeschaltet werden in der Konfigurationsdatei ./etc/startup.xml mit dem Eintrag <Set name="enableOAuth">false</Set>. Der Access Token ist 30 Tage gültig. Kann geändert werden mit der System-Property hub.datawizard.oauth.expiresIn=Anzahl_in_Sekunden. Zum clientseitigen Ablauf siehe Abschnitt OAuth 2.0 (Client).

Authorization Endpoint: <URL des Integration Servers>/dw/register/oauth/authorize

Token Endpoint: <URL des Integration Servers>/dw/register/oauth/token