Files
pulse/internal/api/alerting
rcourtman 94f96eb043 Stop tenant monitor lookups falling back to the default org
The agent, alert, notification and system settings handlers resolved
the request organization's monitor through the tenant manager and, when
that lookup failed for any reason, quietly used the default
organization's monitor instead. A request for another organization
could then list, change or remove the default organization's agents,
alert configuration, webhooks and email settings.

The router's tenant guard already answers 503 tenant_unavailable when a
non-default organization's monitor cannot be resolved, so normal
requests never reached that fallback. The handlers still used it when
a lookup failed after the guard had passed (an organization being
deleted mid-request) and for callers outside the guarded chain. These
routes are open to organization owners, so the handlers have to fail
closed on their own.

Each getMonitor now falls back to the primary monitor only for the
default organization. Any other organization whose monitor cannot be
resolved gets nil, and the HTTP handlers resolve the monitor once
through requireMonitor, which answers the same 503 tenant_unavailable
as the router guard. Default-organization and single-tenant behaviour is
unchanged.

The configuration handlers' getContextState already refused non-default
organizations and is covered by an existing test.

Contract-Neutral: Handlers now return the router tenant guard's existing 503 tenant_unavailable response instead of the default org's data; no new API surface.
2026-10-17 10:14:21 +01:00
..