Authentication gegen FHEMWEB

[PatrickR]

Guten Morgen!

Da es im FTUI 2.6-Thread untergegangen ist, hier der zweite Versuch:

Ich hatte vor Monaten mal probiert, über fhemweb_url via
Code: [Auswählen]
<meta name="fhemweb_url" content="http://user:pass@host:8083/fhem">
Authentication zu FHEM hinzubekommen. Gibt's dafür zufällig schon eine Lösung? Das wäre sehr hilfreich.

Patrick

[Familienpapi]

Ist etwas offtopic: auf Android verwende ich den Fully Kiosk Browser. Auch die kostenlose Version kann Authorisierung und funktioniert. Das Passwort ist da auch nicht sichtbar. Und so als Vollbild ohne irgendwelche Leisten ist es auch schöner.

gesendet von meinem Note via Tapatalk

[PatrickR]

Hi! Meine Frage bezog sich auf die Verbindung FTUI<->FHEM. Die ist insb. dann wichtig, wenn FHEM nicht die FTUI-Seiten ausliefert sondern bspw. ein Apache.

Patrick


Von unterwegs gesendet.

[PatrickR]

Mahlzeit!

Ich habe mir das Thema mal selbst angesehen. Offenbar ist das Problem mit überschaubarem Aufwand lösbar, nämlich durch Erweiterung der jQuery.ajax()-Objekte wie folgt:

Code Auswählen Erweitern


            beforeSend: function (xhr) { //DEBUG: pr
              xhr.setRequestHeader ("Authorization", "Basic " + "aGllcjpnaWJ0c25peHp1c2VoZW4=");
            }

So wie es aussieht - ohne die Funktionsweise von FTUI im Detail zu kennen -, ist das an maximal 4 Stellen in fhem-tablet-ui.js der Fall und leider auch in 10 widgets.
aGllcjpnaWJ0c25peHp1c2VoZW4= ($user:$password als base64) würde man dann in einen META-Tag-packen.

@setstate: Ist das machbar?

Patrick

[setstate]

machbar ist alles, aber bei der Zeit und beim Interesse am Thema sieht es eher eng aus.

[PatrickR]

Hi!

Danke für die ehrliche Rückmeldung.

machbar ist alles, aber bei der Zeit und beim Interesse am Thema sieht es eher eng aus.

Ich bin persönlich immer ein Anhänger von "Erst die Pflicht, dann die Kür." und sehe Sicherheit als Ersteres. Zumal mir ehrlich gesagt etwas unwohl dabei ist wenn ich an die Setups mancher Tablet-UI-Nutzer denke, bei denen die Verbindung UI->FHEM offen über's Internet geht.

Wie kriegen wir die Kuh vom Eis? Würdest Du Dir einen Patch ansehen, wenn ich mich daran probiere?

Patrick

[setstate]

Wo soll denn User und pw hinterlegt sein? Doch nicht in Klarschrift im HTML?

[PatrickR]

Hallo Setstate!

Wo soll denn User und pw hinterlegt sein? Doch nicht in Klarschrift im HTML?

Grundannahme und damit Designentscheidung von Tablet UI ist, dass man jedem, der die Seite aufrufen kann, voll vertrauen kann. Das könnte man - und so verstehe ich Deinen Hinweis - zu Recht hinterfragen. Das möchte ich hier aber garnicht. Da aus dem o. g. Grund der Browser jeglichen Code ausführt, um mit FHEM zu kommunizieren, muss er auch Benutzername und Passwort (oder Werte, die sich in diese transformieren lassen) kennen. Das geht - man ergänze gerne - u. a. durch:

• Erfragen der Daten beim Nutzer und Ablegen auf dem Client, z. B. in einem Cookie.
• Ablegen der Daten im Code der Seite - Ob man sie im JS oder in der Seite selbst versteckt und wie man sie ggf. obfuscated macht Unter dem Strich keinen Unterschied.

