MUTEC – WebSocket-Steuerung: Unterschied zwischen den Versionen
Frontend- und Ticket-Upload dokumentiert; WebSocket-VPS-Installation weiterhin offen |
Frontend- und Ticket-Upload dokumentiert; WebSocket-VPS-Installation weiterhin offen |
||
| Zeile 150: | Zeile 150: | ||
Der Administrator hat anschließend den erfolgreichen Ticket-Login auf dem Smartphone bestätigt. Bei künftigen Anmeldefehlern zeigt die Oberfläche den genauen Anmeldeschritt und HTTP-Status. Ein neuer Code auf dem Ticket-Monitor ist nach erfolgreicher Aktivierung normal. | Der Administrator hat anschließend den erfolgreichen Ticket-Login auf dem Smartphone bestätigt. Bei künftigen Anmeldefehlern zeigt die Oberfläche den genauen Anmeldeschritt und HTTP-Status. Ein neuer Code auf dem Ticket-Monitor ist nach erfolgreicher Aktivierung normal. | ||
== Sporadische Ticket-Prüfung: Untersuchung vom 09.10.2026 == | |||
Der Administrator meldet erfolgreiche Ticket-Aktivierung und anschließend sporadisch HTTP 401 von /verify, auch mit frischen Codes und verschiedenen Browsern. Zwölf eigene Testtickets am getrennten Test-Monitor wurden erfolgreich aktiviert und jeweils dreimal geprüft. Zwei direkte Browser-Anmeldungen erreichten ebenfalls das Menü. Diese Tests reservierten keine Station und schalteten keine Geräte um. Die sporadische Ursache ist noch nicht nachgewiesen. | |||
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. | |||
Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]]. | Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]]. | ||