Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows10 client: unable to open trustetedServersFile - Username with space #976

Closed
Schlunze opened this issue Dec 8, 2020 · 6 comments · Fixed by #979 or input-leap/input-leap#979

Comments

@Schlunze
Copy link

Schlunze commented Dec 8, 2020

on a Windows Client i have a space and "ä" in the username.
The File trustedServers.txt is written correctly, fingerprint is ok.
The log on client shows continuously: Unable to open trustetedServersFile: C:\Users\xxx xäx\AppData\Local\Barrier...

someone has similar problems with linux client and chinese symbols i think. New issue do to win client.

Thanks for your help in advance

@albertony
Copy link

Would you be willing to test this beta build?
https://dev.azure.com/debauchee/Barrier/_build/results?buildId=355&view=artifacts&pathAsName=false&type=publishedArtifacts

If that fixes it, the problem was the nordic character and not the space.

@albertony
Copy link

albertony commented Dec 9, 2020

Pushed a fix for an additional related issue; when enabling the drag-drop functionality it would not find the desktop path where it will drop files for the same reason as the previous fix.

Edit: Tracked down another issue, this time in the windows service (deamon) communication. If you want to test your exact case, the beta is here: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=376&view=artifacts&pathAsName=false&type=publishedArtifacts

Edit 2: Aaaaand another issue, this time in the client: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=388&view=artifacts&pathAsName=false&type=publishedArtifacts

PS: The issue were non-ascii characters in user name, space did not seem be problematic.

albertony added a commit to albertony/barrier that referenced this issue Dec 9, 2020
@Schlunze
Copy link
Author

Schlunze commented Dec 18, 2020

Edit 2: Aaaaand another issue, this time in the client: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=388&view=artifacts&pathAsName=false&type=publishedArtifacts

Hello albertony
sorry for the late reply. I have tested the build from Edit 2.
The non-ascii character in username does not work in this build.
Here is the log:
...
[2020-12-18T11:13:32] NOTE: server fingerprint: 67:44:C8:9F:D8:3F:6E:42:93:2C:4D:60:E5:18:9F:55:11:30:4C:04
[2020-12-18T11:13:32] NOTE: trustedServersFilename: C:\Users\xxxxx xäx\AppData\Local\Barrier /SSL/Fingerprints/TrustedServers.txt
[2020-12-18T11:13:32] NOTE: Unable to open trustedServersFile: C:\Users\xxxxx xäx\AppData\Local\Barrier /SSL/Fingerprints/TrustedServers.txt
[2020-12-18T11:13:32] ERROR: failed to verify server certificate fingerprint
...
btw thank you for your work :)

@albertony
Copy link

Thank you for your feedback!

That error is the same as #974 (comment) (I think that issue and yours are essentially duplicates, and is about non-ascii characters). I have not been able to reproduce that in my test setup, unfortunately, latest beta works with special characters (and space), but will have another look.

@Schlunze
Copy link
Author

That build works with non-ascii characters and solved my issue - thank you.
https://dev.azure.com/debauchee/Barrier/_build/results?buildId=396&view=artifacts&pathAsName=false&type=publishedArtifacts

@albertony
Copy link

Great!!

p12tic added a commit that referenced this issue Dec 30, 2020
Use ansi codepage for internal multibyte strings on windows (fixes #976, fixes #974, fixes #444)
p12tic added a commit to p12tic/barrier that referenced this issue Oct 29, 2021
p12tic added a commit to p12tic/barrier that referenced this issue Oct 29, 2021
p12tic added a commit to p12tic/barrier that referenced this issue Oct 29, 2021
This fixes debauchee#976, fixes debauchee#974, fixes debauchee#444.

On Windows the standard stream open() functions expect bytes encoded in
current system encoding, not UTF8. Since we're dealing with UTF8
throughout the application this results in wrong paths being passed and
failure to open files. As a solution, we convert the paths to UTF16 via
the WCHAR character type and use the special Windows-specific overloads
of open() functions.
p12tic added a commit to p12tic/barrier that referenced this issue Oct 29, 2021
This fixes debauchee#976, fixes debauchee#974, fixes debauchee#444.

On Windows the standard stream open() functions expect bytes encoded in
current system encoding, not UTF8. Since we're dealing with UTF8
throughout the application this results in wrong paths being passed and
failure to open files. As a solution, we convert the paths to UTF16 via
the WCHAR character type and use the special Windows-specific overloads
of open() functions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants