-
Notifications
You must be signed in to change notification settings - Fork 8
TRITON-2513 - Update Access Keys to better support Manta S3 #12
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
Conversation
- Add support for description field on access keys - Add support for udpating an access key's description and status - Add prefix and checksum to accesskeysecret - Replace usege of nodeunit's ifError with assert-plus' ifError (See: caolan/nodeunit#151)
590843b to
cf5cd46
Compare
- Eexport DEFAULT_PREFIX and DEFAULT_BYTE_LENGTH. - Patch up some fields that may be missing on older records as a convience for clients.
danmcd
left a comment
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.
Catching up on the incremental change here.
danmcd
left a comment
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.
Got distracted by Intel ucode, have some clarifying questions, one of which is critical, and one nit.
| "rimraf": "~2.4.0" | ||
| } | ||
| }, | ||
| "nan": { |
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 will prevent OS-8701/MANTA-5487 classes of problems right?
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.
Unfortunately, not in this case because this module wouldn't commonly be used at the highest level of the dependency tree. It does help the next person working on this module and running tests but its not nearly as helpful as other places.
To avoid OS-8701/MANTA-5487 issues we really want package-lock.json files in the top level modules, like sdc-ufds, and sdc-cloudapi. We also want to use npm ci instead of npm install as there's cases where npm install will still re-resolve version ranges. Even without using npm ci having a package-lock.json in those repos reduces the frequency of a OS-8701/MANTA-5487 happening again.
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.
OH... I'm getting confused. HERE it shouldn't be an issue because nobody's using this app with v0.10 anymore I'm guessing?
If this IS getting used with v0.10, we'll need to put it up in package.json I'm guessing, or higher up here (I'll indicate where).
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.
When sdc-ufds and sdc-cloudapi come up I'll keep an eye on that.
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.
Sorry, I think I muddied things up a bit too and didn't accurately address your question.
it shouldn't be an issue because nobody's using this app with v0.10 anymore
Correct, if something was using v0.10 with this module the package-lock.json here wouldn't help (or hurt) them anyway, we'd still need to solve that in the same way we did in OS-8701/MANTA-5487.
danmcd
left a comment
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.
Pardon my nan panic. I've resolved all other conversations except for that one and a new one. All I need on those two is that I'm now understanding things and not further muddying the waters.
I'll need to go over index.js and accesskey.test.js once more.
| "rimraf": "~2.4.0" | ||
| } | ||
| }, | ||
| "nan": { |
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.
OH... I'm getting confused. HERE it shouldn't be an issue because nobody's using this app with v0.10 anymore I'm guessing?
If this IS getting used with v0.10, we'll need to put it up in package.json I'm guessing, or higher up here (I'll indicate where).
| "rimraf": "~2.4.0" | ||
| } | ||
| }, | ||
| "nan": { |
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.
When sdc-ufds and sdc-cloudapi come up I'll keep an eye on that.
danmcd
left a comment
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.
Code seems okay, but looking through the tests, I have some silly questions. I may be missing the plot too.
- Do access keys have lifetimes?
- This may be more a node-triton or sdc-ufds issue, but does the testing here need to cover users trying to grab things that aren't theirs?
These access keys do not have a lifetime and do not expire on their own. I considered giving them an expiration but opted against it to align with AWS. We'll need to support temporary tokens for the S3 Manta functionality separately too, which would cover the use case for keys that can expire. There's an argument to be made that "We're not AWS" and/or those reasons aren't good enough and we want the keys to automatically expire too.
This module assumes that the user IDs supplied are from a trusted source such as cloudapi or sdc-ufds. I did add some some tests here which creates a key for a user and two subusers and confirms that only their specific keys are returned when queried. I can add another user with two subusers and do a cross check against both accounts too to cover all the bases. |
danmcd
left a comment
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.
Thank you for the extra test with two (possibly mutually-hostile) users. I can't see anything else immediately wrong here.
cneira
left a comment
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.
Let me know if it's too much work to avoid the usage of Buffer.alloc that we need to start exploring bumping up the mahi version of node.
Also fix some inconsistent 2 vs 4 space indentiation usage.
danmcd
left a comment
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.
Re-up based on the new play-nice-with-v.0.10.x changes.
descriptionfield on access keys.descriptionandstatus.updatedfield that is updated when eitherdescriptionorstatusare modified.ifErrorfunction with assert-plus'ifError(See: ifError doesn't throw caolan/nodeunit#151).crypto.randomBytes().Confirmed
make checkandmake testspass. The unit tests will pass with sdc-ufds version (7.5.0) with changes from TritonDataCenter/sdc-ufds/pull/29The unit tests will also mostly pass with the current version of sdc-ufds (v7.4.1) though some validation tests in this repo will fail as this older version is less strict about the
statusanddescriptionproperties. Meaning this client is compatible with both versions (not that it necessarily needs to be.)Related PRs:
triton accesskeyscommands to manage access keys. node-triton#350