@checkstack/auth-backend 0.5.3 → 0.5.5

package/CHANGELOG.md

@@ -1,5 +1,93 @@
 # @checkstack/auth-backend
 
+## 0.5.5
+
+### Patch Changes
+
+- 0626782: Guard the role editor against granting inert (and misleading) permissions to the
+  anonymous role.
+
+  RPC procedures carry two independent axes: `userType` (the hard authentication
+  gate) and `access` rules (authorization). An admin can grant the anonymous role
+  any access rule, but if the procedures needing that rule are `userType:
+"authenticated"`/`"user"`, the grant does nothing - the auth middleware rejects
+  unauthenticated callers BEFORE access rules are checked (so there is no security
+  hole; the grant is simply inert). After anonymous users started seeing
+  permission-gated UI, such a grant would surface as visible-but-broken controls.
+
+  - The backend now computes, from contract metadata, the access rules an anonymous
+    caller can actually use (a rule is "usable" iff at least one `public` procedure
+    requires it) via `pluginManager.getAnonymousUsableAccessRuleIds()`, exposed to
+    plugins through the plugin environment.
+  - `auth.getAccessRules` annotates each rule with `anonymousUsable`.
+  - `auth.updateRole` REFUSES to ADD a non-usable rule to the anonymous role
+    (existing grants are untouched, so no configuration can be wedged). This is a
+    guardrail, not an enforcement change - RPC authorization is unchanged.
+  - The role editor disables non-usable rules (with an explanation) when editing
+    the anonymous role.
+
+  Verified live: `getAccessRules` reports 11 anonymous-usable vs 58 not; granting
+  `incident.incident.manage` to the anonymous role returns HTTP 400 with a clear
+  message.
+
+- 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 [0626782]
+- Updated dependencies [56e7c75]
+  - @checkstack/backend-api@0.21.5
+  - @checkstack/auth-common@0.8.3
+  - @checkstack/common@0.15.0
+  - @checkstack/notification-common@1.3.3
+  - @checkstack/command-backend@0.2.5
+
+## 0.5.4
+
+### Patch Changes
+
+- Updated dependencies [b50916d]
+  - @checkstack/backend-api@0.21.4
+  - @checkstack/command-backend@0.2.4
+
 ## 0.5.3
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/auth-backend",
-  "version": "0.5.3",
+  "version": "0.5.5",
   "license": "Elastic-2.0",
   "type": "module",
   "main": "src/index.ts",
@@ -15,22 +15,22 @@
     "test": "bun test"
   },
   "dependencies": {
-    "@checkstack/auth-common": "0.8.2",
-    "@checkstack/backend-api": "0.21.3",
-    "@checkstack/notification-common": "1.3.2",
-    "@checkstack/command-backend": "0.2.3",
+    "@checkstack/auth-common": "0.8.3",
+    "@checkstack/backend-api": "0.21.5",
+    "@checkstack/notification-common": "1.3.3",
+    "@checkstack/command-backend": "0.2.5",
     "better-auth": "^1.6.13",
     "drizzle-orm": "^0.45.0",
     "hono": "^4.12.23",
     "kysely": "^0.28.17",
     "jose": "^6.2.3",
     "zod": "^4.2.1",
-    "@checkstack/common": "0.14.1",
+    "@checkstack/common": "0.15.0",
     "@orpc/server": "^1.14.4"
   },
   "devDependencies": {
     "@checkstack/drizzle-helper": "0.0.5",
-    "@checkstack/scripts": "0.6.0",
+    "@checkstack/scripts": "0.6.1",
     "@checkstack/tsconfig": "0.0.7",
     "@types/node": "^20.0.0",
     "@types/pg": "^8.20.0",

package/src/index.ts

@@ -323,11 +323,18 @@ export default createBackendPlugin({
       getStrategies: () => strategies,
     };
 
-    // Access rule registry - gets all access rules from PluginManager
+    // Access rule registry - gets all access rules from PluginManager, annotated
+    // with `anonymousUsable` (whether a `public` procedure actually requires the
+    // rule) so the role editor can guard anonymous-role grants.
     const accessRuleRegistry = {
       getAccessRules: () => {
-        // Get all access rules from the central PluginManager registry
-        return env.pluginManager.getAllAccessRules();
+        const usable = new Set(
+          env.pluginManager.getAnonymousUsableAccessRuleIds(),
+        );
+        return env.pluginManager.getAllAccessRules().map((rule) => ({
+          ...rule,
+          anonymousUsable: usable.has(rule.id),
+        }));
       },
     };
 

package/src/router.ts

@@ -190,6 +190,8 @@ export const createAuthRouter = (
       description?: string;
       isDefault?: boolean;
       isPublic?: boolean;
+      /** Whether an anonymous caller can actually use this rule (a public RPC requires it). */
+      anonymousUsable?: boolean;
     }[];
   },
   getBetterAuth: () =>
@@ -237,10 +239,24 @@ export const createAuthRouter = (
     return enabledStrategies.filter((s) => s.enabled);
   });
 
