Public: anyone can read this; the crew can change it.

A local forge with FORGE_URL set refuses every form, and says nothing #169

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

Pushed.

shipped production is serving it deploy 97ab7b8

opened this

Pushed.

A local forge with FORGE_URL already 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 one warn line 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 passes ctx.app.log; the refusal itself, the response body, and the check's logic are unchanged.
  • README's "Run it" says what to do when FORGE_URL is already set: env -u FORGE_URL bun run src/main.ts, or point it at wherever you'll actually browse.
  • docs/APPS.md adds a sentence beside the FORGE_URL row: it's for the app to call the forge back on, not for running the forge software itself.
  • test/web.test.ts adds a suite that signs up over /signup with a mismatched, matching, and missing Origin, 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 Host trust, no loosening), and the response body stays the bare "forbidden" string it always was — only the log gained detail.

bun test and bun x tsc --noEmit are 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 unmodified main.

Closes #167

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs