@aiole
Genau deshalb bevorzuge ich:
- An / Aus
- User
- Pass
- Host
- Lesende Topics
- Schreibende Topics
Das ist schon komplex genug, bietet aber für alle Fortgeschrittenen genug Möglichkeiten.
Wer sich mit auskennt macht das ohnehin per SSH direkt in der Config.
Allerdings ist MQTT wesentlich unkritischer als HTTP der openWB nach außen freizugeben.
Über MQTT siehst du die Daten die published werden, so gesehen die "Hauptseite"-
Heißt Leistungsdaten. Bei schreibendem Zugriff kann der Lademodus / Stromstärke verstellt werden.
Bei Freigabe von HTTP sind tendenziell alle Daten (User / Pass von SoC Modulen) sichtbar.
Geanu das ist mein Ziel. Der Ansatz war grundsätzlich eine "geführte, sichere Konfigurierbarkeit" von MQTT-Bridging die auch der Otto-Normal-User sicher benutzen kann.
Als Szenario sehe ich da Nutzer die z.B. für andere Zwecke bereits rein UI-konfiguriertes MQTT nutzen. Da sehe ich einfach steigenden Bedarf. Solche Nutzer greifen sonst zur nicht-verstandenen "Google"-basierten konfiguration. Das ist bestimmt nicht besser.
Obiges reicht dafür ja schon!?
Vor einem Einspielen von rein benutzerdefinierten Konfigs habe ich persönlich, zu viel "Angst". Denn entweder validiert man gar nichts, mit dem Risiko jegliche (nicht nur Sicherheits-) Ansätze zu torpedieren und somit für erhöhten Support zu sorgen (kaputtes openWB UI, ...). Oder man verbringt sehr viel Zeit mit der Implementierung einer Validierung (und versucht dabei alle möglichen Fehlkonfigurationen vorher zu sehen
).
So viel Zeit hab ich leider nicht. Zudem sollten "Experten" problemlos in der Lage sein Konfigurationen per SSH einzuspielen. Deshalb würde ein PR meinerseits keine Upload-Funktion enthalten.
Eine Konfiguration über MQTT sehe ich noch viel gefährlicher. Da hat man sich ganz leicht selbst ausgesperrt: Lädt man z.B. versehentlich per MQTT eine kaputte Konfig hoch geht die Bridge danach nicht mehr und man kann den Fehler nicht korrigieren. Außerdem wäre das auch sehr viel mehr Implementierungsaufwand für den "Hintegrunddienst" (oder Hook im Regelintervall) der nach neuen Konfigs im MQTT-Broker sucht.
Wie schon erwähnt, da bin ich bei dir.
Eine extra Config Datei um eine Bridge zu erstellen mit den obigen Parametern. Nicht mehr, nicht weniger.
Ich sehe das in der openWB derzeit eher "zweischneidig" und bestimmt noch nicht "TOP": Immerhin ist das WebUI und der MQTT-Server der openWB völlig ungeschützt von allen Hosts mit Zugriff auf das Netzwerk-Segment der openWB erreichbar. Allein das ist m.M.n. brandgefährlich wenn man eben von den hier vermuteten "sehr unbedarften Nutzern" ausgeht. Die konfigurieren dann halt ein Portforwarding ohne zu wissen was sie tun. Ganz zu schweigen davon daß nicht jedes LAN automatisch "sicher" ist (unsicheres WLAN, unauthorisierter Zugriff auf LAN-Dosen, ...). All das kann die openWB nicht verhindern.
Bei einem normalen Hausnetzwerk ist davon allerdings auszugehen und allemal besser als irgendein Clouddienst der pauschal alles nach Hause schickt.
Die openWB wäre allerdings trotzdem halbwegs sicher, würde sie wenigstens TLS (self-signed cert) und Authentication im Web UI und Mosquitto nutzen! Derzeit ist sie dagegen eines von Millionen IOT-Devices die dann offen im Internet rum schwirren (siehe
https://www.shodan.io/search?query=openWB - ergibt gottlob zum Zeitpunkt da ich diesen Text schreibe nur eine!)
Der Sicherheitsgewinn wäre minimalst, mal davon ausgehend das 99,9% der Kommunikation lokal im Hausnetz erfolgt.
Zudem weckt es womöglich die falsche Erwartung das ein Port Forwarding mit aktiviertem https sicher wäre (nein, ist es nicht).
Ich hab den Leaf Fahrer aus der Schweiz mal angeschrieben (https hätte hier nichts geändert)...
Der Support Aufwand wenn alle Browser wegen selfsigned meckern kannst/willst du dir nicht vorstellen.
Es wird definitiv immer Möglichkeiten geben wie "unbedarfte Nutzer" die Sicherheit selbst untergraben. Ist es wirklich Aufgabe der openWB all diese Fälle zu unterbinden? Und das auf Kosten der "offenen Plattform" welche die openWB eigentlich ist?
Nein, darum soll es ja die Möglichkeit geben simpel eine Bridge zu erstellen.
Es gibt die Möglichkeit die Daten weiter zu verarbeiten, ohne gleich alle Daten preis zu geben.
Schlussendlich liegt es immer noch am Nutzer ob dann jeder sieht was die PV gerade bringt.
Der Warnhinweis das ein publishen an externe Server nicht empfohlen wird, wird natürlich mit drinnen stehen.
)
