MUTEC – WebSocket-Steuerung: Unterschied zwischen den Versionen
MUTEC-Inbetriebnahme und Ticket-Projektzuordnung aktualisiert |
MUTEC-Inbetriebnahme und Ticket-Projektzuordnung aktualisiert |
||
| Zeile 164: | Zeile 164: | ||
Die Frontend-Version mutec4 versieht jede /verify-Anfrage mit einem unabhängigen, geheimnisfreien mutec_check-Parameter und cache:no-store. Eine 401 wird nach 250 und 750 Millisekunden mit neuer Adresse wiederholt. Nur ein erfolgreicher Prüfstatus erlaubt den Einstieg; drei 401 bleiben gesperrt. /enter-system wird dabei nicht erneut aufgerufen, fremde bereits verwendete Codes bleiben abgewiesen. Acht Frontend-Tests bestätigen unter anderem temporäre und dauerhafte 401 sowie die getrennte Behandlung von 403. Die Änderung schützt gegen veraltete Prüfantworten und kurze Übergangsfehler, belegt aber nicht, dass einer dieser Fälle die Ursache des gemeldeten Problems ist. Sieben Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt. Eine weitere Anmeldung mit frischem Testticket erreichte auf der veröffentlichten Version das Menü, auch mit einem Code mit führenden Nullen. Der tatsächlich verwendete Monitor https://www.megbes.de/tickets/tine/login.html und seine vier zugehörigen HTML-/JS-Dateien entsprechen den lokalen Quellen, verwenden tine und Monitor 1111 und werden mit no-cache/no-store ausgeliefert. Eine erneute Prüfung am betroffenen Ticket-Monitor steht aus. Keine MegBes-Backend-Änderungen und kein neuer Relay-Installationsschritt. | Die Frontend-Version mutec4 versieht jede /verify-Anfrage mit einem unabhängigen, geheimnisfreien mutec_check-Parameter und cache:no-store. Eine 401 wird nach 250 und 750 Millisekunden mit neuer Adresse wiederholt. Nur ein erfolgreicher Prüfstatus erlaubt den Einstieg; drei 401 bleiben gesperrt. /enter-system wird dabei nicht erneut aufgerufen, fremde bereits verwendete Codes bleiben abgewiesen. Acht Frontend-Tests bestätigen unter anderem temporäre und dauerhafte 401 sowie die getrennte Behandlung von 403. Die Änderung schützt gegen veraltete Prüfantworten und kurze Übergangsfehler, belegt aber nicht, dass einer dieser Fälle die Ursache des gemeldeten Problems ist. Sieben Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt. Eine weitere Anmeldung mit frischem Testticket erreichte auf der veröffentlichten Version das Menü, auch mit einem Code mit führenden Nullen. Der tatsächlich verwendete Monitor https://www.megbes.de/tickets/tine/login.html und seine vier zugehörigen HTML-/JS-Dateien entsprechen den lokalen Quellen, verwenden tine und Monitor 1111 und werden mit no-cache/no-store ausgeliefert. Eine erneute Prüfung am betroffenen Ticket-Monitor steht aus. Keine MegBes-Backend-Änderungen und kein neuer Relay-Installationsschritt. | ||
== Zur Auswahl: Trailer und IDLE == | |||
Die Frontend-Version mutec5 fordert beim Klick auf „Zur Auswahl“ die Freigabe mit DELETE /mutec-control-api/session?returnToTrailer=1 an. Das aktualisierte separate Relay prüft Ticket und aktive Belegung, sendet über die bestehende MegBes-API genau 50-Trailer und meldet anschließend die Station ab. Der BrightSign kann nach seiner Trailer-Umschaltung selbst IDLE melden. Senden und Freigabe werden in derselben Warteschlange ausgeführt, damit eine neue MUTEC-Sitzung nicht dazwischen übernehmen kann. Die normalen Feature-Befehlslisten werden nicht erweitert. | |||
Bei einem Sendefehler bleibt das Token im Browser erhalten und die Fehlermeldung erlaubt einen erneuten Versuch. Bereits entfernte oder fremde Sitzungen schicken keinen Trailer an einen neuen Bediener. Abmelden und automatische Freigaben sind unverändert; diese Ergänzung betrifft den Auswahl-Button in Karte, Aqua und Medien. Zehn Relay-Tests und zehn Frontend-Tests sind erfolgreich, einschließlich tatsächlicher HTTP-Route, Befehlsreihenfolge, Ticket-Widerruf, verlorener Belegung und wiederholbarer Sendefehler. | |||
Der Root-Administrator muss das vorbereitete Update einmal ausführen: bash /home/clawtronics/mutec-trailer-update/apply-update.sh. Es prüft das Paket, testet vor dem Austausch, sichert und ersetzt ausschließlich access.js, server.js und test/relay.test.js des separaten Relays und startet mutec-realtime neu. Fehler führen zur Wiederherstellung. /etc/mutec-realtime.env und DISPLAY_KEY werden nicht verändert. Health muss anschließend returnToTrailer:true enthalten. Frontend-Dateien müssen mit der neuen Versionskennung hochgeladen sein. Bis zur Installation des Relay-Updates bleibt dessen bisheriges Freigabeverhalten aktiv. Nach der Installation Bedienseite neu laden und die tatsächliche Trailer-/IDLE-Reaktion von Station 50 prüfen. | |||
Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]]. | Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]]. | ||