Zusätzliche Authentifizierungsarten beim HTTP Client

Funktionswünsche IP-Symcon
1

Gerade für die Abfrage von (JSON) APIs wird oft eine Authentifizierung mit API Token (aka Bearer Token) oder einem ähnlichen Verfahren benötigt. Derzeit kann man das leider mit dem HTTP Client nicht abbilden.

Sinnvoll (weil weit verbreitet) wären folgende Authentifizierungsformen:

  • Bearer Token (Authorization Header)
  • API Key (via Header oder Query Param)
  • JWT Bearer (schwieriger zu implementieren, via Header oder Query Param)
  • AWS Signature

Zumindest eine Implementation der ersten beiden wäre immens hilfreich!

2

Wir werden zur 7.2 anbieten, dass man die Header selber mitgeben kann. Das sollte viele Use-Cases gut abbilden. Das hatten wir übrigens schon länger vor, aber irgendwie immer vergessen :wink:

paresy

1 „Gefällt mir“
3

@paresy Super, danke!

4

Das Problem ist jedoch es geht ja nicht nur darum den Token mit zu schicken.
Man muss diesen ja anfragen und braucht da auch eine Fehlerbehandlung

  • was passiert wenn der Token abgelaufen ist
  • was passiert wenn die Zugangsdaten nicht gültig sind
    -was passiert wenn der Server nicht das liefert was man erwartet
5

Dafür müsstest du dann doch ein Modul schreiben. Hier geht es eher um simple API Aufrufen, die ein festes, nicht-ablaufbaren Token haben.

paresy

6

Da ich meine Skripte mit curl bisher nur mäßig verstanden habe (Generated by curl-to-PHP: curl-to-PHP: Convert Curl commands to PHP code), habe ich mich mit dem Header im http-Client befasst und tatsächlich auch verstanden.
Ich hatte gehofft, dass ich damit die Skripte evtl. ablösen kann. Jedoch bin ich drauf gestoßen, dass ja in der URL oft noch ein Pfadparameter https://url/api/v1/{Parameter} enthalten ist.
Gibt es eine Möglichkeit, auch diesen Pfadparameter zu setzen?

Und bei einem http-POST gibt es noch einen Body. Gibt es dazu auch eine Möglichkeit außer Skript mit curl?