feat(OIDC): API Access tab with trust relationships UI#8044
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
the
front-end
khvn26
changed the title
Docker builds report
|
f52d48d to
897e6b5
Compare
a9bf1ff to
5478a2a
Compare
github-actions
Bot
added
feature
5478a2a to
b88bd0c
Compare
897e6b5 to
ac0eb55
Compare
This comment was marked as duplicate.
This comment was marked as duplicate.
github-actions
Bot
added
feature
Visual Regression19 screenshots compared. See report for details. |
ac0eb55 to
f3d09e9
Compare
b88bd0c to
b767571
Compare
github-actions
Bot
added
feature
11cd374 to
2d8d889
Compare
83c6bd9 to
8a8c79c
Compare
github-actions
Bot
added
feature
8a8c79c to
153457d
Compare
github-actions
Bot
added
feature
github-actions
Bot
removed
feature
Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
|
…s UI The organisation settings API Keys tab becomes API Access and gains a Trust Relationships section behind the trust_relationships feature flag: list, create, edit and delete, with a claim-rules editor and the same admin toggle and RBAC role assignment flow as master API keys, attached via the backing key. Also fixes two latent request types in the master API key role services. beep boop
The GitHub/Other provider cards were div+onClick only, so keyboard and screen-reader users could not start the create flow. Add role="button", tabIndex and an Enter/Space onKeyDown handler. beep boop
addRole/removeRole mutated local role state unconditionally and never inspected the request result, so a failed assignment left the UI showing a role the backend never stored, with no error surfaced. Update local state only on success and toast on failure; also flag when role assignment fails during creation instead of silently swallowing it. beep boop
Adopt the component-folder layout the frontend guideline expects: every new component now lives in its own directory with an index.ts barrel (ComponentName/ComponentName.tsx + index.ts). providers.ts and errors.ts stay as flat modules, being exempt constants/util. Cross-component imports use the components/ alias, as the import-alias lint rule requires for parent-traversal paths; APIKeysTab keeps importing the tab via the unchanged ./trust-relationships path. beep boop
✅ private-cloud · depot-ubuntu-latest-16 — run #18626 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
🗂️ Previous results✅ private-cloud · depot-ubuntu-latest-arm-16 — run #18626 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
✅ oss · depot-ubuntu-latest-arm-16 — run #18626 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
✅ oss · depot-ubuntu-latest-16 — run #18626 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
✅ private-cloud · depot-ubuntu-latest-arm-16 — run #18528 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)
Details
✅ private-cloud · depot-ubuntu-latest-16 — run #18528 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-16)
Details
✅ oss · depot-ubuntu-latest-16 — run #18528 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-16)
Details
✅ oss · depot-ubuntu-latest-arm-16 — run #18528 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-arm-16)
Details
|
|
@themis-blindfold review |
![themis-blindfold[bot]](https://avatars.githubusercontent.com/in/4278417?s=60&v=4){kind=small}
| const addRole = (role: SelectedRole) => { | ||
| if (isEdit) { | ||
| createRoleMasterApiKey(getStore(), { | ||
| body: { master_api_key: trustRelationship.master_api_key_id }, | ||
| org_id: organisationId, | ||
| role_id: role.id, | ||
| }).then(() => toast('Role assigned')) | ||
| } | ||
| setRoles((selected) => [...selected, { id: role.id, name: role.name }]) |
There was a problem hiding this comment.
🟠 Major · ⚡ Quick win
Role add/remove and creation-flow role assignment ignore API failures — state drifts from server.
Observed: addRole (line 87) and removeRole (line 98) update local roles state unconditionally regardless of whether the API call succeeds. In addRole during edit mode, createRoleMasterApiKey fires and .then(() => toast('Role assigned')) runs on success, but setRoles on line 95 runs immediately outside the callback — even if the request fails. removeRole has the same shape. No .catch or res.error check exists.
Observed: the creation flow (lines 146–168) calls Promise.all over createRoleMasterApiKey for each role, then unconditionally toasts 'Trust relationship created' without inspecting res.error on the results.
The sibling GithubTrustRelationshipForm.tsx already has the correct pattern (lines 139–176): it checks res.error, shows a danger toast on failure, and only calls setRoles inside the success branch. The creation flow there checks results.some((res) => res.error) and warns the user about partial failures.
Predicted: if a role assignment API call returns an error (permissions, network, deleted role), the UI will show the role as assigned/removed while the server state is different, with no feedback to the user.
Fix direction: apply the same res.error-checking pattern from GithubTrustRelationshipForm to addRole, removeRole, and the creation-flow .then() in this file.
| const addRole = (role: SelectedRole) => { | |
| if (isEdit) { | |
| createRoleMasterApiKey(getStore(), { | |
| body: { master_api_key: trustRelationship.master_api_key_id }, | |
| org_id: organisationId, | |
| role_id: role.id, | |
| }).then(() => toast('Role assigned')) | |
| } | |
| setRoles((selected) => [...selected, { id: role.id, name: role.name }]) | |
| const addRole = (role: SelectedRole) => { | |
| if (isEdit) { | |
| createRoleMasterApiKey(getStore(), { | |
| body: { master_api_key: trustRelationship.master_api_key_id }, | |
| org_id: organisationId, | |
| role_id: role.id, | |
| }).then((res) => { | |
| if (res.error) { | |
| toast('Could not assign role', 'danger') | |
| return | |
| } | |
| setRoles((selected) => [...selected, { id: role.id, name: role.name }]) | |
| toast('Role assigned') | |
| }) | |
| return | |
| } | |
| setRoles((selected) => [...selected, { id: role.id, name: role.name }]) | |
| } |
There was a problem hiding this comment.
Confirmed — 90be5fa addresses all three issues raised here:
addRole/removeRole: The shareduseTrustRelationshipRoleshook (hooks/useTrustRelationshipRoles.ts:27-81) now checksres.errorbefore updating local state and shows a'danger'toast on failure, matching the pattern the review suggested.- Creation flow:
assignRoles(hooks/useTrustRelationshipRoles.ts:46-63) returns a boolean indicating whether all assignments succeeded, and the modal (TrustRelationshipModal.tsx:113-120) now surfaces partial failures with a distinct danger toast. - Drift prevention: Both
TrustRelationshipModalandGithubTrustRelationshipFormnow consume the sameuseTrustRelationshipRoleshook, so the two forms can't diverge again. The core logic is also extracted intocreateRoleHandlersfor unit testing.
Looks good to resolve.
⚖️ Themis judgement: 🟠 Fix before mergeSolid new feature: a trust-relationships management UI with a well-scoped RTK Query service, typed requests/responses, a GitHub-specific preset form, a generic OIDC form, and tab plumbing. The GitHub form's role error handling was fixed in earlier review rounds, but the same fix was never applied to its sibling
🟠 Majors
⚖️ Acknowledged
📝 Walkthrough
🧪 How to verify
Automate: add a component test for Product take: This unlocks OIDC token exchange for CI pipelines — a meaningful capability for teams adopting keyless authentication. The GitHub-specific preset with auto-audience and setup snippet lowers the bar considerably compared to manual OIDC configuration. Big picture: 🧭 Assumptions & unverified claims
A trust relationship is only as strong as its weakest modal. · reviewed at 5a3a2d8 |
The role add/remove fix from review only reached the GitHub preset form, leaving the freeform modal with optimistic state updates and success toasts on failed API calls. Role behaviour now lives in a single useTrustRelationshipRoles hook used by both forms — including partial failure reporting when assigning roles after creation — with its core extracted for unit tests, so the two forms cannot drift again. beep boop
3 participants
Thanks for submitting a PR! Please check the boxes below:
docs/if required so people know about the feature.Changes
Contributes to #8040
In this PR, we add a Trust relationships management UI.
The organisation settings "API Keys" tab is renamed to "API Access" and gains a Trust Relationships section, gated by the
trust_relationshipsfeature flag.Tabs now pass their stable key as the slug, and the label-derived legacy slug
?tab=api-keysredirects, like?tab=samlalready did.Creation is preset-based: a provider chooser offers "GitHub Actions" or a freeform "Other OIDC provider", kept for other providers and self-hosted issuers. The GitHub form asks for a repository, picked from the org's GitHub integration if configured, or typed manually otherwise, plus an optional environment. The audience is auto-derived:
https://github.com/<owner>(GitHub's zero-config default) for the first trust relationship per owner, a repo-scoped value once the default is taken.A YAML snippet for
Flagsmith/setup-cliaction is presented in create/edit modals for GitHub trust relationships.The "Is Admin" toggle is now accompanied by "available in enterprise" banner both for Master API Keys and Trust relationships.
Built in the modern RTK style (new
useTrustRelationshipservice, typed requests/responses) rather than extending the legacyAdminAPIKeys.js. Also fixes two latent types surfaced by typed usage:createRoleMasterApiKeywas missing itsbody, and thedeleteMasterAPIKeyWithMasterAPIKeyRoleshelper was annotated with the wrong request type.How did you test this code?
Locally, by hand; no new E2E tests yet.
Screenshots
Trust relationships list:
New trust relationship provider chooser:
GitHub modal:
GitHub setup snippet:
Generic provider modal:
