@checkstack/frontend-api 0.7.2 → 0.9.0

package/CHANGELOG.md

@@ -1,5 +1,108 @@
 # @checkstack/frontend-api
 
+## 0.9.0
+
+### Minor Changes
+
+- 56e7c75: Hide navigation, actions and links that the current user cannot use, so anonymous
+  and read-only users no longer see entries that lead to "Access Denied" or to
+  actions the server would reject.
+
+  - **Sidebar**: a nav entry can now declare a dynamic `nav.isVisible({ accessRules, isAuthenticated })` predicate (in addition to the static `accessRule`). A group whose every entry is filtered out is no longer rendered. The filtering/grouping logic is extracted to a pure, unit-tested helper.
+  - **Infrastructure**: its sidebar entry is shown only when the user can READ at least one contributed tab (queue, cache, …), instead of always (it previously had no static rule because tabs are contributed at runtime).
+  - **Notification Settings**: hidden from anonymous users - notifications are per-user, so an anonymous visitor can't have any.
+  - **Anomaly Mute / Suppress**: the "Mute" / "Mute all" controls (a per-user preference) are hidden from anonymous visitors; the "Suppress" control is gated on `anomalyAccess.feed.manage`. Both were previously always visible.
+  - **Dashboard**: the "Open Catalog" actions (which open the manage-only Catalog config page) are hidden from users without `catalogAccess.system.manage`, and the "View catalog" link is gated on `catalogAccess.system.read`.
+  - **Dashboard status signals**: the per-system status rows contributed by plugins (`SystemSignalsSlot`) now render as a LINK only when the user can open the target, and as plain text otherwise. `SystemSignal` gains an optional `accessRule`; the healthcheck, anomaly, and dependency fillers set it for their gated targets (check-history / assignments / dependency-map). Signals pointing at ungated pages (incident / maintenance / SLO detail) stay links.
+  - **Plugin Manager**: the "Install plugin" button (which opens the install-gated page) is hidden from users with only `plugin` view access.
+  - **Satellites**: the page is entirely manage-gated, but its route/sidebar entry was gated on `read`, so read-only users saw the nav item and hit "Access Denied" on click. The route and nav entry now require `satellite.manage`.
+
+  The `@checkstack/ai-backend` bump is only the regenerated bundled docs index
+  (the frontend routing guide gained the `nav.isVisible` section); no code change.
+
+  **BREAKING (`@checkstack/frontend-api`):** the `AccessApi` interface gains a
+  required `useIsAuthenticated()` method. Custom `AccessApi` implementations must
+  add it (it returns `{ loading, isAuthenticated }`). The built-in auth
+  implementation and the no-auth fallback already do. `NavEntry` also gains an
+  optional `isVisible` predicate (purely additive).
+
+### Patch Changes
+
+- 56e7c75: Fix frontend access checks to use FULLY-QUALIFIED access-rule ids, and resolve
+  the anonymous role on the frontend.
+
+  Granted access-rule ids are stored fully-qualified as `{pluginId}.{ruleId}` (e.g.
+  `incident.incident.read`) so two plugins defining the same short rule id never
+  collide. The frontend, however, was checking the UNqualified id (`incident.read`)
+  via `isAccessRuleSatisfied`, so every check failed for any user without the `*`
+  (admin) grant - masked in development because dev-auth grants `*`. This silently
+  broke ALL non-admin frontend gating (route guards, sidebar entries, and
+  `useAccess`-based button/link gating).
+
+  - **`@checkstack/common`**: `AccessRule` now carries a REQUIRED owning `pluginId`;
+    `access()` / `accessPair()` require and stamp it; `isAccessRuleSatisfied`
+    qualifies the rule (`{pluginId}.{id}`, plus the manage->read escalation) and
+    matches ONLY the qualified form. There is intentionally NO unqualified fallback
+    - matching a bare id would let one plugin's grant satisfy another plugin's
+      identically-named rule (a cross-plugin privilege-escalation flaw). Every plugin
+      that defines access rules now passes its own `pluginId`.
+  - **`@checkstack/backend`**: `pluginManager.getAllAccessRules()` no longer strips
+    the `pluginId` field (the rule `id` is already fully-qualified for the DB sync).
+  - **Route guard** (`@checkstack/frontend` / `@checkstack/frontend-api`) now
+    checks the FULL rule object (so it qualifies and escalates), not a bare id.
+  - **Anonymous role on the frontend**: the `accessRules` procedure is now
+    `public`, returning the configurable anonymous role's grants to unauthenticated
+    callers; `useAccessRules` fetches them for guests instead of returning an empty
+    set. So anonymous UI now reflects exactly what the anonymous role is allowed -
+    which an admin can change (`isPublic` is only the seeded default).
+  - Incident / maintenance / SLO detail routes are now read-gated (their read rule
+    is an `isPublic` default, so the anonymous role holds it unless an admin
+    revokes it); their dashboard status signals carry that rule and render as a
+    link only when the viewer may open it.
+
+  **BREAKING (`@checkstack/common`):** `AccessRule.pluginId` is now REQUIRED, and
+  `access()` / `accessPair()` require a `pluginId` option. `isAccessRuleSatisfied`
+  matches ONLY the fully-qualified `{pluginId}.{ruleId}` form - the previous
+  unqualified fallback is removed, because it was a cross-plugin
+  privilege-escalation flaw. Any code constructing an `AccessRule` or calling
+  `access()`/`accessPair()` must supply the owning `pluginId`.
+
+  Verified live against an anonymous caller: read pages resolve (qualified match),
+  manage actions are denied, manage->read escalation and `*` still work.
+
+- Updated dependencies [56e7c75]
+  - @checkstack/common@0.15.0
+  - @checkstack/signal-common@0.2.9
+
+## 0.8.0
+
+### Minor Changes
+
+- fb705df: Upgrade React 18 to React 19 across the platform.
+
+  **BREAKING (runtime frontend plugins):** React is shared as a Module Federation
+  singleton, so the host now provides **React 19** to every runtime plugin.
+  Frontend plugins built against React 18 must be rebuilt against React 19
+  (`react` / `react-dom` `^19`). The scaffold templates and the host/plugin MF
+  `requiredVersion` are updated to `^19`. `react` (and now `react-dom`) are pinned
+  to a single version across the workspace via syncpack so the singleton can never
+  skew (react and react-dom must match exactly).
+
+  The React 19 removed-API surface was audited - the codebase used only no-arg
+  `useRef()` (now `useRef<T | undefined>(undefined)`); no `ReactDOM.render`,
+  legacy context, string refs, or function-component `defaultProps`. This also
+  clears the `IMPORT_IS_UNDEFINED` build warnings for `React.use` /
+  `React.useOptimistic` (react-router 7 feature-detection), which React 19 exports.
+
+  The downstream `*-frontend` packages (and `@checkstack/infrastructure-common`)
+  receive only the mechanical `react` dependency bump (`patch`); the framework
+  packages carrying the shared-singleton change are bumped `minor`.
+
+### Patch Changes
+
+- @checkstack/common@0.14.1
+- @checkstack/signal-common@0.2.8
+
 ## 0.7.2
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/frontend-api",
-  "version": "0.7.2",
+  "version": "0.9.0",
   "license": "Elastic-2.0",
   "type": "module",
   "main": "./src/index.ts",
