Summary
Add tests that enforce per-account permissions across the API, so a user with allowed_accounts: ["uuid1"] cannot read or mutate data for uuid2 — even via aggregated endpoints.
Background
specs/multi-account-execution/api.md documents the accounts permission resource type and the allowed_accounts constraint on existing permissions:
The allowed_accounts constraint on existing permissions continues to work: a user with view on recommendations and allowed_accounts: ["uuid1"] only sees recommendations from account uuid1.
We already have authz at the router (#178) and federation guards (#234), but we don't have a comprehensive test suite that pins per-account scoping across every endpoint that returns or accepts cloud_account_id-tagged data.
Acceptance criteria
- Table-driven tests for every endpoint that surfaces per-account data — recommendations, purchases, history, plans, dashboard summary, freshness — verifying:
- User with
allowed_accounts: ["a"] sees only account a's rows in list responses.
- Same user is rejected (403 / filtered out) when fetching by
cloud_account_id = b.
- Same user cannot mutate (
POST / PUT / DELETE) anything tagged cloud_account_id = b.
- Aggregated endpoints (e.g. dashboard summary) compute the aggregate over the allowed subset, never the full set.
- Regression for the federation/cross-account exec path: a user with
allowed_accounts: ["a"] cannot trigger a fan-out that touches b.
- Tests live alongside existing handler tests (
internal/api/handler_*_test.go) — no new top-level test directory.
Out of scope
Permission UI surfaces — that's a separate frontend concern. This issue is the backend-enforcement test surface.
Summary
Add tests that enforce per-account permissions across the API, so a user with
allowed_accounts: ["uuid1"]cannot read or mutate data foruuid2— even via aggregated endpoints.Background
specs/multi-account-execution/api.mddocuments theaccountspermission resource type and theallowed_accountsconstraint on existing permissions:We already have authz at the router (#178) and federation guards (#234), but we don't have a comprehensive test suite that pins per-account scoping across every endpoint that returns or accepts
cloud_account_id-tagged data.Acceptance criteria
allowed_accounts: ["a"]sees only accounta's rows in list responses.cloud_account_id = b.POST/PUT/DELETE) anything taggedcloud_account_id = b.allowed_accounts: ["a"]cannot trigger a fan-out that touchesb.internal/api/handler_*_test.go) — no new top-level test directory.Out of scope
Permission UI surfaces — that's a separate frontend concern. This issue is the backend-enforcement test surface.