You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the deviceflow with an external auth server, flytectl repeats the device flow each time it is used because it thinks the token is expired. Tracing through the code, I found this is probably the cause. The api response schema, notably has an expires_in not an expiry field. When unmarshalling to an oauth2.Token, it omits the missing expiry and sets the expiry to 0001-01-01T00:00:00Z, which you can verify by looking in your keyring keyring get flytectl 'dns:///<your-endpoint>:flytectl-user'. This causes the future invocations of flytectl to think the token is expired and restart the device flow.
Expected behavior
The stored token should have the expiry date computed from the optional expires_in response from the /token api.
Additional context to reproduce
Configure flytectl to use authType: DeviceFlow and point to an endpoint that has auth enabled
Run flytectl version
Complete device auth flow
Run flytectl version again, notice you need to redo the device auth flow
Inspect contents of keyring and note the expiry date is the zero value of time.Time
Screenshots
No response
Are you sure this issue hasn't been raised already?
Yes
Have you read the Code of Conduct?
Yes
The text was updated successfully, but these errors were encountered:
Hello 👋, This issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will close the issue if we detect no activity in the next 7 days. Thank you for your contribution and understanding! 🙏
Describe the bug
When using the deviceflow with an external auth server, flytectl repeats the device flow each time it is used because it thinks the token is expired. Tracing through the code, I found this is probably the cause. The api response schema, notably has an
expires_in
not anexpiry
field. When unmarshalling to an oauth2.Token, it omits the missingexpiry
and sets the expiry to0001-01-01T00:00:00Z
, which you can verify by looking in your keyringkeyring get flytectl 'dns:///<your-endpoint>:flytectl-user'
. This causes the future invocations of flytectl to think the token is expired and restart the device flow.Expected behavior
The stored token should have the expiry date computed from the optional
expires_in
response from the /token api.Additional context to reproduce
authType: DeviceFlow
and point to an endpoint that has auth enabledflytectl version
flytectl version
again, notice you need to redo the device auth flowtime.Time
Screenshots
No response
Are you sure this issue hasn't been raised already?
Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: