v0.6.3 — the deploy script follows the host to FileBrowser Quantum

The deploy script only. No rules change, no game change, and the built site is byte-for-byte what
0.6.2 produced — this repairs the path that publishes it.

Found trying to publish the 0.4.9f playtest build: every deploy died with "login failed: 404 404
page not found". The File Browser host has been upgraded to FileBrowser Quantum, a fork whose API
differs from the v2.63 one deploy-web.ts was written against. Three things moved at once, each
fatal on its own: auth is a session COOKIE rather than a JWT sent back as X-Auth, so a deploy that
ignored it would authenticate and then be rejected by every upload; the password is an X-Password
header, URL-encoded, rather than a JSON body field; and the path is a query parameter, with every
resource call also having to name a `source` — Quantum can serve several named stores and refuses
any call that does not say which, a concept the v2.63 API did not have.

Rewritten against the running instance's own bundle rather than guessed, the same discipline the
v2.63 version was written with. Two things worth knowing next time: the bundle is gzip-compressed,
so it needs gunzip before it can be grepped; and an endpoint that exists answers a bad password
with 401 while a missing one answers 404, which is how each path was confirmed against the live
host without holding a password.

The source is discovered from GET /api/settings/sources — one configured source is used silently,
several makes the script stop and list them rather than deploy into the wrong store. FB_SOURCE
overrides it, FB_OTP carries a two-factor code.

Verified by deploying with it rather than by reading: 0.4.9f went up this way. This is that same
file byte-identical, brought across to the main line — both branches carried the same broken
script, so deploying 0.6.x would have failed identically.

Also removes dist-test/, an untracked hand-made copy of a v0.6.2 dist/ build that no script or test
references. build-web.ts hardcodes dist and wipes it on every run, so nothing in the repo could
have produced that directory or would ever read it. .gitignore is deliberately unchanged: the
answer for a directory that should not exist is to delete it, not to hide it.

715 tests pass, tsc clean, site builds.
This commit is contained in:
Jesse.Markowitz
2026-08-22 22:04:23 -04:00
parent 7804756f11
commit 42adfda390
3 changed files with 140 additions and 36 deletions
+43
View File
@@ -19,6 +19,49 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
---
## 0.6.3 — 2026-08-23
The deploy script only. No rules change, no game change, and the built site is byte-for-byte what
0.6.2 produced — this repairs the path that publishes it.
### The host moved to FileBrowser Quantum
Found trying to publish the 0.4.9f playtest build: every deploy died with
`login failed: 404 404 page not found`. The File Browser instance has been upgraded to
**FileBrowser Quantum**, a fork whose API differs from the v2.63 one `deploy-web.ts` was written
against. Three things moved at once, each fatal on its own:
1. **Auth is a session COOKIE**, not a JWT returned in the response body and sent back as `X-Auth:`.
A deploy that ignored the cookie would authenticate and then be rejected by every upload.
2. **The password is a header** — `X-Password`, URL-encoded — not a JSON body field.
3. **The path is a query parameter** (`?path=`), and every resource call must also name a
**`source`**: Quantum can serve several named stores and refuses any call that does not say which
("no source provided"). The v2.63 API had no such concept at all.
Rewritten against the running instance's own bundle rather than guessed — the same discipline the
v2.63 version was written with, and worth repeating: the bundle at `/public/static/assets/index-*.js`
is **gzip-compressed**, so it has to go through `gunzip` before it can be grepped. Each path was then
confirmed against the live host by response code, which is the cheap way to tell a moved endpoint
from a bad password without holding a password: **an endpoint that exists answers 401, one that does
not answers 404.**
The source is discovered from `GET /api/settings/sources` — one configured source is used silently,
and several makes the script stop and list them rather than deploy the site into the wrong store.
`FB_SOURCE` overrides it; `FB_OTP` carries a two-factor code.
**Verified by deploying with it**, not by reading: 0.4.9f went up this way. This commit is the same
file, byte-identical, brought across to the main line — both branches had carried the same broken
script, so deploying 0.6.x would have failed in exactly the same way.
### Housekeeping
`dist-test/` removed — an untracked hand-made copy of a v0.6.2 `dist/` build, referenced by no
script and no test. `build-web.ts` hardcodes `dist` and wipes it on every run, so nothing in the repo
could have produced that directory or would ever read it. `.gitignore` is deliberately unchanged:
the answer for a directory that should not exist is to delete it, not to hide it.
---
## 0.6.2 — 2026-08-22
Three more from the v0.4.9e gameplay-testing round, now filed as Gitea issues: **#4** extras did not