@zerotal/core 1.13.3 → 1.13.4

package/CHANGELOG.md

@@ -8,6 +8,26 @@ follows the Zerotal monorepo's unified versioning.
 
 ## [Unreleased]
 
+## [1.13.4] — 2026-09-01
+
+### Fixed
+
+- **The site gate's staff bypass was a denylist, and failed open.** 1.13.3 admitted any
+  authenticated user whose role was not literally `"customer"`. In an app whose roles are
+  `user` and `admin` — which is most of them — that is every signed-in visitor, so a
+  private preview showed the site to anyone with an account. A gate that fails open is
+  worse than no gate, because it reports success while doing nothing.
+
+  It is now an allowlist: `gate.staffRoles`, defaulting to `["admin"]`. An app whose staff
+  role is named something else gets no bypass and notices, which is the safe direction to
+  be wrong in. The token path is unchanged.
+
+- **The same code broke `tsc` for apps that do not use the gate.** `role !== "customer"`
+  is a type error when an app's role union has no such member, and the framework ships TS
+  source, so the error landed on a feature the app never touched. The role is read as
+  `string` now, because the framework cannot know an app's role names and must not narrow
+  to them.
+
 ## [1.13.3] — 2026-08-31
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zerotal/core",
-  "version": "1.13.3",
+  "version": "1.13.4",
   "license": "MIT",
   "maturity": "stable",
   "private": false,

package/src/gate/GateMiddleware.ts

@@ -49,6 +49,22 @@ interface GateConfig {
    * of your routes a third party calls, so it has to be declared.
    */
   allow?: string[];
+  /**
+   * Roles admitted to a preview without a token.
+   *
+   * An **allowlist**, defaulting to `["admin"]`. An app whose staff role is named
+   * something else declares it here:
+   *
+   * ```ts
+   * // config/gate.ts
+   * export default { staffRoles: ["admin", "editor"] };
+   * ```
+   *
+   * It is a list rather than a rule because the framework cannot know an app's
+   * role names, and the shape it replaced — "anyone who is not a customer" —
+   * admitted every signed-in user in an app that has no role called `customer`.
+   */
+  staffRoles?: string[];
   /**
    * What the public gets during a **preview** — not maintenance, which is always
    * 503.
@@ -200,8 +216,25 @@ function _isStaff(ctx: HttpContext): boolean {
   if (!("user" in ctx)) return false;
   const user = ctx.user;
   if (typeof user !== "object" || user === null || !("role" in user)) return false;
-  const role = user.role;
-  return typeof role === "string" && role !== "customer";
+
+  // Widened to `string` deliberately. Comparing against an app's own role union
+  // is a type error when the app has no such member — 1.13.3 shipped
+  // `role !== "customer"` and broke `tsc` for every app whose roles are, say,
+  // `"user" | "admin"`, on a feature they were not using. The framework cannot
+  // know an app's role names, so it must not narrow to them.
+  const role: string = typeof user.role === "string" ? user.role : "";
+  if (!role) return false;
+
+  // An **allowlist**, and this is the load-bearing part. 1.13.3 asked
+  // `role !== "customer"`, which reads as "everyone except customers is staff" —
+  // so in an app whose roles are `user` and `admin`, every signed-in visitor was
+  // staff and the gate let the public straight through. A gate that fails *open*
+  // is worse than no gate, because it reports success.
+  //
+  // Defaulting to `admin` alone rather than to something broad, for the same
+  // reason: an app that names its staff role something else gets no bypass and
+  // notices, which is the safe direction to be wrong in.
+  return config.safe<string[]>("gate.staffRoles", ["admin"]).includes(role);
 }
 
 /** HMAC of the token hash under the app key, so the cookie cannot be forged. */