fix: show selected owner's external auth when creating a workspace - #26653
Merged
Conversation
When an admin created a workspace for another user, the external authentication section reflected the admin's own auth state instead of the selected owner's, because the endpoint and form keyed external auth by template version only. The external-auth endpoint now accepts an optional user_id. When it differs from the requester, it authorizes create-workspace-for-owner, reads the owner's link status under an elevated read-only context, and omits the authenticate URL. The create form threads the selected owner through the query and shows a read-only status for other users instead of a login button that would authenticate the admin.
Contributor
Docs previewCheck off each page once it's been reviewed. If a page changes in a later push, its checkbox clears automatically so it gets a fresh look. Pages not yet wired into the docs navigation aren't listed here. |
…wner # Conflicts: # coderd/templateversions.go
Replace AsSystemRestricted with a new AsExternalAuthChecker actor when reporting or validating a workspace owner's external auth state. The new subject can only read and refresh a user's external auth links (ResourceUser personal read/update) instead of granting read on every resource plus broad writes. Applied to both call sites of templateVersionExternalAuthForUser: the create-workspace form endpoint and the create-time owner check.
…ok arg Give getTemplateVersionExternalAuth and the templateVersionExternalAuth query/key a userId = "me" default instead of an optional param, and make useExternalAuth's userId required so callers must say whose external auth they want. Update TaskPrompt to pass "me" explicitly.
code-asher
approved these changes
Jul 6, 2026
code-asher
left a comment
Member
There was a problem hiding this comment.
Tested and looks good to me!
nickvigilante
approved these changes
Jul 23, 2026
nickvigilante
left a comment
Contributor
There was a problem hiding this comment.
docs/reference/api/templates.md LGTM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an admin creates a workspace for another user, the External Authentication section now reflects the selected owner's auth state instead of the admin's.
Previously the form always reported the requesting admin's external auth, so an admin connected to a provider saw "Authenticated" and could submit even when the target owner had never connected it.
Behavior
Implementation details & decisions
Root cause. External auth was keyed by template version only. The backend endpoint looked up links using the requester's ID, and the form never passed the selected owner.
Backend.
GET /templateversions/{ver}/external-authaccepts an optionaluser_id. When it differs from the requester, the requester is authorized forcreate workspace as that owner(mirroring workspace creation). The owner's link status is then read under an elevated read-only context, so admins who can create for others but lack personal read access (e.g. org admins) still work. The build path already resolves external auth per owner, so this only corrects the form.Decisions / tradeoffs.
authenticate_urlis omitted for non-self responses so the UI cannot offer a login action that would authenticate the wrong account.Tests. Backend: an org admin (create-for-owner, no personal read) sees the owner's state; a plain member is forbidden. Frontend: Storybook play tests cover the read-only status and the "another user" form state.
Generated by Coder Agents on behalf of @aslilac.