Adds a warning when API keys will expire soon #1086
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.