feat: validate coder_secret requirements in dynamic parameters - #24697
feat: validate coder_secret requirements in dynamic parameters#24697dylanhuff-at-coder wants to merge 3 commits into
Conversation
b5e46ab to
6d771c8
Compare
|
/coder-agents-review |
Unmet template `coder_secret` requirements now surface as missing_secret diagnostics on the create-workspace page, disabling Create Workspace until the owner satisfies them and pointing at the `coder secret create` CLI docs for recovery. Secret metadata is read under the caller's own authorization context. Non-owners (e.g. admins rendering for another user) lack user_secret:read on the target per the User Secrets RFC, so they see a secret_validation_forbidden warning instead. This avoids a side-channel where a non-owner could enumerate a target user's secret env_names and file_paths by watching for missing_secret diagnostics. NotAuthorized denials are cached for the websocket lifetime; successes and transient errors re-fetch every render so that following the CLI guidance in another tab is picked up without a page reload. Refs PLAT-100.
6d771c8 to
a394903
Compare
There was a problem hiding this comment.
Clean authorization design, well-constructed anti-enumeration defense, and a test suite that proves what it claims. The TestDynamicRender_NonOwnerCannotLeakSecretRequirements test is a standout: it seeds a matching secret and verifies the non-owner still cannot observe satisfaction, which is the right way to pin an information-leak fix. The caching strategy (deny-only cache, live-refetch on success) is a deliberate UX choice that the code and tests document well.
1 P1, 1 P2, 6 P3, 2 P4, 3 Nit.
The P1 is the load-bearing issue: checkSecretRequirements emits hcl.DiagError for missing secrets, and ResolveParameters gates on diags.HasErrors() for ALL build transitions. A user who deletes a required secret (or whose template adds one) cannot stop or delete their workspace. Auto-delete is safe (non-owner warning path), but user-initiated stop/delete is not.
"What happens at three users: nothing. What happens when coder_secret adoption grows and template admins start adding secret blocks to established templates: workspaces become unstoppable." Hisoka
🤖 This review was automatically generated with Coder Agents.
…nsitions, add ticket in TODO
|
Added @aslilac and @jeremyruppel for a frontend review :) |
jeremyruppel
left a comment
There was a problem hiding this comment.
frontend changes look great to me! thank you for all the tests! 🙏
| github.com/coder/aisdk-go v0.0.9 | ||
| github.com/coder/boundary v0.8.4-0.20260304164748-566aeea939ab | ||
| github.com/coder/preview v1.0.8 | ||
| github.com/coder/preview v1.0.9-0.20260422211932-5e77eadfa551 |
There was a problem hiding this comment.
We should probably make and use the 1.0.9 official tag in coder/preview here.
There was a problem hiding this comment.
Chatted in DMs with Dylan and we're going to revisit this to more closely align with the Figma mockups/design
aslilac
left a comment
There was a problem hiding this comment.
just one small note, the frontend code seems fine
| @@ -4,7 +4,7 @@ import ( | |||
| "context" | |||
| "database/sql" | |||
| "io/fs" | |||
| "log/slog" | |||
| stdslog "log/slog" | |||
There was a problem hiding this comment.
why are we bringing in two slog libraries? I can only find one other reference to "log/slog" in the codebase, so I think this deserves a bit of justification

Integrates
coder_secretrequirements from the preview renderer into dynamic parameter evaluation. Missing owner secrets now surface as dynamic parameter diagnostics, with UI guidance forcoder secret create; callers without secret read access get a non-blocking validation warning.Workspace starts enforce missing secrets, while stop and delete transitions filter those diagnostics so unmet secret requirements do not prevent cleanup.
Refs PLAT-100