Adds support for secret resolution via support of secretResolver.#1543
Adds support for secret resolution via support of secretResolver.#1543
Conversation
Codecov Report❌ Patch coverage is ❌ Your patch check has failed because the patch coverage (3.30%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## develop #1543 +/- ##
===========================================
- Coverage 41.88% 41.09% -0.79%
===========================================
Files 49 50 +1
Lines 3794 3876 +82
Branches 1087 1115 +28
===========================================
+ Hits 1589 1593 +4
- Misses 2082 2160 +78
Partials 123 123
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
appurva21
left a comment
There was a problem hiding this comment.
Are we tracking changes to make scripts work separately?
lib/runner/index.js
Outdated
| certificates: options.certificates, | ||
| proxies: options.proxies | ||
| proxies: options.proxies, | ||
| secretResolvers: options.secretResolvers |
lib/runner/index.js
Outdated
| * @param {String} [options.entrypoint.lookupStrategy=idOrName] strategy to lookup the entrypoint [idOrName, path] | ||
| * @param {Array<String>} [options.entrypoint.path] path to lookup | ||
| * @param {Object} [options.run] Run-specific options, such as options related to the host | ||
| * @param {Object} [options.secretResolvers] - Object mapping provider names to resolver configs. |
There was a problem hiding this comment.
I don't think runtime needs to be aware of all kinds of sources and their respective resolvers. Runtime should just accept one resolver, which then can encapsulate all this (including retry and timeout).
Let's follow the same pattern as options.script.packageResolver etc.
There was a problem hiding this comment.
Makes sense. Will work on this and update.
There was a problem hiding this comment.
Why do we have these changes?
There was a problem hiding this comment.
Removing them completely now as not needed anymore. previous approach resolved secret here so they were left out.
| if (err) { | ||
| // Secret resolution failed - this is fatal for the current item | ||
| // (same pattern as pre-request script skip) | ||
| self.triggers.item(err, coords, item, null, { isSecretResolutionFailed: true }); |
There was a problem hiding this comment.
isSecretResolutionFailed why do we need this?
There was a problem hiding this comment.
@appurva21 item trigger gets following args (err, coords, item, result, options). Added this to determine that error was because of the secret resolution and not in other place like pre-request, request, or tests. I don't think there's current usage so it can be removed if needed.
Ideally, if we expect from consumer to provide correct codes/errors from secretResolver side, it's not needed since error will have that info but if not then it'd be usefull field.
it's similar to how we pass { isSkipped: true } in case of execution skip.
lib/runner/resolve-secrets.js
Outdated
| return callback(); | ||
| } | ||
|
|
||
| var usedVariables = findUsedVariables(payload.item), |
There was a problem hiding this comment.
If we just run this logic on used variables, how would we make it work in scripts?
There was a problem hiding this comment.
Yes, we'll be resolving all secrets for now. making related changes.
lib/runner/resolve-secrets.js
Outdated
| } | ||
|
|
||
| if (values.members && Array.isArray(values.members)) { | ||
| values.members.forEach(function (variable) { |
There was a problem hiding this comment.
There is an each function on values - https://github.com/postmanlabs/postman-collection/blob/b3d052bdfcf304a8243f73618c6aa962ca517115/lib/collection/property-list.js#L412
lib/runner/resolve-secrets.js
Outdated
| } | ||
| }); | ||
| } | ||
| else if (Array.isArray(values)) { |
There was a problem hiding this comment.
This is to handle?
scope can be converted to VariableScope if it is not already one
package.json
Outdated
| { | ||
| "name": "postman-runtime", | ||
| "version": "7.51.1", | ||
| "version": "7.52.0-beta.2", |
package.json
Outdated
| "node-oauth1": "1.3.0", | ||
| "performance-now": "2.1.0", | ||
| "postman-collection": "5.2.0", | ||
| "postman-collection": "5.3.0-beta.1", |
There was a problem hiding this comment.
note: bump to correct version before merge
…esolver function to be single instead of interface
There was a problem hiding this comment.
Removing them completely now as not needed anymore. previous approach resolved secret here so they were left out.
| if (err) { | ||
| // Secret resolution failed - this is fatal for the current item | ||
| // (same pattern as pre-request script skip) | ||
| self.triggers.item(err, coords, item, null, { isSecretResolutionFailed: true }); |
There was a problem hiding this comment.
@appurva21 item trigger gets following args (err, coords, item, result, options). Added this to determine that error was because of the secret resolution and not in other place like pre-request, request, or tests. I don't think there's current usage so it can be removed if needed.
Ideally, if we expect from consumer to provide correct codes/errors from secretResolver side, it's not needed since error will have that info but if not then it'd be usefull field.
it's similar to how we pass { isSkipped: true } in case of execution skip.
lib/runner/resolve-secrets.js
Outdated
| return callback(); | ||
| } | ||
|
|
||
| var usedVariables = findUsedVariables(payload.item), |
There was a problem hiding this comment.
Yes, we'll be resolving all secrets for now. making related changes.
package.json
Outdated
| "node-oauth1": "1.3.0", | ||
| "performance-now": "2.1.0", | ||
| "postman-collection": "5.2.0", | ||
| "postman-collection": "git+ssh://git@github.com:postmanlabs/postman-collection.git#feature/secret-resolution", |
There was a problem hiding this comment.
We'll update this to correct version once we have related PR merged.
lib/runner/resolve-secrets.js
Outdated
| return callback(); | ||
| } | ||
|
|
||
| secretResolver({ secrets, payload }, function (err, result) { |
There was a problem hiding this comment.
Do we need to send the payload to secretResolver?
There was a problem hiding this comment.
@appurva21 Yes, it's used for context in cases like domain based resolution and such. i.e. If request URL is matching with allowed domain for vault secret, we'd resolved otherwise not.
Overview
This PR adds support for the optional secretResolvers interface that can accept various resolvers taking care of the actual resolution of variables of type secrets and their resolution.