-
Notifications
You must be signed in to change notification settings - Fork 137
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
ocm login --use-config #69
base: main
Are you sure you want to change the base?
Conversation
Can one of the admins verify this patch? |
[test] |
9527da0
to
6fabc27
Compare
[test] |
This allows you to log in using the values from your config without overwriting it. This lets you use a refresh token indefinitely if desired, reducing/eliminating "token expired" errors while doing other stuff like ocm cluster login.
6fabc27
to
4af940d
Compare
@vkareh PTAL |
/hold |
This would be neat for internal use as we have several production/staging/integration envs to log into, all using same SSO! For "token expired" use cases, I'm not sure we need it. Most commands already write refreshed tokens back to config file, #153 discusses some corner cases to improve. |
To be honest, I'm not sure. So let's back up to my use case. What was frustrating me was being able to run ocm commands for "a while" (whatever the short-lived token timeout is) but eventually failing and having to
* Understanding that we have separate environments, I guess I'm okay needing to log in explicitly when I need to switch from one to the other. But even there, why should I need to, since the offline token is the same? Heck, what would be really neat is if the config were able to maintain separate sections, each with its short-lived token, to minimize SSO calls even when I'm thrashing among envs. |
This allows you to log in using the values from your config without
overwriting it. This lets you use a refresh token indefinitely if
desired, reducing/eliminating "token expired" errors while doing other
stuff like ocm cluster login.