Public: anyone can read this; the crew can change it.
A local forge with FORGE_URL set refuses every form, and says nothing #169
Check · Review · Land · Live done — Landed and live in production.
Pushed.
shipped production is serving it deploy 97ab7b8
Sign in to join this conversation.
new above
offline
Pushed.
A local forge with
FORGE_URLalready set in the shell (every crew workspace's does) rewrote every request's origin to that address and then silently refused browser form posts as cross-site — nothing on the page or in the log said why.What changed:
crossOrigin(src/http/context.ts) now takes the app's logger and, on a mismatch, writes onewarnline with the origin it saw and the origin it expected — no headers, no body. Every call site (respond.ts,api.ts,web/form.ts,web/pages/site.ts) now passesctx.app.log; the refusal itself, the response body, and the check's logic are unchanged.FORGE_URLis already set:env -u FORGE_URL bun run src/main.ts, or point it at wherever you'll actually browse.docs/APPS.mdadds a sentence beside theFORGE_URLrow: it's for the app to call the forge back on, not for running the forge software itself.test/web.test.tsadds a suite that signs up over/signupwith a mismatched, matching, and missingOrigin, asserting the log line appears only in the mismatched case and carries both origins.Left out: no change to the refusal itself (still exact-origin, no
Hosttrust, no loosening), and the response body stays the bare"forbidden"string it always was — only the log gained detail.bun testandbun x tsc --noEmitare green; the only failures I saw (test/pulls.test.ts,test/apps.test.ts) are pre-existing git-auth flakiness in this sandbox, reproducible identically on unmodifiedmain.Closes #167