credential expiration comes back as numeric Inf (unclassed)

[tyner]

We had a user set only these three environment variables:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN

and then when paws.common::locate_credentials() was called, its return had expiration equal to numeric Inf (with no class attribute; usually it would have POSIXct). I not sure whether Inf is a valid expiration, but if it is, should it be classed? Conversely, if it is not a valid expiration, should an error/warning be thrown?

The use case is if someone is caching the credentials and needs to figure out if the cached credentials are expired.

[DyfanJones]

Really sorry about my slow replies. I am currently on holiday. I am guessing the biggest issue with this is if a session token is known i.e. sso, then a refresh session token should be generated by the SDK :)

[DyfanJones]

In the meantime please feel free to raise any PR if you believe you have a solution for this. I do appreciate PRs as paws is a beast of a SDK package.

[DyfanJones]

Hi @tyner the expiration parameter should be a Unix Timestamp. Usually it is generated from the sso method boto3: get_role_credentials or paws: get_role_credentials. Ultimately it is a integer, we currently don't utilise it in paws, however it is for refreshing credentials.

Currently it is defaulted as inf to represent the session not expiring. I will add a ticket for refreshing/caching credentials so it doesn't need to hit aws for sso credentails.

[DyfanJones]

Temporary credential refresh are now supported for sso connections #794

[tyner]

Thanks @DyfanJones for looking into this! Note: I don't believe we are using sso for credentials, in case that is relevant.