Da es ohnehin sinnvoll und mit Bordmitteln möglich ist, den Zugriff auf die TabletUI-Seite gesondert abzusichern, finde ich Ansatz 2 vollkommen ausreichend. Konkret würde ich, wie oben beschrieben, den base64-Wert in einem META-Tag ablegen. Das spart dem Browser das Encoding, macht die Anmeldedaten erst auf den zweiten Blick sichtbar und ist verglichen mit Ansatz 1 von überschaubarem Aufwand.

Bitte verstehe mich nicht falsch. Ich verwendet TabletUI mit steigender Begeisterung und habe inzwischen meine Suche nach einer flexiblen FHEM-iOS-App (nach dem Kauf aller im App Store verfügbaren) durch Realisierung in TabletUI beenden können. Daher ist es für mich unverzichtbar geworden, ich würde aber gerne dennoch mein FHEM besser absichern.

Patrick

[setstate]

base64-Wert in einem META-Tag ablegen

Also würde ich anstatt

Code Auswählen Erweitern

'Authorization': 'Basic ' + btoa('myuser:mypswd')

gleich das aufrufen

Code Auswählen Erweitern

'Authorization': 'Basic ' + 'bas64String'

Erwarten die Server immer ein base64 Wert? Ich kenne mich da nicht aus?
Muss sich dann jeder den base64 Wert selbst erzeugen? Ist das nicht zu umständlich?
Ich will das, wenn schon, allgemein für alle gestallten.

[PatrickR]

Hi!

Erwarten die Server immer ein base64 Wert? Ich kenne mich da nicht aus?

So wie ich das sehe bei Basic ja: https://en.wikipedia.org/wiki/Basic_access_authentication unter Protocol->Client side
So habe ich es bei mir auch getestet, wenn auch zugegebenermaßen nur kurz.

Muss sich dann jeder den base64 Wert selbst erzeugen? Ist das nicht zu umständlich?
Ich will das, wenn schon, allgemein für alle gestallten.

Du hast vermutlich Recht, den Nebenkriegsschauplatz kann man sicherlich vermeiden.

Wenn Du einen Tester brauchst, sag Bescheid.

Patrick

[setstate]

Wenn im FHEMWEB basicAuth angeschaltet ist, funktioniert Longpoll mit Websocket nicht. Oder übersehe ich da was?

Was ist nun besser: wenn "myUser:myPass" oder "D135336HF=" (base64 Token) im HTML als Meta Tag hinterlegt wird? Im FHEMWEB wird als Attribute der base64 String erwartet. Ist also nichts unbekanntes für interessierte User. 

[CoolTux]

Sehe ich das richtig das es dann nur bei base64 geht. Es ist ja so das man da auch Perlfunktionen nehmen kann.
Auch glaube ich mich zu entsinnen das Rudi in den letzten Tagen da auch noch SHA256 Hash mit eingearbeitet hat. Kann mich aber auch irren.

https://forum.fhem.de/index.php/topic,67192.msg589351.html#msg589351

[setstate]

Dann ist es ja besser, wenn der credentials String im Header direkt benutzt wird, dann ist der User für die richtige Codierung verantwortlich.

[PatrickR]

Wartet mal. Der Hinweis mit SHA256 macht mir Sorgen. Das muss ich mir ansehen.


Von unterwegs gesendet.

[PatrickR]

Hi!

Sorry. Habe mal geschaut. Ich hatte die Befürchtung, dass Rudi Digest Authentication einbauen möchte. Das hätte die Implementierung verkompliziert. Hatte aber einen Denkfehler, so dass alles wieder im grünen Bereich ist.

Zur Frage ob user/pass in der Website als base64 oder im Klartext abgelegt werden sollen. Um den Supportaufwand klein zu halten tendiere ich inzwischen zu setstates Ansatz, den Klartext abzulegen und btoa() im JS durchzuführen.

Rudis Änderungen haben übrigens auf Tablet UI keine Auswirkungen, da sie nur die Speicherung der Daten in FHEM betreffen. "Über die Leitung" gehen aber die gleichen Daten.

Patrick