mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #974] Not able to open trustedServers.txt if username contains wide characters e.g. Chinese characters #781
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#781
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cheese on GitHub (Dec 7, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/974
Describe the bug
A clear and concise description of what the bug is.
SSL-enabled session failed to start. Barrier is unable to open the right created trustedServers.txt. I am wondering that's because the path contains wide characters, since my username is in wide characters.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Works with username contains wide character
Screenshots
If applicable, add screenshots to help explain your problem.
Please do not link to image hosting sites, as these can be ephemeral. Instead, attach them to the issue.
Error log:
Desktop (please complete the following information):
Additional context
Server is barrier 2.3.3 running on Fedora 32. Connection can be established if SSL-disabled on both sides.
@albertony commented on GitHub (Dec 9, 2020):
Could be related to https://github.com/debauchee/barrier/issues/976.
I made an attempt to fix that one, and it may also fix your issue but am not sure (as I am not familiar with chinese characters, and how they relate to Windows ansi encoding etc). If you are willing to test this beta build, we would find out:
https://dev.azure.com/debauchee/Barrier/_build/results?buildId=355&view=artifacts&pathAsName=false&type=publishedArtifacts
@cheese commented on GitHub (Dec 9, 2020):
I tested this. trustedServers.txt can be read now. But a new issue is barrier keeps asking me to trust the host signature, again and again.
@albertony commented on GitHub (Dec 9, 2020):
Great! Thank you.
It seems the service is misconfigured somehow, leading to the client exiting but being continuously restarted by the process monitoring logic.
I see you also get non-fatal errors like this. I think I can fix this the same way as the original "Unable to open trustedServersFile".
@albertony commented on GitHub (Dec 9, 2020):
Pushed a fix for this as well, beta version here: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=359&view=artifacts&pathAsName=false&type=publishedArtifacts
The remaining issue is in your configuration, I think?
@cheese commented on GitHub (Dec 9, 2020):
What does 'configuration' mean? I was only changing configuration on the GUI.
@albertony commented on GitHub (Dec 9, 2020):
Sorry for the vague statement, I'm farily new to this project so I wasn't sure how the configuration were handled from GUI..
Looked a bit more into it, and seems the GUI generates a temporary configuration file based on the settings.
And then passes this to the background service, which in turn executes the client/server utilities. There is probably a similar issue, (character encoding related) somewhere along this route, but I cannot see where..
Increasing the log level to DEBUG and posting the log again could help:
Then I will investigate it more... (unless you do not bother, and would rather wait until someone more familiar with this code can take over)
@cheese commented on GitHub (Dec 10, 2020):
Log with debug level enabled
@albertony commented on GitHub (Dec 10, 2020):
Thank you! Finally tracked down another one of those character encoding issues, hopefully this was it!
This time the problem was with the windows service (deamon) communication, the previous fix was internally in the client/server executables.
I managed to reproduce a similar error locally, and verify that the last change fixed it.
If you want to retest your exact case, the beta is here:
https://dev.azure.com/debauchee/Barrier/_build/results?buildId=376&view=artifacts&pathAsName=false&type=publishedArtifacts
@cheese commented on GitHub (Dec 11, 2020):
This build does not work still. It still pops dialog again and again.
Logs:
@albertony commented on GitHub (Dec 11, 2020):
Thank you for your patience, and for your valuable input!
Fixed yet another couple of issues,
new beta here: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=388&view=artifacts&pathAsName=false&type=publishedArtifactsPrevious fix was more in the server and deamon, I reproduced an issue there and were too convinced that was it, but your issue are in the client mode... And it turns out there were several parts that needed a fix (client, server, deamon). Hopefully I've tracked all down and fixed them this time. But I don't have the exact test setup as you, so can not be 100% certain. Just let me know if there are more issues, I'm determined to get this out of the way now!
Edit: Did some additional refactoring, should not change any of the functionality but if not testet previous beta yet, then please use latest: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=396&view=artifacts&pathAsName=false&type=publishedArtifacts
@cheese commented on GitHub (Dec 14, 2020):
I tried this build. Not any pop-up dialog. But the connection still failed to be established.
Debug log:
@albertony commented on GitHub (Dec 14, 2020):
That is too bad. And strange.
Did you get the fingerprint pop-up, asking you to trust the fingerprint, at all this time?
Does this file exist, and has content?
If you delete it (or rename it temporarily) before starting the barrier client, do you get the normal fingeprint pop-up asking you to trust the fingerprint? And when you accept, this same file is created again?
(It seems the gui front-end application thinks the TrustedServers.txt exists and is ok, while the client background application is not able to find it).
(I retested the beta again in my setup, and it works as it should - fingerprint pop-up once, TrustedServers.txt created, client background application finds the file and matches the fingerprint, connect ok. So your case might still be somewhat different).
@cheese commented on GitHub (Dec 14, 2020):
No pop-up for this build.
Yes. The file exists.
I can test this, but may be a few days later.
@albertony commented on GitHub (Dec 18, 2020):
What I think is an identical issue was solved with that latest beta, so fingers crossed yours will as well..
@cheese commented on GitHub (Dec 28, 2020):
I am back to that configuration. Which is the latest build I can test?
@albertony commented on GitHub (Dec 28, 2020):
Forced a new build, artifacts here:
https://dev.azure.com/debauchee/Barrier/_build/results?buildId=404&view=artifacts&pathAsName=false&type=publishedArtifacts