-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(apiKeys): api keys manager #374
Conversation
@bsantare What do you think? Feedbacks are welcome :) |
da91a8a
to
c620305
Compare
c620305
to
fa24cd8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
Just one suggestion and a typo
README.md
Outdated
|--------------| ------------------|------------| | ||
| name | *auto-generated* | Name of the key. This is used under the hood to differentiate keys in the deployment process.<br/><br/>Names are used in the Cfn resource name. Please, keep them short and without spaces or special characters to avoid issues. Key names are case sensitive. | | ||
| description | *name of the key* | A short description for that key | | ||
| expires | 1y | Expiration time for the key. <br/>Can be expressed in seconds or in "human" format. eg: `86400`, `30d`, `2w`, `1y` (See [jkroso/parse-duration](https://github.com/jkroso/parse-duration)).<br/>Min: 1d, max: 1y | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This description is a little misleading as the implementation will set the key to expire at now() + expires
on the next deployment. Would it make sense to support two modes?
expiresOn
- absolute expiration expressed by Posix timestamp or ISO 8601 stringexpiresAfter
- on each deployment, updated to now() +expiresAfter
At a minimum, I would suggest updating this description to explain that the expires date for the key will be bumped by expires
on each deployment.
Also, it may be prudent to mention that deployments may fail if a key has expired and was removed via Appsync Dynamo TTL with a note mentioning that the key name may be changed to resolve the broken deployment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to support two modes?
Yes!! This is something I thought about yesterday too. Wanted to update the PR but I haven't had time yet.
Also, it may be prudent to mention that deployments may fail if a key has expired and was removed via Appsync Dynamo TTL with a note mentioning that the key name may be changed to resolve the broken deployment.
Sure, Will add that. Thanks
src/index.js
Outdated
|
||
let duration = parseDuration(expires); | ||
if (duration === null) { | ||
throw new Error(`Could not parse ${expires} as a valid diration`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
duration
d326d96
to
3be25d4
Compare
3be25d4
to
71145c3
Compare
Replaces/fixes #373
Add Api key manager.
Features:
expiry
,description
andapikeyId
(See Cfn doc).