Locked Mode — Tab-Sichtbarkeit für Nicht-Admin-Benutzer konfigurierbar

[tomkenobi]

Zuerst einmal vielen Dank für den Client und die aktive Weiterentwicklung — ein wirklich durchdachtes Projekt. Wir ziehen ihn als mögliches Kommunikationsmittel für eine spätere Ausbaustufe in Betracht. Eine Anregung hätte ich dazu:

Use-Case

Wenn der Client von mehreren Personen am selben Gerät genutzt wird (z.B. Vereinslokal, Schulung, Veranstaltung, geteilte Station), möchte ich als Admin verhindern, dass Mitbenutzer versehentlich Kanal- oder Node-Konfiguration ändern. Aktuell sind alle Tabs für alle Benutzer gleich sichtbar und bedienbar.

Vorschlag

Ein einfacher „Locked Mode":

• Admin-Toggle in den Settings, geschützt durch ein Passwort
• Konfigurierbare Liste, welche Tabs für Nicht-Admin-Benutzer sichtbar sind

Beispiel-Setup an einer geteilten Station: nur Map + Chat + Traceroute sichtbar, Channel-, LoRa- und MQTT-Konfiguration ausgeblendet.

Zweck

Versehens-Schutz, kein Angriffs-Schutz — physischer Node-Zugriff (BLE-PIN am Display) bleibt davon unberührt. Es geht ausschließlich um die App-Schicht.

Frage

Wäre so ein Feature grundsätzlich willkommen? Falls ja, beteilige ich mich gerne an Konzept, Tests und — mit Unterstützung — an der Umsetzung.

[SMLunchen]

Hi @tomkenobi - danke für deinen Beitrag!
ich hab mal drüber seniert und versteh den Wunsch.
Das ist definitiv implementierbar. So wie die Einstellungen aktuell gespeichert werden (.ini) ist es natürlich kein richtiger Schutz. - Das Passwort könnte aber als PBKDF2 mit Salt abgelegt werden. Damit ist es nicht als Klartext lesbar. (kann aber im Zweifel einfach rausgelöscht werden)
Die Tabs die ausgeblendet werden sollen könnten dann ebenfalls in der INI Datei stehen.
Vorschlag:
wir führen in den Einstellungen einen Punkt ein "Schulungsmodus" (Name t.b.d.) - Dort geht dann eine Abfrage auf: Passwort eingeben, Passwort wiederholen, welche Tabs sollen ausgeblendet werden. (Checkbox Liste)
Danach kanns mans über ein kleines UI icon im footer durch Passwort-Eingabe entweder temporär oder dauerhaft deaktivieren.

Die hinterliegenden Funktionen müssen trotzdem mit gesperrt werden. - Also nur Ausblenden reicht nicht. - Sowas wie Remote Admin, Zeit Sychronisieren, Favoriten - das schreibt ja auch. das wollen wir u.U. ja auch verhindern. - Meshhessen Schnellkonfiguration schreibt ebenfalls.

Hinweis für so ein Schulungsszenario:
Wenn du die vNode aktivierst, kannst du beispielsweise einen Trainer PC nehmen und mit der Hardware - Node verbinden, dann den vNode aktivieren. - Admin-Befehle von Clients blockieren auf aktivieren.
Dann nimmst du die einen Trainigs-PC - dort kannst du auf die vNode des Trainers verbinden. - Änderungen die dann über den Trainings-PC gesendet werden, und dem Admin-Command Protobuf entsprechen (6 = ADMIN_APP) werden einfach gefressen. - damit kann auch nichts verstellt werden (am Node) - der Client auf dem Trainings-PC schon. ;)

was denkst du?

[tomkenobi]

Hi @SMLunchen - klasse Antwort — danke fürs gründliche Durchdenken!

Punkt 1 (Funktionen sperren, nicht nur Tabs ausblenden): voll dabei, das ist der Kern. Weil es reiner Versehens-Schutz ist, muss alles Schreibende hart gesperrt sein (Remote Admin, Zeit-Sync, Favoriten, Schnellkonfig) — reines Ausblenden räumt nur die Oberfläche auf.

Punkt 2 (PBKDF2 + Salt): passt genau. Löschbar aus der .ini ist okay — es geht bewusst um Versehens-, nicht Angriffsschutz.

Punkt 3 (vNode): Die Virtual-Node-Funktion im Tools-Tab (mit „Admin-Befehle blockieren") hab ich in der README gefunden - magst du das Trainer/Trainee-Setup, das du beschreibst, kurz damit einordnen? Für meinen unmittelbaren Fall (unten) ist primär der App-seitige Locked Mode relevant, aber den vNode-Weg würde ich gern verstehen.

Hintergrund/Use-Case: Ich komme aus dem operativen Zivilschutz (Führungsstab) und prüfe den Client für ein Notfallkommunikations-Konzept. Fixe „Leuchtturm"-Stationen sollen von Laien-Bedienern getippte Standardmeldungen (Mustervorlage einfügen) an den Führungsstab senden, um den Sprechfunk zu entlasten. Empfangsseitig laufen die als Text in MeshMonitor auf (bei uns mit eigenem, offline-fähigem Tileserver). An den Stationen soll sichtbar bleiben: Map + Chat (ggf. Traceroute); Config-Tabs weg, Schreibfunktionen gesperrt — deine Checkbox-Liste trifft das ideal.

Zum Namen: „Schulungsmodus" passt fürs Training, deckt meinen „fixe/geteilte Station"-Fall aber nicht ganz — evtl. neutraler wie „Kioskmodus"? t.b.d. Konzept + Tests mache ich gern mit.

[SMLunchen]

@tomkenobi
schau mal hier
https://github.com/SMLunchen/mh_windowsclient/releases/tag/v1.5.13-alpha-kiosmode
... btw. der meshhessenclient Tile - Server liefert nun auch österreich aus. (DACH Region)
Vermutlich werd ich in den nächsten Tagen mal eine neue Version rausbringen, die hoffentlich mit Vectortiles arbeiten kann. In der Hoffnung dass das die map nennenswert beschleunigt.

[tomkenobi]

Servus @SMLunchen - großartig, danke Dir! Dass Du den Kioskmodus so schnell als Alpha rausgebracht hast, freut mich wirklich.

Ehrlich gesagt konnte ich die v1.5.13-alpha-kiosmode noch nicht testen — am Dienstrechner geht's (noch) nicht, und daheim ist mir gestern die Zeit ausgegangen. Ich hole das zeitnah nach und gebe Dir dann konkretes Feedback zum Locked Mode (Tabs ausblenden + hartes Sperren der Schreibfunktionen).

Der vNode-Weg für Trainer/Trainee, den Du beschrieben hast, klingt richtig spannend — den probiere ich auf jeden Fall aus. Gerade das serverseitige „Wegfressen" der ADMIN_APP-Commands (Type 6) ist genau die Absicherung, die ich mir für die geteilten Stationen vorstelle.

Und schön, dass Dein Tile-Server jetzt auch DACH ausliefert! Bei uns läuft im Blackout-Fall zwar ein eigener Offline-Tileserver, aber für Normalbetrieb und Tests ist das top — auf die Vectortiles-Version bin ich gespannt.

Melde mich, sobald ich's getestet hab. Danke nochmal fürs gründliche Umsetzen! Ich hoffe, dass das auch für euch eine sinnvolle Ergänzung ist.