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
fix(security): AggregationRunner — RBAC + multitenancy on native PG path
The Postgres-native fast path built raw SQL against `oc_<table>` with
only `_deleted IS NULL` in the WHERE. `loadSchema/loadRegister` passed
`_multitenancy: false`, the controller is `#[NoAdminRequired]`, and the
PHP fallback's RBAC was unreachable for the common metric set
(count/sum/avg/min/max). Net effect: any authed user could compute
aggregates over any schema in any tenant.
Changes:
- Inject PermissionHandler + IUserSession + OrganisationService.
- Gate run() on `hasPermission(schema, 'list', userId)` — fail-closed.
- Drop `_multitenancy: false` on loadSchema / loadRegister so the slug
lookup itself is tenant-scoped.
- Add `"organisation" = ?` predicate to tryNativeAggregation's WHERE,
mirroring MagicRbacHandler. Active org `null` ⇒ no rows.
- Include userId + active-org UUID in the AggregationCache key so two
callers with different RBAC verdicts can't read each other's cached
results (also addresses concern r3187494499).
Refs: #1419 review (blocker 2 + concern 8) — discussion_r3187494411,
discussion_r3187494499
0 commit comments