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
{{ message }}
Repository navigation
Commit eb85a50
Browse filesBrowse the repository at this point in the historyBrowse files
feat(api/auth): split execute:ri-exchange from execute:purchases (closes#660) (#891)
RI exchanges are financially irreversible once submitted to AWS. Keeping
execute:ri-exchange disjoint from execute:purchases ensures a user who
can initiate regular purchases cannot inadvertently (or intentionally)
trigger an RI exchange without an explicit additional grant.
Changes:
- Add ResourceRIExchange = "ri-exchange" constant to internal/auth/types.go
- Update executeExchange handler to require execute:ri-exchange (was
execute:purchases)
- Update TestExecuteExchange_PermissionGate to assert the new permission
verb; add isolation sub-test proving execute:purchases does not grant
ri-exchange access
- Add /api/ri-exchange/* routes to openapi.yaml with 403 responses and
permission documentation on the execute endpoint
- Add 'ri-exchange' to the frontend Resource closed-union type and
extend canAccess tests: admin true, user false (no default grant);
add isolation sub-tests proving execute:purchases does not imply
execute:ri-exchange (and vice versa) on the frontend gating mirror
Rebased onto feat/multicloud-web-frontend post #922 (effectivePermissions
migration). The conflict in frontend/src/__tests__/permissions.test.ts
was resolved by re-expressing the user-default-deny invariant in the new
effective-permissions model: a non-admin holding execute:purchases is
still denied execute:ri-exchange. Em-dashes scrubbed from added prose.
No DB migration needed: role defaults are computed at runtime from
Go constants; no DB table stores the permission set.
No conflict with PR #884 (fix/476): that PR adds 403 to plans/purchases
routes; this PR adds a new ri-exchange section that #884 does not touch.
0 commit comments