ich habe eine technische Frage zu den API Verbindungen.
Ich muss wie bei Plentymarkets mittels eines API Calls einen Bearer Token abfragen und anschließend diesen für die restlichen Calls verwenden.
In euren HTTP Verbindungen kann ich aber bei Bearer nur direkt den Bearer Token speichern. Der läuft aber regelmäßig ab und muss somit neu gespeichert werden.
Die restlichen Typen funktionieren leider nicht, da ich nicht entscheiden kann was im Body bzw. als Header (mehrere Header-Zeilen) übergeben wird.
Jetzt bin ich etwas aufgeschmissen und habe den Call erstmal direkt im Flow gebaut und kriege dort auch den Bearer Token raus. Diesen muss ich aber irgendwie global speichern und anschließend in den SpreadsheetUrlDownload integrieren.
Aber nur, falls du es mal für eine andere API brauchst. Hierbei beherrscht der HTTP Account dann auch die automatische Erneuerung des Tokens nach Ablauf.
Ich habe jetzt auch den Fall, dass ich eine handvoll Calls über den APICall-Step an Plenty schicken will. Ich habe dazu z.B. den HTTP-Account plentyAPIUser-Tornado eingerichtet. Jetzt hatte ich den eine Weile nicht genutzt und der Bearer Token war abgelaufen. Zur erneuten Autorisierung habe ich einen eigenen APICall mit /rest/login genutzt und dann den ausgegebenen Token in der Verbindung eingetragen.
Gibt es da auch einen besseren (automatischen) Weg? Der Step PlentyRESTAuthenticate authentifiziert mir ja nur die Verbindung vom Typ Plentymarkets und nicht vom Typ HTTP, oder?
Ihr habt geschrieben, man könnte das ggf. über OAuth machen, wie müsste ich dafür die Verbindung denn konfigurieren damit das mit Plenty dynamisch läuft?
Der PlentyRESTAuthenticate Step gibt den (neuen) Token als Output aus. Diese Token könntest du im Feld requestHeaders der HTTP Steps (API, UrlDownload, SpreadsheetUrlDownload) verwenden: Authorization=Bearer ${token@PlentyRESTAuthenticate_??!}
Über die HTTP Verbindung sollte es auch funktionieren:
type: OAuth 2.0
Grant Type: Client Credenditials
Client ID & Secret: irgendwas eintragen, nicht verwendet
Token URL: https://www.example.com/rest/login?username={{username}}&password={{password}}
ich habe bei einem Projekt dasselbe Problem. Leider funktioniert die Konfiguration des OAuth2-Accounts aber nicht, ich erhalte immer die Nachricht, daß die Seite nicht existiert. Im Einzelnen sieht es bei mir so aus:
ist die Token Url korrekt? Wenn ich diese Url (ohne Parameter) z.B. mit Postman aufrufe, bekomme ich auch „Entschuldigung. Die Seite existiert nicht!“.
Wichtig ist noch: Der Workarround aus diesem Thread funktioniert nur, wenn die API bei Aufruf der Token Url eine OAuth 2 konforme Antwort liefert. Diese sollte in etwas so aussehen:
Hi Torsten,
die URL ist korrekt. Das Problem ist, daß username/password im Body übergeben werden müssen:
{
„username“: „{{User}}“,
„password“: „{{PW}}“
}
Ich kann die Daten also nicht in die URL mit reinschreiben, da das ja header-Angaben sind. Gibt es denn keine Chance, eine Verbindung so aufzubauen, daß ihr zusätzlich zur auth-token-Zeile auch noch die Möglichkeit schafft, ggf. einen solchen Body zu übergeben?
Du kannst nochmal den GrantType „Passwort“ probieren. Da wird der username / password Wert per POST an die Token URL geschickt, allerdings nicht als JSON (wie in deinem Beispiel) sondern mit ContentType („application/x-www-form-urlencoded“)
Wenn es zwingend ein JSON Body sein muss, können wir das sicher noch einbauen. Bei GrantType „client credentials“ haben wir schon eine Option („Request Content Type“) dafür. Voraussetzung damit es dann funktioniert ist aber, dass die API eine OAuth 2 konforme Response liefert (siehe Screenshot oben). Wenn das nicht der Fall ist, bleibt nur der „manuelle“ Weg im Flow per UrlDownload/APICall, um den Token zu holen.
Das mit Grant type=password hatte ich schon mal probiert, das funktionierte nicht. Es muß im Body übergeben werden. Allerdings sieht die erfolgreiche Antwort solchermaßen aus:
{
„token“: „…“
}
Das entspricht nicht den Anforderungen, fürchte ich
nein, dann funktioniert es leider nicht mit einer OAuth 2.0 HTTP Verbindung. Die Feldnamen in der response müssen passen (access_token, expires_in, …).
