-
Notifications
You must be signed in to change notification settings - Fork 821
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
Can't use --prompt=terminal with --ec2-server #888
Comments
Hey @FernandoMiguel, this is because the ec2/ecs server mode of exec needs to be able to refresh credentials from the background aws-vault process asynchronously, while the terminal prompt can only receive input synchronously and needs to interrupt the foreground process leading to a poor/broken UX. So I'm really not sure how to handle terminal input when using a server, do you have any thoughts or ideas? |
No idea. Was fine yesterday. It's broken today. |
@FernandoMiguel ah so it's the "default" as terminal that is the problem |
I assume you can specify a different prompt value to get things working |
Just regular vanilla iTerm2. |
I mean you can specify a different prompt value (e.g. |
I'll give ir a try. That will make this a much longer command to run every time. Easy to forget and have problems again. |
yeah we should sort out a better default |
that seems to work fine. thanks for the help! |
This breaking change is a bummer - we use
Could it not just work the way it used to? Ask for 2FA input at launch then start erroring when re-auth in required... |
Bump. I'm with @danwashusen here. This breaks terribly in places where 'terminal' is the only viable option. |
so... nothing on this? |
My understanding the "breaking change" was the introduction pre server start check to see if v6.5.0...v6.6.0#diff-70819234fda619d5e21380c6721d9c61a32ef46edb6092e117800926fc169cf3R52-R60 Without this check the user is at risk of starting a sever that will not be able to do what its suppose to do (keep the creds refreshed). Effectively the error path is been highlighted to the user at the point of invoking It feels the change made is in the right direction but some use cases hadn't been considered. The correct resolution doesn't feel like just rolling back the change. @FernandoMiguel, @danwashusen and @pdehlke: In your use cases are you using 2FA? . If you are then my view is an explicit optin from the user really needs be made to bypass the above check (maybe |
we are using aws sso (with azure AD). so no MFA |
The whole point of |
Yay |
The text was updated successfully, but these errors were encountered: