-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
"websocket unavailable" when starting RDP session in full screen mode #41515
Labels
Comments
@ibeckermayer looks like there are 2 problems here:
|
ibeckermayer
added a commit
that referenced
this issue
May 15, 2024
1. A new mechanism is added to withhold all non-MFA TDP messages during the MFA ceremony within lib/web/desktop.go 2. A new mechanism is added to withhold all resizes when the rdpclient/client.go is not yet ready to receive messages. (Non-resize messages are still just dropped). This fixes #41515
github-merge-queue bot
pushed a commit
that referenced
this issue
May 21, 2024
* Update 'failed' statusText only if a previous error has not already been displayed to the user. This way the first error message (which is usually the most informative as to what's gone awry) is displayed to the user in the case of an error cascade. (E.g. tdp error is sent back, the server to closes the websocket, and that close causes a client websocket error. In that case, we want to display the tdp error that was sent back, not the websocket is closed error.) * Adds mechanisms for withholding resizes 1. A new mechanism is added to withhold all non-MFA TDP messages during the MFA ceremony within lib/web/desktop.go 2. A new mechanism is added to withhold all resizes when the rdpclient/client.go is not yet ready to receive messages. (Non-resize messages are still just dropped). This fixes #41515 * Remove superfluous comment, rename handleMessage to handleTDPInput * Refactors mfa and desktop handlers to use a single function to handle checking if MFA is required, and refactors the desktop handler to make the TLS configuration creation more clear. * use idiomatic TypeAttr * Only log a warning when we try to send TDP message on a closed ws The only time I know this happens is when the user tries to resize on when an "Active Session" warning modal is shown, in which case the session was failing. In reality we can just ignore this scenario. If the websocket isn't yet open, we don't want to send messages. If it closes, then the onclose handler will take care of cleaning up the session, we don't need to error if any straggling messages are attempted to be sent.
ibeckermayer
added a commit
that referenced
this issue
May 21, 2024
* Update 'failed' statusText only if a previous error has not already been displayed to the user. This way the first error message (which is usually the most informative as to what's gone awry) is displayed to the user in the case of an error cascade. (E.g. tdp error is sent back, the server to closes the websocket, and that close causes a client websocket error. In that case, we want to display the tdp error that was sent back, not the websocket is closed error.) * Adds mechanisms for withholding resizes 1. A new mechanism is added to withhold all non-MFA TDP messages during the MFA ceremony within lib/web/desktop.go 2. A new mechanism is added to withhold all resizes when the rdpclient/client.go is not yet ready to receive messages. (Non-resize messages are still just dropped). This fixes #41515 * Remove superfluous comment, rename handleMessage to handleTDPInput * Refactors mfa and desktop handlers to use a single function to handle checking if MFA is required, and refactors the desktop handler to make the TLS configuration creation more clear. * use idiomatic TypeAttr * Only log a warning when we try to send TDP message on a closed ws The only time I know this happens is when the user tries to resize on when an "Active Session" warning modal is shown, in which case the session was failing. In reality we can just ignore this scenario. If the websocket isn't yet open, we don't want to send messages. If it closes, then the onclose handler will take care of cleaning up the session, we don't need to error if any straggling messages are attempted to be sent.
github-merge-queue bot
pushed a commit
that referenced
this issue
May 21, 2024
* Backports the piece of mfa.go changed in #40077 required for backporting #41570 * Fixes error propagation and resizes during MFA (#41570) * Update 'failed' statusText only if a previous error has not already been displayed to the user. This way the first error message (which is usually the most informative as to what's gone awry) is displayed to the user in the case of an error cascade. (E.g. tdp error is sent back, the server to closes the websocket, and that close causes a client websocket error. In that case, we want to display the tdp error that was sent back, not the websocket is closed error.) * Adds mechanisms for withholding resizes 1. A new mechanism is added to withhold all non-MFA TDP messages during the MFA ceremony within lib/web/desktop.go 2. A new mechanism is added to withhold all resizes when the rdpclient/client.go is not yet ready to receive messages. (Non-resize messages are still just dropped). This fixes #41515 * Remove superfluous comment, rename handleMessage to handleTDPInput * Refactors mfa and desktop handlers to use a single function to handle checking if MFA is required, and refactors the desktop handler to make the TLS configuration creation more clear. * use idiomatic TypeAttr * Only log a warning when we try to send TDP message on a closed ws The only time I know this happens is when the user tries to resize on when an "Active Session" warning modal is shown, in which case the session was failing. In reality we can just ignore this scenario. If the websocket isn't yet open, we don't want to send messages. If it closes, then the onclose handler will take care of cleaning up the session, we don't need to error if any straggling messages are attempted to be sent.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected behavior:
I'm starting RDP sessions using Chrome/ium's App mode, to provide a more native feel, using the following command:
After logging in with a Passkey, I'm prompted for MFA auth.
Current behavior:
After touching the yubikey when the Windows MFA prompt appears, I get the following error: "websocket unavailable"
devtools error:
This error only occurs when trying to use MFA in full screen mode, if I hit F11 to get out of full screen mode, it works flawlessly.
This message is produced when the error occurs:
My Role has
spec.options.require_session_mfa: true
This is reproducible reliably with Chrome 123.0.6312.123/32bit and MSEdge 123.0.2420.97 on Windows 10, and sometimes with chromium-121.0.6167.85-1.fc38.x86_64 on Fedora 38.
Previously, with Teleport 15.1.8, this used to work everytime/everywhere.
Bug details:
The text was updated successfully, but these errors were encountered: