@bakery-framework/core 2.0.0-alpha.6 → 2.0.0-alpha.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bakery-framework/core",
-  "version": "2.0.0-alpha.6",
+  "version": "2.0.0-alpha.8",
   "description": "Bakery framework core: handlers, router, config, session, caches, logger, compiler.",
   "keywords": [
     "bakery",

package/src/core/index.ts

@@ -4,6 +4,10 @@ import { Case, is, Math2, match, Try } from '../utils/common'
 import { encodeSSE, response, sse } from '../utils/http'
 import Bakery, { getHostname, hostKey, hostStore } from './bakery'
 import { getConfig, NOOP } from './config'
+// `./context` is already in this barrel's graph — line 5 reaches it through
+// `./bakery`, which re-exports `hostStore` from exactly here — so naming it
+// adds no module edge, only a name.
+import { getFrameworkVersion } from './context'
 import { createElement, Fragment, html } from './jsx'
 
 export const defineConfig = <T extends AppConfig>(config: T): T => config
@@ -63,6 +67,19 @@ export {
   encodeSSE,
   Fragment,
   getConfig,
+  /**
+   * The version of `@bakery-framework/core` itself, read from its own manifest.
+   *
+   * **Not the app's version**, which is what `import.meta.env.BAKERY_VERSION`
+   * and `getAppVersion()` report — the compiler reads those from
+   * `<cwd>/package.json`, so in an application they answer with the
+   * application's number. The name is a long-standing misnomer and this is the
+   * one that means what "Bakery version" sounds like it means.
+   *
+   * Exported because a plugin rendering framework chrome has no other way to
+   * ask. The dashboard's footer showed a hardcoded `v3` for want of it.
+   */
+  getFrameworkVersion,
   // Multi-host helpers. Documented in docs/configuration/multi-host.md, and
   // the only reason `./core/bakery` had to be a subpath of its own.
   getHostname,

package/src/handlers/core/$registry.ts

@@ -30,11 +30,16 @@ export class HandlerMap<T extends typeof Handler = typeof Handler> extends Map<
     }
   }
 
-  set(handlerClass: any, priority: number = 10): this {
-    super.set(handlerClass, priority)
+  /** Drop the derived views. Every mutation has to call this, not just `set`. */
+  private invalidate(): void {
     this.cachedList = null
     this.cachedGates = null
     this.cachedOrder = null
+  }
+
+  set(handlerClass: any, priority: number = 10): this {
+    super.set(handlerClass, priority)
+    this.invalidate()
     return this
   }
 
@@ -42,6 +47,30 @@ export class HandlerMap<T extends typeof Handler = typeof Handler> extends Map<
     return this.set(handlerClass, priority)
   }
 
