r? @stripe/developer-products
cc @stripe/developer-products
Sorry this one's a bit big. I added a new structure for holding API keys, so there's a couple commits in here that are mostly mechanical changes. Recommend going commit-by-commit to see the juicy stuff.
Summary
This change adds a warning on stderr when the stored API keys will expire soon. When expiration is within 24 hours, the warning will appear on every command. Otherwise, if expiration is within the next two weeks, the warning will appear once every 12 hours.
Here's what it looks like with new keys provisioned today, with expiration times doctored in various ways.
Fresh keys:
Expiration set to 2023-06-25:
Expiration set to 2023-06-16 (tomorrow):
I also started setting the expiration time to reflect the expiration returned in the API call during key transfer rather than guessing at today + 90 days. This allows us to locally store the correct expiration if the validity of these keys ever changes.
Unfortunately the precision of these warnings can be a little bit off depending on the time of day the key was issued since we only store the UTC date right now, rather than a timestamp. As such, it's possible that a key which expires at 23:59:00 UTC on January 2 could start showing a 24-hour warning at 00:00:01 UTC on January 1. I didn't want to change the storage in this PR because I didn't want to expand the scope, but it's something we could probably improve the precision of relatively easily in the future.
Reviewers
r? @stripe/developer-products cc @stripe/developer-products
Sorry this one's a bit big. I added a new structure for holding API keys, so there's a couple commits in here that are mostly mechanical changes. Recommend going commit-by-commit to see the juicy stuff.
Summary
This change adds a warning on stderr when the stored API keys will expire soon. When expiration is within 24 hours, the warning will appear on every command. Otherwise, if expiration is within the next two weeks, the warning will appear once every 12 hours.
Here's what it looks like with new keys provisioned today, with expiration times doctored in various ways.
Fresh keys:
Expiration set to
2023-06-25:Expiration set to
2023-06-16(tomorrow):I also started setting the expiration time to reflect the expiration returned in the API call during key transfer rather than guessing at today + 90 days. This allows us to locally store the correct expiration if the validity of these keys ever changes.
Unfortunately the precision of these warnings can be a little bit off depending on the time of day the key was issued since we only store the UTC date right now, rather than a timestamp. As such, it's possible that a key which expires at 23:59:00 UTC on January 2 could start showing a 24-hour warning at 00:00:01 UTC on January 1. I didn't want to change the storage in this PR because I didn't want to expand the scope, but it's something we could probably improve the precision of relatively easily in the future.