Feuersoftware

[rudolfkoenig]

Die gezeigte Meldung mit EOF kommt, wenn der HTTP Header nicht mit 2-mal \n (oder \r\n) abgeschlossen wird.
Soweit ich weiss, das ist Standard.

[Johannes B.]

Danke!

Habe eben testen können, tatsächlich kommt ein EOF, wenn man den Autorization-Header nicht mitschickt. Deine Lösung, den Benutzernamen und das Passwort voranzustellen scheint nicht zu klappen bzw. scheint von der Feuersoftware nicht unterstützt zu werden.
Du kannst die Log-Einträge auch lokal reproduzieren, wenn du bei deinem curl-Aufruf mal den Benutzernamen und das Passwort am Anfang weglässt.

Spontan fällt mir ein, dass du einen Reverse Proxy davorschaltest, dem du dann einen Pfad angibst, der einen "Access Token" darstellt, also z.B. dann

Code Auswählen Erweitern

https://XXXXXXX.duckdns.org:1121/<HIER IRGENDEIN SEHR LANGER STRING>/fhem?cmd=<BEFEHLE>&fwcsrf=XXXXXXXXXXXXXXXXaufgerufen wird.

Ob man das sonst irgendwie mit FHEM-Bordmitteln sicher hinkriegt (oder sogar "nur" mit dem CSRF-Token? Wenn man sonst das Web-Interface komplett abschaltet?) – keine Ahnung, ich habe für solche Fälle bis jetzt immer die Reverse Proxy Lösung genutzt, evtl. weiß jemand anderes hier mehr.

Alternativ natürlich mal bei der Feuersoftware nachfragen, ob die irgendwie auf einem anderen Weg HTTP-Basic-Auth unterstützen.

Wenn ich Benutzername und Passwort mal weg lasse, bekomme ich die nächste Fehlermeldung:

Feuersoftware:

Fehler beim Senden der Anforderung. Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..

FHEM Log

2024.01.25 20:01:24 1: Connection refused from the non-local address 51.116.126.93:5760, as there is no working allowed instance defined for it
2024.01.25 20:01:24 1: Connection refused from the non-local address 51.116.126.93:5761, as there is no working allowed instance defined for it

[passibe]

Da ist jetzt irgendetwas mit deinem allowed Device falsch. Ist das noch richtig zugeordnet? Wenn du es zu Testzwecken rausgenommen hast, musst du mal im allowfrom im FHEMWEB-Device die IP des Feuersoftware-Servers eintragen (auch nur zu Testzwecken, natürlich); siehe hier.

Achtung, das läuft als Regex, bei dir müsste also 51\.116\.126\.93 drinstehen.

Edit: Und dann läuft natürlich lokal auf dem jeweiligen FHEMWEB-Device nichts mehr. Also im Zweifel noch die IP von deinem Computer getrennt mit | eintragen.

[Johannes B.]

Das hat funktioniert    
Sobald ich allerdings Benutzer und Passwort mit rein nehme gehts wieder nicht.

[passibe]

Sehr gut!

Dann ist es aber wie vermutet das Problem, dass die Feuersoftware nix mit dem <USER>:<PASS>@-Ding anfangen kann und dann den Basic-Auth-Header nicht setzt.

Dann Workaround wie von mir beschrieben, oder jemand hat noch eine andere Idee. Aber ich vermute mal vorsichtig, dass es schwierig werden könnte, um einen Reverse-Proxy herumzukommen, wenn du das ordentlich absichern willst.

[Johannes B.]

Habe gerade mal Feuersoftware per E-Mail angeschrieben ob die dafür ein Lösungsvorschlag haben wie man Benutzername und Passwort in der URL verwenden kann.

[Johannes B.]

Das kam gerade von Feuersoftware:

Hi Johannes,
aktuell gibt es nur die Möglichkeit, dass du deinem Webhook per Query-Parameter einen Authentifizierungsschlüssel mitgibst. HTTP Basic Auth unterstützen wir aktuell nicht.

[Wernieman]

Baue Dir doch einen eigenen FHEMWEB nur für die Feuersoftware. Dann kannst Du nur diese auf die IP der Feuersoftware einschränken und auch die Möglichkeiten minimieren, was dort erlaubt ist. ABER .. trotzdem ist es natürlich eine Lücke ....

[passibe]

Habe gerade gesehen, dass du sowieso schon Apache am laufen hast. Wenn das so ist, dann kannst du da relativ einfach einen neuen listening Port vergeben, den forwarden, Apache als Reverse Proxy konfigurieren und den Token als "Unterordner" direkt in die URL einbauen (so wie ich oben beschrieben habe).

Apache kann dann auch direkt den Basicauth-Header mit an FHEM übermitteln, dann kannst du dein Allowed-Device auch so lassen wie es ist und kannst im FHEMWEB-Device allowfrom einfach auf die IP von der aus Apache seine Requests sendet setzen.

In Apache musst du dann natürlich noch dein letsencrypt-Zertifikat angeben, FHEMWEB kannst du dann im Zweifel nur mit HTTP laufen lassen (ist ja dann nur intern).

Das dürfte unter den gegebenen Umständen die sicherste Lösung sein ...