Add URL Display Theme for Raspberry Pi

[MartinRinas]

Introduce a new URL display theme for Raspberry Pi, enabling users to connect to a specified URL.

[benderl]

Danke für das Display Theme.

[MartinRinas]

@benderl danke fürs Review, hab' jetzt auch eine mini-build pipeline via package.json und ein wenig Validierung gegen die URL.

[benderl]

Sieht auf jeden Fall professioneller aus, als vorher. 👍
Gibt es einen Grund, warum Du die alte 6.x Version von Vite verwendest? Bei einem neuen Projekt wäre ich mindestens auf 7.x, wenn nicht sogar die brandneue 8.x gegangen. Das erspart in Zukunft ein bzw. zwei Migrationen.

[MartinRinas]

Sieht auf jeden Fall professioneller aus, als vorher. 👍 Gibt es einen Grund, warum Du die alte 6.x Version von Vite verwendest? Bei einem neuen Projekt wäre ich mindestens auf 7.x, wenn nicht sogar die brandneue 8.x gegangen. Das erspart in Zukunft ein bzw. zwei Migrationen.

hm im Grunde nicht, ich werde meinen Mitarbeiter Copilot da noch mal drauf ansprechen. Kann mir keinen Grund vorstellen da nicht gleich auf die aktuellse Version zu gehen.

[benderl]

Im Ordner .github/workflows kannst Du analog zu den anderen Display Themes eine Datei check_display_theme_url_display.yml anlegen.

Die Build-Dateien unter "web" gehören nicht in den PR. Das Theme wird automatisch nach dem Merge neu gebaut. Das wird in der Datei .github/workflows/publish_to_master.yml erledigt. Voraussetzung ist, dass es eine Aktion "build" in der package.json Datei gibt, was hier der Fall ist.

[benderl]

Wenn Du mit dem Theme fertig bist, bitte melden.

[MartinRinas]

@benderl habe fertig.
Das Theme wird läuft sauber wenn die openWB auf primary läuft. Auf secondary kann ich kein display theme konfigurieren, und selbst wenn ich die Konfig manuell überschreibe wird das nicht gezogen. Das ist aber ein separates Thema für ein neuen PR - schau' ich mich parallel an.

[benderl]

@MartinRinas
Hast Du das Theme lokal mit verschiedenen URLs schon getestet? Wir haben intern etwas Bedenken bezüglich der Systemauslastung bei komplexen und sehr aktiven Webseiten. Der RasPi 3b ist in Verbindung mit dem alten Treiber (nicht VK3D) nicht gerade ein Performance-Wunder.

Wir überlegen, wie man die Systemlast, oder besser die Last des Display-Prozesses, beobachten und ggf. das Display-Theme beenden kann, damit es nicht zu Problemen mit der Regelung kommt.

[MartinRinas]

ja, ich habe meine openWB seit Tagen mit der EVCC Oberfläche am laufen, vollkommen unauffällig. Läuft auch nach Tagen vollkommen flüssig, keine Verzögerung bei der Bedienung o.ä.

[MartinRinas]

Welcher Prozess würde denn tendenziell zu viel CPU verbrauchen, wäre das der Browser / die X session oder ähnliches? Könnte man dort mit Prozesspriorität (nice) arbeiten um der Regelschleife mehr Gewicht zu geben?

[benderl]

Kannst Du bitte mal nach der "load" Deines Systems und den Chromium-Prozessen sehen?

[MartinRinas]

gern, in etwa so oder wäre eine andere Ausgabe relevant?

[benderl]

Die Load sieht wirklich unauffällig aus. Kritisch ist immer der Chromium Render-Prozess, bei Dir die PID 10793.

Nicht schön ist aber, dass schon der Swap zu knapp 50% verwendet wird.

Ist bei Dir ein 3b oder 3b+ verbaut?

[MartinRinas]

Raspberry Pi 3 Model B Plus Rev 1.3

[benderl]

Kurzes Update:
Wegen der Systemlast prüfen wir noch, in wie weit sich das überwachen lässt und ggf. der Chromium beendet werden kann.

Was aber definitiv noch anzupassen ist: es dürfen nur URLs mit einer IP aus einem nicht öffentlichen Subnetz eingegeben werden. Hintergrund ist einfach, dass man seine openWB und potentiell das gesamt Heimnetz nicht durch eine "böse" Webseite kompromittieren kann.

Die Prüfung des Subnetz müsste an mehreren Stellen durchgeführt werden:

• bei der Eingabe der URL im Frontend
• im Display-Theme Modul bei der Instantiierung inkl. Entfernung der nicht zugelassenen URL
• optional eine zusätzliche Prüfung im Frontend des Display-Themes, sollte aber nicht notwendig sein, wenn das Modul ordentlich validiert

Kannst Du das so integrieren oder benötigst Du dafür Hilfe?

[MartinRinas]

klar, eine Validierung einzubauen ist sicher nicht so arg schwer. Ich schau' mal was mir das System vorschlägt.

Wobei mir der konkrete Angriffsvektor nicht klar ist. Um eine kompromittierte URL hinterlegen zu können muss der Angreifer ja bereits kontrolle über das System haben, also ein post-compromise. Angenommen das ist der Fall und es wird eine andere URL hinterlegt, wie genau würde der Angriffsvektor dann aussehen? Auf dem Display wird eine andere URL dargestellt, welches weitere Risiko geht davon aus? Es wird ja kaum jemand Zugangsdaten übers Display eingeben. Und Chromium sollte hinreichend abgesichert sein dass durch die reine Anzeige einer URL keine weitere Kompromittierung des Systems erfolgen kann, zumal es ja bereits eine Kompromittierung gegeben haben muss um in den Zustand zu kommen.

Zum Thema Systemlast, gibts vergleichswerte von den Display Themes welche mit der openWB kommen, wie hoch ist die Last dort? Kann man das Problem durch Anpassung der Prozessprioritäten für Chromium und Python Regelschleife nicht anpassen? So würde die Regelschleife immer genug CPU Zyklen bekommen, selbst wenn Chromium am Rad dreht.

[benderl]

Der Angriffsvektor ist einfach der potentiell veraltete, ungepatchte Chromium Browser. Wenn jemand die URL eines "super tollen Portals", was ihm irgend einen immensen Vorteil verspricht, einträgt und der Betreiber dieses "Portals" sich durch bekannte Schwachstellen auf der openWB einnistet, haben wir ein Problem.

Hauptanwendungsfall ist eine lokale URL von EVCC oder was auch immer die secondary ansteuert. Dann sollten wir es auch so beschränken, um nicht Tür und Tor zu öffnen.

[benderl]

Zum Thema Systemlast, gibts vergleichswerte von den Display Themes welche mit der openWB kommen, wie hoch ist die Last dort? Kann man das Problem durch Anpassung der Prozessprioritäten für Chromium und Python Regelschleife nicht anpassen? So würde die Regelschleife immer genug CPU Zyklen bekommen, selbst wenn Chromium am Rad dreht.

Die Animation im Energiefluss sorgt für eine Auslastung von ca. 90-100% (verteilt auf mehrere Cores). Die Load liegt bei meinem Testsystem ohne Ladepunkte, dafür Simulator, bei etwa 2. Ist demnach zum EVCC bei Dir auch kein großer Unterschied.