+  // The configurable "anonymous" role's grants - what an unauthenticated visitor
+  // is allowed. Same `roleAccessRule` store the enriched `user.accessRules` is
+  // built from, so the format matches and the frontend's access checks behave
+  // identically for guests and users.
+  const loadAnonymousAccessRules = async (): Promise<string[]> => {
+    const rolePerms = await internalDb
+      .select()
+      .from(schema.roleAccessRule)
+      .where(eq(schema.roleAccessRule.roleId, ANONYMOUS_ROLE_ID));
+    return rolePerms.map((rp) => rp.accessRuleId);
+  };
+
   const accessRulesHandler = os.accessRules.handler(async ({ context }) => {
     const user = context.user;
+    // Anonymous callers get the anonymous role's effective rules (NOT empty), so
+    // the UI can gate on what a guest may actually do.
     if (!isRealUser(user)) {
-      return { accessRules: [] };
+      return { accessRules: await loadAnonymousAccessRules() };
     }
     return { accessRules: user.accessRules || [] };
   });
@@ -436,6 +452,36 @@ export const createAuthRouter = (
     const isAnonymousRole = id === ANONYMOUS_ROLE_ID;
     if (isAnonymousRole) {
       const allPerms = accessRuleRegistry.getAccessRules();
+
+      // GUARDRAIL: refuse to ADD an access rule to the anonymous role that no
+      // `public` endpoint uses. The auth middleware rejects unauthenticated
+      // callers BEFORE checking access rules, so such a grant is inert and
+      // misleading (the admin would think anonymous users gained a capability
+      // they cannot actually use). Only NEWLY-added inert rules are blocked;
+      // anything already on the role is left untouched so this can never wedge
+      // an existing configuration.
+      const usableIds = new Set(
+        allPerms.filter((p) => p.anonymousUsable).map((p) => p.id),
+      );
+      const currentAnonRows = await internalDb
+        .select()
+        .from(schema.roleAccessRule)
+        .where(eq(schema.roleAccessRule.roleId, ANONYMOUS_ROLE_ID));
+      const currentAnonRules = new Set(
+        currentAnonRows.map((r) => r.accessRuleId),
+      );
+      const inertAdditions = validAccessRules.filter(
+        (p) => !usableIds.has(p) && !currentAnonRules.has(p),
+      );
+      if (inertAdditions.length > 0) {
+        throw new ORPCError("BAD_REQUEST", {
+          message:
+            "These access rules cannot be granted to the anonymous role - no " +
+            "public endpoint uses them, so only authenticated callers could " +
+            `ever exercise them: ${inertAdditions.join(", ")}`,
+        });
+      }
+
       const publicDefaultPermIds = allPerms
         .filter((p) => p.isPublic)
         .map((p) => p.id);
@@ -922,13 +968,7 @@ export const createAuthRouter = (
   );
 
   const getAnonymousAccessRules = os.getAnonymousAccessRules.handler(
-    async () => {
-      const rolePerms = await internalDb
-        .select()
-        .from(schema.roleAccessRule)
-        .where(eq(schema.roleAccessRule.roleId, ANONYMOUS_ROLE_ID));
-      return rolePerms.map((rp) => rp.accessRuleId);
-    },
+    async () => loadAnonymousAccessRules(),
   );
 
   const filterUsersByAccessRule = os.filterUsersByAccessRule.handler(