Feuersoftware

[Wernieman]

Wie mein Vorredner schrieb:
Für DNS-Authentifizierung brauchst Du einen DNS-Provider mit API-Steuerung. Also bei CloudFlare musst Du den Token bei CloudFlare einrichten.

Also die INI musst Du selber schreiben! Deshalb die Nachfrage nach dem Inhalt.

[Johannes B.]

Variante 2 (TXT-Record) wäre hier wohl die bessere Lösung – dann kannst du aber nicht MyFritz verwenden, weil du ja nicht auf AVMs Servern TXT-Einträge hinzufügen kannst. Das einfachste ist dann, dass du dich einer Lösung wie z.B. https://desec.io bedienst, die sich recht einfach mit Certbot verknüpfen bzw. automatisieren lassen dürfte (siehe hier). Dann gibst du der Feuersoftware einfach deine desec-Domain und alles ist gut.

Desec bietet derzeit keine dynDNS mehr an.

dynDNS registrations are suspended at this time. We do not process requests for exceptions.
Please do not contact support about this. You will have to register a domain elsewhere.

[passibe]

Ah, schade. Dann wie gesagt DuckDNS nehmen, das sollte funktionieren (https://www.duckdns.org/spec.jsp).

[Johannes B.]

DuckDNS habe ich am Wochenende mal eingerichtet, das funktioniert auch. Zertifikat habe ich erstellt. In der Feuersoftware ist der Fehler mit dem SSL Zertifikat verschwunden, jedoch zeigt er mir jetzt 

Authorization Required

an.
Bei Feuersoftware habe ich mal nachgefragt die Autorisierung ist kein Problem von ihrer Seite. Benutzer und Passwort habe ich aber vor die URL angehängt mit https://BENUTZERNAME:PASSWORT@xxxxx.duckdns.org... und den csrf Token hinten angehängt mit ...&fwcsrf=XXXXXXXXXXXX.
Verstehe nicht so ganz wo hier das Problem liegt. Wenn ich zum ausprobieren mal kurz Benutzername, Passwort und csrf Token rausnehme gehts auch nicht.
Die Adresse ist aber mit allem und Befehlen von anderen Netzwerken oder über Mobilfunknetz per Browser erreichbar.

[passibe]

Was bekommst du, wenn du die URL von deinem Computer aus mit curl im Terminal aufrufst?

Steht was im FHEM-Log? Ggfs. mal dein webhook-device auf verbose 5 setzen.

CSRF-Token sollte hier kein Problem sein, solange der fest gesetzt ist (sieht laut deiner webhook-Definition weiter oben aber so aus als hättest du das gesetzt, aber bitte nochmal überprüfen; wobei das dann eine andere Fehlermeldung sein sollte, glaube ich).

Alternativ kannst du natürlich kurz in einem Docker-Container o.ä. einen anderen Webserver aufsetzen, die Feuersoftware das aufrufen lassen und dort mal loggen lassen, was die Feuersoftware für einen Request macht und was der beinhaltet (oder per Wireshark mitlesen – falls du das über http laufen lässt/einen reverse Proxy davorschaltest).

[Johannes B.]

Probiere ich gleich mal aus.
Im Log finde ich das hier:

2024.01.25 19:08:07 4: Connection accepted from WEBhook_51.116.126.93_1985
2024.01.25 19:08:07 5: GET /fhem?cmd=set%20Einsatz_Info%20Adresse%20%7BAddress%7D;set%20Einsatz_Info%20Einsatzstichwort%20F1;set%20Einsatz_Info%20Sachverhalt%20%7BFacts%7D;set%20Einsatz_Info%20Standort%20Feuerwehr%20Musterstadt&fwcsrf=XXXXXXXXX HTTP/1.1
Host: XXXXXXX.duckdns.org:1121
Connection: Keep-Alive
2024.01.25 19:08:07 4: Connection closed for WEBhook_51.116.126.93_1985: EOF

Csrf habe ich manuell gesetzt, der ändert sich nicht mehr.

[Johannes B.]

mit curl bekomme ich das raus:

C:\Users\XXX>curl https://BENUTZERNAME:PASSWORT@xxxxx.duckdns.org:1121/fhem?cmd=set%20Einsatz_Info%20Status%20Komme&fwcsrf=XXXXXXXXXXXX
Der Befehl "fwcsrf" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

[Wernieman]

Windows ... versuche es mal mit " oder ' zu maskieren. Er versteht das hinter dem & als nächsten Befehl ...

[Johannes B.]

"&fwcsrf=XXXXXXXXXXXX" so hats funktioniert.

So sieht das ganze im Log aus:

Code Auswählen Erweitern

2024.01.25 19:29:59 5: GET /fhem?cmd=set%20Einsatz_Info%20Status%20Komme&fwcsrf=XXXXXXXXXXXX HTTP/1.1
Host: XXXXX.duckdns.org:1121
Authorization: Basic RmV1ZXJzb2Z0d2XXXXXXXXXXXXXXXXZnR3YXJlX3Rlc3Q=
User-Agent: curl/8.4.0
Accept: */*
2024.01.25 19:29:59 4: WEBhook_188.74.36.27_63492 GET /fhem?cmd=set%20Einsatz_Info%20Status%20Komme&fwcsrf=XXXXXXXXXXXX; BUFLEN:0
2024.01.25 19:29:59 4: authorize WEBhook/cmd/set: allowedWEBhook returned dont care
2024.01.25 19:29:59 4: authorize WEBhook/devicename/Einsatz_Info: allowedWEBhook returned allowed

Mein Dummy wird geschaltet

[Johannes B.]

Aber wenn die Url am Browser funktioniert und mittels curl auch warum geht es dann über die Feuersoftware nicht?

[Wernieman]

Ruft jetzt die Feuersoftware FHEM auf oder umgekehrt?

[Johannes B.]

Feuersoftware soll die URL von FHEM abrufen. Entweder wenn ich über die App die rückmeldung "Kommen" gebe oder wenn ein Alarm rein kommt.

Hier mal die Beispielanleitung von Feuersoftware für IFTTT.

[passibe]

Kann es sein, dass FHEM ein Problem mit den geschweiften Klammern, die im Testaufruf mit abgesetzt werden hat?
Probier mal den Testaufruf aus der Feuersoftware heraus etwas "einfacher", d.h. z.B. nur mit dem Standort oder so ...

Kann grade nicht selbst testen, ob geschweifte Klammern ein Problem sind (selbst wenn sie URL encoded sind), aber könnte ich mir vorstellen, dass FHEMWEB deshalb ein EOF schmeißt ...

[Johannes B.]

Auch mit diesem Aufruf aus der Feuersoftware:

Code Auswählen Erweitern

https://BENUTZERNAME:PASSWORT@XXXXXXX.duckdns.org:1121/fhem?cmd=set%20Einsatz_Info%20Status%20Komme&fwcsrf=XXXXXXXXXXXXXXXXschaltet mein Dummy nicht und im Log steht das hier:

Code Auswählen Erweitern

2024.01.25 19:44:38 4: Connection accepted from WEBhook_51.116.126.93_3008
2024.01.25 19:44:38 5: GET /fhem?cmd=set%20Einsatz_Info%20Status%20Komme&fwcsrf=XXXXXXXXXXXXX HTTP/1.1
Host: XXXXXX.duckdns.org:1121
2024.01.25 19:44:39 4: Connection closed for WEBhook_51.116.126.93_3008: EOF


[passibe]

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.