You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Result, on a clean checkout of feat/multicloud-web-frontend:
internal/api/handler_purchases.go:520:13: session.Role undefined (type *Session has no field or method Role)
This was not caught because CI does not gate on go build ./... / go test ./... (only pre-commit + read-only sanity + CodeRabbit run). Every open PR that compiles internal/api is blocked from a clean rebase by this (observed on #804 and #808), and any deploy built from this base would fail.
Fix
Remove the dead session.Role == "admin" shortcut from authorizeSessionExecuteDirect, matching its sibling gates. authorizeSessionApprove, authorizeSessionCancel, and the retry gate already have NO Role shortcut post-#907 - Administrators-group users pass via the HasPermissionAPI(ctx, session.UserID, auth.ActionExecuteAny, auth.ResourcePurchases) check immediately below (the Administrators group carries the {admin, *} wildcard permission, which matches ExecuteAny). The function's own doc comment even says it "mirrors authorizeSessionApprove / authorizeSessionCancel", which no longer use Role.
Concretely:
Delete the 3-line if session.Role == "admin" { return nil } block at the top of authorizeSessionExecuteDirect.
Update the gate-logic doc comment: drop the "admin role: always permitted" bullet; note admins pass via the execute-any permission (matching the sibling functions' comments).
Acceptance criteria
go build ./... succeeds on the branch.
A regression test asserts an Administrators-group user (no execute-own/any explicit grant) is still permitted by authorizeSessionExecuteDirect via the wildcard HasPermissionAPI(ExecuteAny) path (so removing the shortcut does not lock admins out).
Non-admin without execute-any/own is still 403; nil auth component is still 500 (fail-closed unchanged).
Provenance
Discovered by the pr-iterate sweep while rebasing #804 and #808; both correctly STOPPED rather than fixing base code out-of-scope.
Severity: base branch
feat/multicloud-web-frontenddoes not compileTwo already-merged PRs are mutually inconsistent, leaving the base branch in a non-building state:
authorizeSessionExecuteDirectininternal/api/handler_purchases.go, which starts with:Rolefield fromapi.Session(nowtype Session struct { UserID string; Email string }).Result, on a clean checkout of
feat/multicloud-web-frontend:This was not caught because CI does not gate on
go build ./.../go test ./...(only pre-commit + read-only sanity + CodeRabbit run). Every open PR that compilesinternal/apiis blocked from a clean rebase by this (observed on #804 and #808), and any deploy built from this base would fail.Fix
Remove the dead
session.Role == "admin"shortcut fromauthorizeSessionExecuteDirect, matching its sibling gates.authorizeSessionApprove,authorizeSessionCancel, and the retry gate already have NORoleshortcut post-#907 - Administrators-group users pass via theHasPermissionAPI(ctx, session.UserID, auth.ActionExecuteAny, auth.ResourcePurchases)check immediately below (the Administrators group carries the{admin, *}wildcard permission, which matchesExecuteAny). The function's own doc comment even says it "mirrors authorizeSessionApprove / authorizeSessionCancel", which no longer use Role.Concretely:
if session.Role == "admin" { return nil }block at the top ofauthorizeSessionExecuteDirect.Acceptance criteria
go build ./...succeeds on the branch.authorizeSessionExecuteDirectvia the wildcardHasPermissionAPI(ExecuteAny)path (so removing the shortcut does not lock admins out).Provenance
Discovered by the pr-iterate sweep while rebasing #804 and #808; both correctly STOPPED rather than fixing base code out-of-scope.