On a sunny day in March, I felt like launching a 'tl-single-app google-chrome' in my ThinLinc client 4.16.0 on Fedora. Creating the session was a breeze, but then I got disturbed and had to pay attention to other things for a while, so I closed my session and my plan was to resume it later. A few hours later... I opened my client and connected with 'tl-single-app google-chrome' again. I expected to see my critically important work that I've had started previously, but this time the ThinLinc client said: > ThinLinc login failed. > (You are not allowed to create any more sessions) What, why?! I'm sure this used to work before! Last time I used this was in ThinLinc 4.13.0, and that I'm sure it worked.
This is a regression from bug 7006. The config handling needed to be overhauled there, and it broken the session command handling.
It is possible to work around this bug by changing the client's reconnect policy. If it's set to "Always ask...", the offending code is bypassed.
Works well now. Tested with different commands, and without a command, and it filtered things correctly. Fedora 39 client to Ubuntu 24.04 server. > MUST: > > * Users should reconnect to the sessions matching their session command Yup. > SHOULD: > > * The API should prevent these kinds of mistakes Yup, see above.
Tested client build 3568 on macOS against server build 3675 on SLES 15. > MUST: > * Users should reconnect to the sessions matching their session command They do. Tested by logging in as a user with multiple running sessions: Session 1: no command Session 3: xterm xclock Session 2: firefox Session 4: xterm When using automatic reconnect (i.e. not "Always ask..."), I was reconnected to the session that matched the startup command setting. That means, if the settings had command "xterm" I reconnected to session 4, while command "xterm clock" reconnected to session 3. If the settings did not have any startup command, I reconnected to session 1. If the session did not match any existing session, a new session was created, no matter if a startup command was used or not. When using "Always ask...", I received a list of all existing sessions to choose from, regardless of the value of the startup command setting. > SHOULD: > * The API should prevent these kinds of mistakes By requiring the caller of the function to be more explicit, similar mistakes should be caught easier in the future.
Also checked release notes and code changes as part of testing in comment 12, looks good.
