Currently, SSO does not respect the character encoding set by the system locale and instead assumes UTF-8. This can cause issues for external programs using our SSO system that likely expect us to follow the system character encoding. To reproduce: - Set system locale to latin-1 - Add a user with a password containing an "ö" - Start a new ThinLinc session with the newly created user - Run `tl-sso-password | cat' This is expected to print the above set password including the "ö" (which is part of latin-1), but as of now the system character encoding is assumed to be UTF-8, and thus the utf-8 "ö" is replaced by the corresponding "ö" since our system locale is set to latin-1.
Clarification regarding reproduction: Due to lacking character encoding support in both OpenSSH, the bug can currently only be reproduced using webaccess to start the new ThinLinc session mentioned above.
As of the conversion to python 3, and the improved handling of string thereof, this issue is now resolved.
This works as expected now! There are two ways to see the issue. 1. To be able to log in with non-ASCII password you need a build before this was fixed but after Webaccess was converted to Python 3. I tested on build 1981, as described in the description and comment 1. 2. Instead of trying to log in with non-ASCII password you can set the sso password with tl-sso-update-password and then see the effect of tl-sso-password. Tested that it was fixed on RHEL8, Latin-9 locale and build 2005. When verifying this we had a discussion if this really was the desired behavior. We came to the conclusion that it is, since the Single Sign-on mechanism should replace manually entered passwords from the user. If the user was to enter the password manually it should be sent system locale encoded to the application.
