Open tyner opened 3 weeks ago
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 :)
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.
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.
Temporary credential refresh are now supported for sso connections #794
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 hadexpiration
equal to numericInf
(with no class attribute; usually it would havePOSIXct
). I not sure whetherInf
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.