@marver-design/marver 0.10.2 → 0.11.1

package/CHANGELOG.md

@@ -2,6 +2,167 @@
 
 Notable changes to `@marver-design/marver`. Format follows [Keep a Changelog](https://keepachangelog.com); versions follow semver.
 
+## 0.11.1 - 2026-08-27
+
+### Fixed
+
+- **The password gate's cookie now gets `Secure` from the pinned origin too.** 0.11.0 fixed
+  this for the collaboration session cookie and missed the gate's own, which is set in a
+  different file and is the one most likely to be sitting behind a plain `proxy_pass` - it is
+  the door on every password-mode canvas. Same rule, same reason: `MARVER_PUBLIC_ORIGIN`
+  decides when it is set, and `X-Forwarded-Proto` is the fallback only when there is nothing
+  better. Set `MARVER_PUBLIC_ORIGIN=https://your-canvas.example.com` and the thirty-day gate
+  cookie is https-only regardless of what your proxy tells the process.
+
+  Canvases behind a proxy that does send `X-Forwarded-Proto` - Railway, Fly, Vercel, Caddy,
+  and nginx configured with `proxy_set_header` - were never affected.
+
+## 0.11.0 - 2026-08-27
+
+### Added
+
+- **Marver Sign In: a canvas can ask people who they are, instead of asking for a shared
+  password.** Set `MARVER_ID_ISSUER=https://id.marver.design` (plus `MARVER_PUBLIC_ORIGIN`
+  and `MARVER_DATA_DIR`) and the gate becomes an identity gate. People sign in once - with
+  Google, or a code emailed to them - and every canvas gated this way opens without another
+  password. Nobody types a canvas password, so there is none to leak, rotate, or forget, and
+  revoking one person revokes exactly them. This is the better default for a team, and the
+  one we run ourselves.
+
+  **Your guest list stays yours.** The identity service proves *who somebody is* and has no
+  say in *where they may go*: an address gets in if it already has an account on your canvas,
+  holds an unexpired invite, or is `MARVER_OWNER_EMAIL` on a canvas with no accounts yet.
+  That decision is made on your disk, and the identity service is never told the answer.
+  Somebody with a perfectly valid Marver account who is not on your list gets nothing.
+
+  **The sovereign path is unchanged and is not going anywhere.** `MARVER_PASSWORD` still
+  gates a canvas with accounts that live entirely in your `MARVER_DATA_DIR`, and a served
+  canvas with no `MARVER_ID_ISSUER` set makes no outbound request at all - nothing to depend
+  on, nothing to phone home to. (Stated precisely, because it is the kind of promise that
+  should be: `marver serve` is silent. `marver dev` still makes the one anonymous registry
+  request it always has, once a day, to notice a new version - `MARVER_NO_UPDATE_CHECK=1`
+  turns it off - and a workspace you have connected to a published canvas still syncs its
+  comments with that canvas.) The two are alternatives rather than layers: running both
+  would weaken your invite list to "an account OR whoever has the password", so the identity
+  gate replaces the password gate rather than sitting beside it.
+
+  How it works, for anyone who wants to check rather than trust: the canvas mints a
+  single-use nonce bound to the browser that started the sign-in, the tab visits the identity
+  service and comes back with a short-lived ES256 assertion in the URL fragment - the one
+  part of a link no server ever receives - and the canvas verifies it against published JWKS
+  before issuing its own ordinary session. The assertion's audience is the canvas's exact
+  origin, port included, so one minted for one canvas is inert at another. The verifying half
+  is dependency-free and lives in this repo (`src/server/marver-id.ts`), which is why
+  pointing a canvas at a different issuer is a configuration change rather than a fork.
+
+  `MARVER_PUBLIC_ORIGIN` is required and the canvas will not start without it, in
+  development too. The audience cannot be inferred safely: nginx's documented
+  `proxy_pass http://localhost:PORT` rewrites `Host` and adds no `X-Forwarded-*`, so a
+  request from the internet is indistinguishable from a local one - and a canvas that
+  guessed would hand its caller a `http://localhost` audience and a cookie with no Secure
+  flag.
+
+  Sign-in fails closed: if the identity service is unreachable, existing sessions keep
+  working and new ones are refused. Nothing falls back to open.
+
+  **Managing people from the repo needs `MARVER_CLI_TOKEN`.** `marver comments invite`,
+  `revoke` and `sync` authenticate the CLI with a password, and an identity account has none -
+  so set `MARVER_CLI_TOKEN` on the canvas to a *generated* secret of 32 characters or more
+  (`openssl rand -hex 24`) and pass the same value back:
+
+  ```
+  MARVER_CLI_TOKEN='<that same value>' marver comments connect https://canvas.example.com
+  ```
+
+  (`--token` works too, but a secret on the command line is visible to anything that can
+  list processes.)
+
+  It acts as whoever owns the canvas, so it does nothing until somebody has signed in and
+  claimed it. Generate it rather than choosing one: nothing rate-limits this credential and
+  nothing slows a guess down, so its entropy is the whole defence, and a length floor is the
+  only part of entropy a program can check. The canvas refuses to start on a value that is too
+  short, and on one containing characters an `Authorization` header cannot carry - hex rather
+  than base64, so that a canvas never boots holding a secret it would go on to reject.
+
+  `connect` trades that secret for an ordinary session and stores THAT in
+  `~/.marver/canvases/`, so neither the secret nor the session lands in your repo. **Rotate
+  `MARVER_CLI_TOKEN` to revoke it**: every session it minted stops working the moment the
+  variable changes, and sessions people hold in their browsers are untouched. That is the
+  lever rather than `comments revoke`, because the session acts as the owner and a canvas
+  refuses to remove its last owner.
+
+  It is an environment variable, and not a page that hands out tokens to whoever is signed in,
+  for a reason worth stating plainly: authored frames run same-origin in a canvas. That is
+  deliberate and documented, and it means frame JavaScript can read `mv_c` and ride the
+  viewer's session - so any browser-reachable way to mint a durable credential is a way for a
+  frame to mint one silently and carry it off, an owner's if an owner is the one looking. A
+  browser-approved device flow was built for exactly this job and pulled before release for
+  exactly that reason; requiring a real top-level navigation narrowed it and did not close it,
+  because `Sec-Fetch-Site: same-origin` proves where a request came from and never that a
+  person meant it. An environment variable is on the other side of that line: it is never
+  sent to a page, and reaching it already means reaching the deployment.
+
+  The cost is honest. It is a static secret that rotates by redeploying, and it acts as the
+  owner rather than as a person, so it is an operator's credential and belongs with your other
+  deployment secrets. Per-member CLI credentials still want the frame isolation this release
+  does not have.
+
+### Changed
+
+- **The gate refuses to be framed** - every gate response now carries
+  `Content-Security-Policy: frame-ancestors 'none'` and `X-Frame-Options: DENY`. A
+  credential form inside somebody else's page, under a transparent button, is the classic
+  clickjack, and `SameSite=Lax` does not help because a framed page on the same site still
+  carries its cookies. Called out because it is a behaviour change rather than an addition:
+  if you were embedding a password-gated canvas in an iframe, that stops working. Embedding
+  a canvas people have already signed into is unaffected - it is the gate itself that
+  refuses.
+
+### Fixed
+
+- **`Secure` on the collaboration session cookie no longer depends on a header your proxy may
+  not send.** A canvas decided whether it was on https by reading `X-Forwarded-Proto`, and
+  nginx's own documented `proxy_pass http://localhost:PORT` sets no `X-Forwarded-*` at all. A
+  canvas served over https behind that configuration saw no header, concluded "not secure",
+  and issued a thirty-day session cookie the browser would happily send over plain http. Where
+  `MARVER_PUBLIC_ORIGIN` is set it now decides - a deliberate statement by whoever deployed
+  the canvas, rather than a guess about a proxy that may not be speaking. The header remains
+  the fallback only where there is nothing better, which is development on loopback.
+
+  This release fixed the collaboration session cookie only. The password gate's own cookie
+  still guessed from the header - see 0.11.1.
+
+- **The collaboration credential has moved out of your repository, because `marver dev` was
+  serving it.** It lived at `design/.local/collab.json`, and the dev server puts the repository
+  on the web so frames can import from it. Authored frames run same-origin, so any frame could
+  `fetch('/design/.local/collab.json')` and carry off a live session for your published canvas.
+
+  It now lives in `~/.marver/canvases/`, keyed by the project's path - one file per canvas per
+  machine, outside anything that is served. `connect` writes there, `dev` moves an older
+  credential out of the repo the first time it runs, and nothing needs doing by hand.
+
+  Guarding the old location was tried first and is the reason for the move: a deny rule matched
+  the path asked for rather than the file served, so a repository containing
+  `leak.json -> design/.local/collab.json` walked straight past it - and after that was fixed,
+  `public/` and Vite's derived `index.html` candidates each did the same. Enumerating a
+  bundler's resolution rules is not a thing anyone finishes. Those guards stayed as depth,
+  `design/.local` is still never served whatever route a request takes, and Vite's own default
+  deny list is no longer replaced by ours.
+
+  If you have ever run `marver dev` on a repository you did not write, treat that credential as
+  exposed: change `MARVER_CLI_TOKEN` on the canvas, which ends every session it minted, or on a
+  password-account canvas `marver comments revoke` and reconnect.
+
+- **A gated canvas is no longer publicly cacheable in identity mode.** The `Cache-Control`
+  decision keyed off the password verifier alone, so an identity-gated canvas marked its
+  assets `public, immutable` - an invitation for a shared CDN to serve somebody's private
+  frames to anybody who asked. Both modes are now `private, no-store`.
+
+- **A missing cosmetic file no longer falls through to the bundle.** Favicon and logo paths
+  are allowed past the gate on the promise that they are favicons and logos; when no such
+  file existed, the hash-routing fallback handed an unauthenticated caller `index.html`
+  instead. For those paths a miss is now a miss.
+
 ## 0.10.2 - 2026-08-24
 
 ### Fixed

package/README.md

@@ -28,6 +28,7 @@ Frames appear on the canvas the moment the files land. That's the loop.
 - **Everything hot-reloads.** The agent writes, you watch it land - live.
 - **True viewports.** Each frame is a real iframe: drag its edge and your actual breakpoints fire.
 - **Your agent answers on the canvas.** Tag `@marver` in a comment and it picks up the job, edits the real source, and replies in the thread - no wiring, on by default. See [Live Jam](#live-jam).
+- **Feedback without a signup wall.** Publish the canvas, invite people by email, and they sign in as themselves - one free Marver account, Google or an emailed code, and it opens every canvas you ever share with them. Or keep it entirely self-hosted behind a shared password. See [Collaboration](#collaboration).
 - **No AI inside.** The designer is the coding agent you already run and pay for. `init` generates the `design/AGENTS.md` contract that teaches it the whole workflow.
 
 ## The canvas
@@ -40,9 +41,21 @@ Frames appear on the canvas the moment the files land. That's the loop.
 
 ## Collaboration
 
-- **Comments.** Google-Docs-style feedback pinned to actual elements. Press `c`, click a div inside a frame, write - the thread lives on that element and survives edits via a layered anchor (source semantics → structure → fuzzy text). Viewers on a published canvas comment with real names and avatars (invite-link accounts, no email infrastructure). `marver dev` syncs the same threads into `design/comments/*.jsonl`, where your agent works the queue: `npx marver comments list --open --json` → fork a variant → `resolve --addressed-in`. Live via SSE; one deploy, no extra services.
+- **Comments.** Google-Docs-style feedback pinned to actual elements. Press `c`, click a div inside a frame, write - the thread lives on that element and survives edits via a layered anchor (source semantics → structure → fuzzy text). Viewers on a published canvas comment with real names and avatars - either a Marver account they already have, or an invite-link account on that canvas alone. `marver dev` syncs the same threads into `design/comments/*.jsonl`, where your agent works the queue: `npx marver comments list --open --json` → fork a variant → `resolve --addressed-in`. Live via SSE; one deploy, no extra services.
 - **Laser mode.** Press `l`: every element in every frame gets depth-hued outlines plus a hover label - the fastest way to see structure. Click any element to copy its full address (frame file + CSS path) for the agent.
-- **Publishing.** `npx marver build` exports a static canvas (default-closed: `design/publish.json` names what ships); `npx marver serve` hosts it with an optional password gate. One deploy on Railway, Docker, or any static host - the [publishing guide](docs/publish.md) has the one-pagers.
+- **Publishing.** `npx marver build` exports a static canvas (default-closed: `design/publish.json` names what ships, and whether each board is `read` or `comment`); `npx marver serve` hosts it. One deploy on Railway, Docker, or any static host - the [publishing guide](docs/publish.md) has the one-pagers.
+
+- **Two ways to let people in.** They are alternatives, not layers - pick one per canvas.
+
+  **Marver Sign In** (new in 0.11). Set `MARVER_ID_ISSUER=https://id.marver.design` and reviewers sign in as themselves, with Google or a six-digit code emailed to them. One free Marver account opens *every* canvas gated this way, so the second board you share costs them nothing: no new signup, no new password, no link to keep. You invite an email address and they are in.
+
+  That is the whole difference, and it is the difference between "I'll look later" and a comment actually landing on the board. It also means their real name and face ride along, so a thread is from a person rather than from an address.
+
+  **A shared password** (`MARVER_PASSWORD`). Fully self-hosted, no account anywhere but your own volume, nothing about your reviewers leaves your infrastructure - and still fully supported, not a legacy path. The trade is that every canvas is an island: reviewers claim an invite link and pick a name and password *on that canvas*, and do it again for the next one. Fine for one board, a toll on the fifth.
+
+  Either way the canvas runs on your infrastructure and stores its own comments and members. With Marver Sign In the identity service only ever tells your canvas that a verified address matched an entry on your invite list - it never sees your frames, your files, or your comments. Rights stay yours: `design/publish.json` decides which boards are readable and which are commentable, and `marver comments invite`/`revoke` decides who is on the list.
+
+  *Coming next:* one home for your account - every canvas you have been invited to, every canvas you have shared, and the access each one carries, in a single list. Today the account page at `id.marver.design` shows the canvases you have approved and lets you revoke them.
 
 ## Live Jam
 
@@ -61,7 +74,7 @@ The same glow, driven from the terminal. When your agent takes a request, it cre
 | `npx marver init` | Scaffold `design/` in this repo (safe to re-run; refreshes managed files) |
 | `npx marver dev` / `canvas` | Start the local canvas - hot reload, comments, Live Jam armed (`--port`, default 5199) |
 | `npx marver build` | Static export → `design/.dist`; what ships comes from `design/publish.json` (default-closed) |
-| `npx marver serve` | Serve the export; `MARVER_PASSWORD` gates it, `MARVER_DATA_DIR` persists comments + accounts |
+| `npx marver serve` | Serve the export; `MARVER_ID_ISSUER` or `MARVER_PASSWORD` gates it, `MARVER_DATA_DIR` persists comments + accounts |
 | `npx marver comments …` | The agent's queue: `connect <url>` · `sync` · `list` · `reply` · `resolve` · `invite <email>` · `revoke <email>` |
 | `npx marver work …` | Working glow from the terminal: `start <scene/frame …>` · `done … \| --all` · `list` |