Skip to content

fix(api/purchases): base build broken - session.Role removed by #907 but still used in authorizeSessionExecuteDirect (#803) #940

Description

@cristim

Severity: base branch feat/multicloud-web-frontend does not compile

Two already-merged PRs are mutually inconsistent, leaving the base branch in a non-building state:

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.

No activity

Activity on this issue will appear here.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions