Conversation
…endpoint is selected Add NodeHelpers.displayParameterPath filtering to CredentialResolverEditModal to respect displayOptions constraints. When the OAuth2 resolver validation method is set to "oauth2-userinfo", clientId and clientSecret fields are now hidden as they are not needed for that flow. Resolves IAM-142 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
| return selectedType.value.options.map(toNodeProperty).filter((property) => { | ||
| if (property.type === 'hidden') return false; | ||
| if (!property.displayOptions) return true; | ||
| return NodeHelpers.displayParameterPath( |
There was a problem hiding this comment.
resolverProperties uses resolverData.value inside its computed getter, but resolverData is declared later; if the computed runs immediately, this can throw due to temporal dead zone.
Details
✨ AI Reasoning
1) The new filtering logic in the computed getter reads resolverData to evaluate displayOptions.
2) resolverProperties is defined before resolverData in the script.
3) If the computed getter runs during computed creation (common to establish reactive dependencies), it will access resolverData while it is still in the temporal dead zone.
4) That makes the control flow impossible to satisfy without error: evaluating resolverProperties can crash before resolverData exists.
🔧 How do I fix it?
Trace execution paths carefully. Ensure precondition checks happen before using values, validate ranges before checking impossible conditions, and don't check for states that the code has already ruled out.
Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
There was a problem hiding this comment.
computed() creates a lazy getter — the callback is not executed at declaration time, only when .value is first accessed. By the time any code reads resolverProperties.value, resolverData is already declared and initialized. There’s no TDZ risk here.
This is standard Vue 3 Composition API — computed properties commonly reference each other regardless of declaration order. The bot is applying a raw JS TDZ rule that doesn’t apply to lazy evaluations.
cstuncsik
changed the title
Bundle ReportChanges will increase total bundle size by 1.71kB (0.0%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: editor-ui-esmAssets Changed:
Files in
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
cubic analysis
No issues found across 2 files
Linked issue analysis
Linked issue: IAM-142: Do not display client secret field in resolver when user info endpoint is selected
| Status | Acceptance criteria | Notes |
|---|---|---|
| ✅ | GIVEN a user is using dynamic creds, WHEN they configure an oauth resolver and select user info endpoint, THEN the client secret field is hidden | Filtering hides clientSecret when validation is oauth2-userinfo |
| ✅ | Optionally hide client secret field | Implement displayOptions-based hiding for clientSecret |
| ✅ | Frontend evaluates displayOptions for resolver fields so UI can hide/show fields based on resolverData | Added NodeHelpers.displayParameterPath usage to resolverProperties filter |
| ✅ | UI should clearly indicate what data we need from the user (hide irrelevant inputs) | Resolver modal now filters out irrelevant fields via displayOptions |
| ❌ | Add estimations in T-Shirt sizes to the issue as requested | No T-Shirt estimation added in diffs or PR description |
Architecture diagram
sequenceDiagram
participant User as User Interface
participant Modal as CredentialResolverEditModal
participant API as Backend API
participant Helpers as n8n-workflow (NodeHelpers)
participant Inputs as CredentialInputs Component
User->>Modal: Open Edit Resolver
par Fetching Definitions and Data
Modal->>API: getCredentialResolverTypes()
API-->>Modal: Resolver Definitions (with displayOptions)
Modal->>API: getCredentialResolver(id)
API-->>Modal: Current Resolver Config (e.g. validation method)
end
Note over Modal,Helpers: NEW: Compute visible fields dynamically
loop For each property in definition
Modal->>Helpers: NEW: displayParameterPath(resolverData, property)
alt Property "displayOptions" matches current data
Helpers-->>Modal: Return true (Visible)
else Property "displayOptions" does not match
Note right of Helpers: e.g. "oauth2-userinfo" selected,<br/>hiding "clientSecret"
Helpers-->>Modal: Return false (Hidden)
end
end
Modal->>Inputs: CHANGED: Pass filtered "credentialProperties"
Note over Inputs: Renders only properties that<br/>passed displayOptions check
Inputs-->>User: Display fields (Client ID/Secret hidden if applicable)
Verifies fields dynamically hide when user switches validation method from oauth2-introspection to oauth2-userinfo. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
cstuncsik
requested review from
a team,
BGZStephen,
afitzek,
guillaumejacquart and
phyllis-noester
and removed request for
a team
- Extract createCredentialInputsSpy() to deduplicate test setup - Replace Options API updated() with Composition API watch() for prop capture - Add create-mode test verifying CredentialInputs doesn't render without type selection Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/frontend/editor-ui/src/app/components/CredentialResolverEditModal.test.ts">
<violation number="1" location="packages/frontend/editor-ui/src/app/components/CredentialResolverEditModal.test.ts:395">
P3: This test doesn't exercise or assert any displayOptions filtering in create mode, so it's effectively a placeholder and risks masking missing coverage. Either remove it or simulate selecting the OAuth type and assert the filtered fields.
(Based on your team's feedback about avoiding vacuous tests.) [FEEDBACK_USED]</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
packages/frontend/editor-ui/src/app/components/CredentialResolverEditModal.test.ts
Outdated
Show resolved
Hide resolved
guillaumejacquart
left a comment
guillaumejacquart
left a comment
There was a problem hiding this comment.
Looks good to me !
The test didn't exercise any filtering logic — it only verified CredentialInputs doesn't render without a type selected, which is unrelated to displayOptions. The filtering code path is identical for create and edit mode and is already covered. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
cstuncsik
deleted the
iam-142-do-not-display-client-secret-field-in-resolver-when-user-v2
branch
…oint is selected (#26340) Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
|
Got released with |
2 participants
Summary
When configuring an OAuth2 credential resolver with the "UserInfo Endpoint" validation method, the
clientIdandclientSecretfields are now correctly hidden. The backend already defineddisplayOptionson these fields, but the frontend modal was not evaluating them. This addsNodeHelpers.displayParameterPathfiltering toresolverPropertiesinCredentialResolverEditModal.vue.Related Linear tickets, Github issues, and Community forum posts
https://linear.app/n8n/issue/IAM-142
Review / Merge checklist
release/backport(if the PR is an urgent fix that needs to be backported)