Skip to content

Adds support for secret resolution via support of secretResolver.#1543

Open
VShingala wants to merge 19 commits intodevelopfrom
feature/secret-resolution
Open

Adds support for secret resolution via support of secretResolver.#1543
VShingala wants to merge 19 commits intodevelopfrom
feature/secret-resolution

Conversation

@VShingala
Copy link
Member

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.

@codecov
Copy link

codecov bot commented Feb 4, 2026

Codecov Report

❌ Patch coverage is 3.30579% with 117 lines in your changes missing coverage. Please review.
✅ Project coverage is 41.09%. Comparing base (ad947cc) to head (971af12).

Files with missing lines Patch % Lines
lib/runner/extensions/item.command.js 1.78% 55 Missing ⚠️
lib/runner/resolve-secrets.js 4.25% 45 Missing ⚠️
lib/runner/extensions/event.command.js 5.55% 17 Missing ⚠️

❌ 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              
Flag Coverage Δ
unit 41.09% <3.30%> (-0.79%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Member

@appurva21 appurva21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we tracking changes to make scripts work separately?

certificates: options.certificates,
proxies: options.proxies
proxies: options.proxies,
secretResolvers: options.secretResolvers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be added to README

* @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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Will work on this and update.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have these changes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isSecretResolutionFailed why do we need this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

return callback();
}

var usedVariables = findUsedVariables(payload.item),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we just run this logic on used variables, how would we make it work in scripts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we'll be resolving all secrets for now. making related changes.

}

if (values.members && Array.isArray(values.members)) {
values.members.forEach(function (variable) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

}
});
}
else if (Array.isArray(values)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's revert this

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",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: bump to correct version before merge

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 });
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

return callback();
}

var usedVariables = findUsedVariables(payload.item),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll update this to correct version once we have related PR merged.

PR: postmanlabs/postman-collection#1421

@VShingala VShingala changed the title [Draft] Adds support for secret resolution via support of secretResolvers/ Adds support for secret resolution via support of secretResolver. Feb 20, 2026
@VShingala VShingala marked this pull request as ready for review February 20, 2026 14:41
return callback();
}

secretResolver({ secrets, payload }, function (err, result) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to send the payload to secretResolver?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants