Conversation
|
Any thoughts on this? |
|
Are all maintainers just crazy busy(which is, of course, fine) or is there another way to get this PR looked at? Did I miss something? |
|
"The maintainers" is me :) And yeah, Christmas break then the usual rush of work because the other half of the world didn't have as much of a break as me, and etc etc :) |
|
oh, thanks @bernardd. didn't know you were all by your lonesome. |
The SSO credentials API returns the `expiration` field as an integer in milliseconds. However, the `next_refresh_in` calculation assumed all integer expiration values were in seconds (similar to the output of `DateTime.to_unix/1`). This led to a massive calculation for the `send_after` delay value resulting in a GenServer crash with `ArgumentError: exceeds the maximum supported time value`. This fix adjusts `next_refresh_in/1` to automatically detect and convert millisecond timestamps to seconds.
Instead of checking for a millisecond timestamp inside the AuthCache module, we now normalize the timestamp as soon as it's parsed from the AWS SSO API JSON payload. This is a cleaner 'anti-corruption layer' pattern that ensures all cache logic consistently interacts with timestamps in seconds. Also added a dedicated test using a simulated JSON payload based on the official AWS SSO GetRoleCredentials API documentation to prevent regressions.
| # AWS SSO returns expiration as an integer in milliseconds, | ||
| # but ex_aws auth cache expects it in seconds. | ||
| expiration_sec = | ||
| if is_integer(expiration) and expiration > 99_999_999_999 do |
There was a problem hiding this comment.
this makes me sad, and i'm hoping someone has a better solution.
2 participants
This builds on top of a solution proposed in #1100.
This adds writing out the updated credentials to the sso cache as well as a preemptive credential refresh to the auth cache genserver.
I used this locally to tun a long running(multiple hours) script against AWS with SSO credentials.