-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Teleport Connect headless approval #29097
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Joerger marked this conversation as resolved.
Outdated
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When I execute a headless login and then approve it outside of Connect (or in another instance of Connect), Connect will continue to show the modal. I guess that's because the loop in tshd will be stuck on How hard would it be to abort that request when we detect that the auth prompt has been approved? I think it wouldn't need to be addressed in this PR, but it feels like something we should implement sooner rather than later. In this PR, we should at least add a timeout to the request, I feel like a minute would be enough?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The more I think about it, the more doable it seems. We'd basically need to set up a new watcher using I also think having a timeout (3m callback timeout to match the max lifetime of a headless request) is a must have, thanks for suggesting it.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fb8b2efa8a4cb623b896f26feae3cc52dc9cecda
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Both the relogin logic in gateways and the headless watcher show an important modal in Connect and focus the app. An important modal is going to cover a regular modal shown in the app. The Electron app doesn't guard against attempting to show two important modals at the same time. Calling Because the relogin logic in gateways and the headless watcher don't coordinate with each other, it's possible for them to overwrite each other. I don't think that should be the case: in a situation where you requested a headless login somewhere and the app was brought to focus, if a DB GUI client attempts to relogin, it should not overwrite the headless authn modal. The relogin logic is already written in a way that assumes it might not be able to lock a mutex and will instead fail immediately. I think we could do the same for headless authn. It should boil down to renaming What do you think about this? Both relogin and headless authn occuring at the same time are rather unlikely, but it would set out a good pattern to follow for any other features using important modals in tshd.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, after reading Grzegorz's comment about two requests in a row, I realized that it's possible for two headless requests from two different clusters to override each other.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that we should add IIUC, there is a second reason for In general, we want to use a normal
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. eff189353ea587d662a89f81d2e0c7436b759061
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That makes sense. I'm just thinking about the name:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I named it 0fa2e3d964ed966fc3569c171a9fb2ea9c777c2d |
Uh oh!
There was an error while loading. Please reload this page.