Univention Bugzilla – Bug 50740
Send screen lock to clients at regular intervals
Last modified: 2020-02-13 21:42:36 CET
Title: === As a teacher, I would like computers that have a screen lock (intentionally) restarted to automatically receive a screen lock again to prevent users from using this to bypass the screen lock. Description: === 1. send "lock screen" again at regular time intervals, provided it is still selected in the computer room module 2. is not only relevant in case of intentional misbehaviour but in practice not all iTalc clients always get the "Lock Screen" signal. 3. time intervals configurable via UCR (default: every 5sec) Release: === * As errata acceptance criteria: === * Assuming I'm in the computer room module, lock one computer, then the computer is locked again at regular intervals until I actively unlock it. * The signal for the new lock is implemented in the UMC module - here the signal is resent by timer. If the UMC module is closed, the signal is not sent any further.
The following solution was implemented on oschwieg/4.4/50740: An interval is started in the browser of the teacher that triggers every x seconds, where x is the value configured in ucsschool/umc/computerroom/screenlock/interval If the value is <1 the feature is disabled. If unset (default) the value is 5 seconds. On every interval the following happens: It is checked, if all computers, that are marked as locked, are indeed locked. If that is not the case the UMCP command to trigger the lock is send again. There are some caveats: If the computers are checked before the new status reached the UMC, a lock signal might be send again, resulting in a flicker on the target system. That should happen very rarely and only in the seconds after initially locking a computer. In very rare cases it can also happen that a teacher unlocks a computer, but a status update arrives marking it still as locked, which would result in the logic to lock it again. I did not find a solution yet for these two problems. Both of which can be drastically reduced by increasing the interval time to a sufficent amount. One proposal: Merge the updateComputers and lockingInterval logic into one (with one UCRV to configure the interval time). The problem is mentioned in the manual addition for administrators. Please QA and REOPEN for merge or adaption.
The product tests were also modified to include this feature in future checks: https://hutten.knut.univention.de/mediawiki/index.php/Produkttests_UCS@school_4.4_UMC_Module#Computerraum
In very rare cases it can also happen that a teacher unlocks a computer, but a status update arrives marking it still as locked, which would result in the logic to lock it again. -- This was a thought problem on my side. It can logically not happen since the updateRoom function only delivers changes. Bug can be QA'ed.
Package: ucs-school-umc-computerroom Version: 11.0.0-16A~4.4.0.202002100902 Branch: ucs_4.4-0 Scope: ucs-school-4.4 Can be tested. Automatic test follows asap
My findings so far: 1) UCR variable description: s/Type: str/Type: int/ 2) Possible inconsistency from user perspective: if the room is changed back and forth or the browser is closed and reopened, the "auto screen lock" is no longer active. This is not transparent to the user. 3) Possible confusion from user perspective: if the same room is opened by the same user in 2 different browser instances and the screens are locked by browser1, any unlock action of browser2 is reverted a short time after by browser1. 4) Currently only screens are automatically relocked; the auto-relock does not apply to input devices. 5) Suggestion for manual section: Ab Version 4.4v4 prüft das Computerraum-Modul von UCS@school in der Standardeinstellung regelmäßig, ob alle gesperrten Rechner weiterhin noch gesperrt sind, um z.B. Rechner nach deren Neustart wieder in den gesperrten Zustand zu versetzen. Das Intervall, in dem die Überprüfung läuft, kann durch die &ucsUCR;-Variable <envar>ucsschool/umc/computerroom/screenlock/interval</envar> konfiguriert werden. In der Standardkonfiguration wird die Prüfung alle 5 Sekunden durchgeführt. Wird der Wert der Variable auf 0 gesetzt, wird die Prüfung abgeschaltet. Bei der Verwendung der Rechnersperre ist folgendes zu beachten: Damit das automatische Wiedersperren von Rechnern funktioniert, darf die UMC zwischen dem Sperren von Rechnern und dem Entsperren der Rechner nicht geschlossen werden und zusätzlich darf innerhalb des Computerraum-Moduls der Raum nicht gewechselt werden. Besides the items above, it worked for me.
To 1.: Will be fixed in the next build To 2.: This should not be the case. If a teacher opens a computerroom and there are locked screens, the frontend should be notified about that in the updateRoom function (computerroom.js line 1298). Only if the computers are actually not locked anymore a newly opened frontend has no way anymore of knowing if a computer should be locked or not. To 3.: This problem cannot be fixed to my knowledge. The frontend code in the two browsers are independent of each other. Also both browsers communicate with a separate UMC module process. There is now defined way of these two browser windows to communicate over the status of the computer room other than with the update UMCP command. Since these updates are polling (every 2 seconds per timer) I do not know how we could avoid this problem. The only suitable solution for this I know is real time communication via websockets. To 4.: The User Story mentioned specifically screen lock and not input lock. I was not aware this should work for the input lock as well in this US. Too 5.: Will be applied with the next build
(In reply to Ole Schwiegert from comment #6) > To 2.: This should not be the case. If a teacher opens a computerroom and > there are locked screens, the frontend should be notified about that in the > updateRoom function (computerroom.js line 1298). Only if the computers are > actually not locked anymore a newly opened frontend has no way anymore of > knowing if a computer should be locked or not. You are right. It worked for me, too. Looks like I tested it yesterday the wrong way. So one problem less. > To 3.: This problem cannot be fixed to my knowledge. The frontend code in > the two browsers are independent of each other. Also both browsers > communicate with a separate UMC module process. There is now defined way of > these two browser windows to communicate over the status of the computer > room other than with the update UMCP command. Since these updates are > polling (every 2 seconds per timer) I do not know how we could avoid this > problem. The only suitable solution for this I know is real time > communication via websockets. I think this is only a minor problem in a seldom scenario. > To 4.: The User Story mentioned specifically screen lock and not input lock. > I was not aware this should work for the input lock as well in this US. According to Michel, this is ok for this userstory.
REOPEN: the YAML entry is missing
Package: ucs-school-umc-computerroom Version: 11.0.0-17A~4.4.0.202002111527 Branch: ucs_4.4-0 Scope: ucs-school-4.4 UCRV to int Manual adapted YAML added
(In reply to Ole Schwiegert from comment #9) > Package: ucs-school-umc-computerroom > Version: 11.0.0-17A~4.4.0.202002111527 > Branch: ucs_4.4-0 > Scope: ucs-school-4.4 > > UCRV to int > Manual adapted > YAML added OK: code change OK: installation OK: update OK: changelog entry OK: advisory OK: functional change OK: package built and installable
UCS@school 4.4 v4 has been released. https://docs.software-univention.de/changelog-ucsschool-4.4v4-de.html If this error occurs again, please clone this bug.