+  /**
+   * `delete` and `clear` invalidate too, and neither used to.
+   *
+   * `list()` memoizes the sorted handler array and only `set` cleared it, so a
+   * removed handler stayed in the list — and therefore stayed *in the request
+   * pipeline* — until something happened to add one. Registration is
+   * add-only in a served process, which is why this never bit: it is reachable
+   * only by code that unregisters, and the first thing to do that was a test.
+   *
+   * A cache that survives the removal of its input is wrong regardless of who
+   * currently calls it, and "nothing removes handlers today" is a property of
+   * the callers rather than of this class.
+   */
+  override delete(handlerClass: any): boolean {
+    const removed = super.delete(handlerClass)
+    if (removed) this.invalidate()
+    return removed
+  }
+
+  override clear(): void {
+    super.clear()
+    this.invalidate()
+  }
+
   list(): T[] {
     if (this.cachedList) {
       return this.cachedList

package/src/handlers/core/$routing.ts

@@ -21,15 +21,37 @@ export type RouteScanOptions = {
 const catchAllGlob = (ext: string) => new Bun.Glob(`[[]...*${ext || '.*'}`)
 
 // The single-param route forms, in the order they are tried: `[name].ext`
-// first, then the escaped-literal `*.ext`. Built here rather than twice inside
+// first, then the literal-asterisk `*.ext`. Built here rather than twice inside
 // `routeGlobs` — the `dynamicOnly` branch and the combined branch returned
 // character-identical pairs, and the two must stay in step or a route form
 // resolves under one caller and not the other. A function, not a hoisted
 // constant: `ext` varies per handler, and `staticOnly` returns before it needs
 // them at all.
-const dynamicGlobs = (ext: string) => [
+//
+// **The literal asterisk is a character class, `[*]`, never the escape `\*`.**
+// A backslash is the obvious spelling and is unusable on Windows, where `\` is
+// a path separator: Bun read `\*.*` as a drive-absolute pattern, ignored the
+// `cwd` in `GETFILE` entirely, and matched files at `C:\`. A route lookup under
+// a serve root six levels down returned `C:\$WINRE_BACKUP_PARTITION.MARKER`,
+// and `fs.isForbidden` — whose walk is bounded by `startsWith(root)` — waved it
+// through because an out-of-root path skipped the loop and answered "allowed".
+// That clamp now fails closed, so this is belt and braces; both halves are
+// pinned, and neither test can see the other's bug.
+//
+// Measured with a scan whose cwd was a temp directory holding one file: `[*]`
+// yields nothing, `\*` yields four files from the drive root. The escape is
+// also unreachable on Windows in the direction it was meant for — `*` is a
+// reserved character in a Windows filename, so a route file literally named
+// `*.ts` can only exist on POSIX, where both spellings match it identically
+// (verified on Linux). The character class costs nothing and means the same
+// thing on both platforms.
+//
+// Exported only as a test seam: with the clamp in place no test driving
+// `getRoute` can tell the two spellings apart — verified by reverting this line
+// and watching all 17 pass — so the pattern has to be asserted directly.
+export const dynamicGlobs = (ext: string) => [
   new Bun.Glob(`[[][!.]*${ext || '.*'}`),
-  new Bun.Glob(`\\*${ext || '.*'}`),
+  new Bun.Glob(`[*]${ext || '.*'}`),
 ]
 
 const routeGlobs = (

package/src/utils/fs.ts

@@ -395,6 +395,35 @@ export namespace FileSystem {
     let curr = safeResolve(pathToCheck)
     const normalizedRoot = safeResolve(root)
 
+    // A path outside `root` is forbidden, and this is the clause that says so.
+    //
+    // The walk below is bounded by `curr.startsWith(normalizedRoot)`, so an
+    // out-of-root path skipped the loop body entirely and fell through to
+    // `return false` — "not forbidden". That is a guard failing *open* on the
+    // one input it most needs to refuse, and it made every caller that relied
+    // on this for containment (all of them: `constants.ts` said so in as many
+    // words) incapable of catching an escape.
+    //
+    // Not theoretical. `$routing.ts` builds its route globs with `\*` to mean a
+    // literal asterisk; on Windows a backslash is a path *separator*, so Bun
+    // read the pattern as drive-absolute, ignored `cwd`, and matched files at
+    // `C:\`. `getRoute` resolved one, asked this function, was told "allowed",
+    // and returned an `Info` pointing six levels above the serve root. The glob
+    // is fixed too, but the glob was only how it was reached — a resolved file
+    // outside the root has to be refused here whatever produced it.
+    //
+    // The separator suffix matters: a bare `startsWith` would also accept a
+    // sibling directory whose name merely begins with the root's. A root that
+    // is already a filesystem root ends in `/` and must not gain a second one —
+    // `C://` matches nothing, which would make every path under `C:/` read as
+    // an escape. `fs.test.ts` drives both through its root corpus.
+    const rootPrefix = normalizedRoot.endsWith('/')
+      ? normalizedRoot
+      : `${normalizedRoot}/`
+    if (curr !== normalizedRoot && !curr.startsWith(rootPrefix)) {
+      return true
+    }
+
     const store = hostStore.getStore()
     const seen = store ? (store.forbiddenProbes ??= new Map()) : null