@@ -10,11 +10,11 @@
     "lint:code": "eslint . --max-warnings 0"
   },
   "peerDependencies": {
-    "react": "^18.3.1"
+    "react": "19.2.7"
   },
   "dependencies": {
-    "@checkstack/common": "0.14.1",
-    "@checkstack/signal-common": "0.2.8",
+    "@checkstack/common": "0.15.0",
+    "@checkstack/signal-common": "0.2.9",
     "@orpc/client": "^1.14.4",
     "@orpc/contract": "^1.14.4",
     "@orpc/tanstack-query": "^1.14.4",
@@ -22,10 +22,10 @@
   },
   "devDependencies": {
     "@types/bun": "^1.3.5",
-    "@types/react": "^18.0.0",
+    "@types/react": "^19.0.0",
     "typescript": "^5.0.0",
     "@checkstack/tsconfig": "0.0.7",
-    "@checkstack/scripts": "0.4.2"
+    "@checkstack/scripts": "0.6.1"
   },
   "checkstack": {
     "type": "tooling"

package/src/core-apis.ts

@@ -39,6 +39,21 @@ export interface AccessApi {
    * ```
    */
   useAccess(accessRule: AccessRule): { loading: boolean; allowed: boolean };
+  /**
+   * Whether the current user is authenticated (logged in). Use to gate UI that
+   * needs a real user but no specific access rule - e.g. per-user actions like
+   * muting your own anomaly notifications, which any logged-in user may do but
+   * an anonymous visitor may not.
+   *
+   * @example
+   * ```tsx
+   * const { isAuthenticated } = accessApi.useIsAuthenticated();
+   * if (isAuthenticated) {
+   *   // show the per-user action
+   * }
+   * ```
+   */
+  useIsAuthenticated(): { loading: boolean; isAuthenticated: boolean };
 }
 
 export const accessApiRef = createApiRef<AccessApi>("core.access");

package/src/plugin-registry.ts

@@ -1,4 +1,5 @@
 import type { ComponentType, ReactNode } from "react";
+import type { AccessRule } from "@checkstack/common";
 import { FrontendPlugin, Extension } from "./plugin";
 
 /** Lazy page loader, as declared on a {@link PluginRoute}. */
@@ -20,7 +21,12 @@ interface ResolvedRoute {
   load?: RouteLoader;
   element?: ReactNode;
   title?: string;
-  accessRule?: string;
+  /**
+   * The FULL access rule (not just its id) so the route guard can qualify it
+   * (`{pluginId}.{id}`) against the user's granted ids AND apply manage->read
+   * escalation. A bare id string could do neither.
+   */
+  accessRule?: AccessRule;
 }
 
 class PluginRegistry {
@@ -73,7 +79,7 @@ class PluginRegistry {
         load: route.load,
         element: route.element,
         title: route.title,
-        accessRule: route.accessRule?.id,
+        accessRule: route.accessRule,
       };
 
       // Add to route map for resolution
@@ -189,7 +195,7 @@ class PluginRegistry {
           load: route.load,
           element: route.element,
           title: route.title,
-          accessRule: route.accessRule?.id,
+          accessRule: route.accessRule,
           // Resolved sidebar entry (defaults applied) for routes that opt in.
           // `accessRule` here is the EFFECTIVE rule object (nav override, else
           // the route's own rule) the sidebar gates visibility on.
@@ -200,6 +206,10 @@ class PluginRegistry {
                 label: route.nav.label ?? route.title ?? route.route.id,
                 order: route.nav.order ?? 0,
                 accessRule: route.nav.accessRule ?? route.accessRule,
+                // Dynamic visibility predicate (e.g. Infrastructure: any
+                // readable tab; per-user entries: authenticated) — passed
+                // through so the sidebar can evaluate it.
+                isVisible: route.nav.isVisible,
               }
             : undefined,
         };

package/src/plugin.ts

@@ -122,6 +122,22 @@ export interface NavEntry {
    * (e.g. show on `read` while the page itself needs `manage`).
    */
   accessRule?: AccessRule;
+  /**
+   * Dynamic visibility predicate, evaluated with the current user's access
+   * rules and auth state. Use for entries whose visibility cannot be expressed
+   * as a single static `accessRule`:
+   *  - the Infrastructure entry, visible only if the user can read at least one
+   *    of the tabs contributed by other plugins at runtime;
+   *  - per-user entries (e.g. Notification Settings) that require an
+   *    authenticated user rather than a specific rule.
+   * Evaluated IN ADDITION to `accessRule` (both must pass). Returning `false`
+   * hides the entry; a group with no visible entries is not rendered.
+   */
+  isVisible?: (context: {
+    /** The current user's granted access-rule IDs (as `isAccessRuleSatisfied` expects). */
+    accessRules: string[];
+    isAuthenticated: boolean;
+  }) => boolean;
 }
 
 /** Fields common to every route, regardless of eager/lazy. */