認証の境界を1か所に決める (#472)

[kojira]

Fixes #472

境界の規則

/api/events/* の認証は routes/events.ts の use("*", requireAuth) だけが持つ。worker.ts で api.route("/events", eventRoutes) が /events への登録の1本目なので、後ろに並べた配下ルート（scoring・photos・chat …22本）は必ずこれを通る。配下のサブアプリは自前の requireAuth を持たない。

認証なしで通したい経路は api.route("/events", eventRoutes) より前に登録する（既存の公開画像・公開コメント一覧などと同じ形）。/api/events 以外の接頭辞（/api/me・/api/communities など）は、従来どおり各ルートファイルが自分の境界を持つ。

なぜ「二重」では済まなかったか

Hono のミドルウェアはパターン一致で積まれる。/api/events/* に use("*") を持つサブアプリを22本並べると、どのサブアプリのハンドラを叩いても、並べた全部の requireAuth が順に走る。最も後ろに並ぶ /api/events/:id/staff-invites では23回。requireAuth 1回につきセッションとユーザーで2クエリなので、1リクエストで D1 を46回引いていた。

	requireAuth の実行回数	D1 クエリ
GET /api/events/:id/staff-invites (最悪)	23 → 1	46 → 2
GET /api/events/:id/todos	16 → 1	32 → 2
GET /api/events/:id/bingo	14 → 1	28 → 2
GET /api/events・/api/me など	1 → 1	変化なし
認証必須448本の延べ実行回数	2893 → 448

ルート表の差分

app.routes を歩き、各ルートのパスを実際のルーター（app.router.match）に引かせて、そのハンドラに届くまでに通る requireAuth を数えた。読んだだけの推測ではなく、Hono 自身の解決結果。

• 登録ルート 533本、うち認証必須 448本、未認証で通る 85本
• 認証の有無は1本も変わらない（533本の AUTH/OPEN 分類が前後で完全一致）
• 変わったのは実行回数だけ。変更後は448本すべてが authN=1

変異テスト

test/auth-boundary.test.ts が本当に効くことを、共有ツリーとは別の使い捨てコピーで確認した。各変異はファイルの内容ハッシュで「当たったこと」と「戻ったこと」を検証している。

変異	ハッシュ (前→変異→復元)	結果
events.ts の use("*", requireAuth) を削除	9fa1bd4ea864→ffe7d6d3b50e→9fa1bd4ea864	落ちた（未認証の検査・events の検査）
境界の外に api.get("/leak") を追加	a0398b7ec7de→183fad3751dd→a0398b7ec7de	落ちた（未認証の検査）
worker.ts で scoringRoutes を eventRoutes より前へ	a0398b7ec7de→feee55fb7caa→a0398b7ec7de	落ちた（未認証の検査・events の検査）
eventBingo.ts で requireAuth を重ねる	2ddef3d0d160→114267aae568→2ddef3d0d160	落ちた（1回だけの検査・events の検査）

未認証で通る85本は表に列挙してあり、認証の要らない経路を足すときは表にも足さないと落ちる。逆に、認証必須のはずの経路を境界の外に生やしても落ちる。

検証

• pnpm -r typecheck 通過
• サーバー全件: 86ファイル 1150件 通過（11シャード）
• web 全件: 880件 通過
• 触ったファイルはすべて800行未満（最大 worker.ts 653行）

docs

docs/design.md §3.1 に「配下は自前の requireAuth を持たない」根拠と実測、テストが見張る範囲を追記。docs/staff-todo.md §6.1・docs/staff-roles.md §6.1 のコード片も実装後の姿に合わせた。

🤖 Generated with Claude Code

https://claude.ai/code/session_01SLkuubF8cHzSnnsv4fN9DA

[kojira]

レビューの2点に対応した（8c9dc7f）。

1. 表への追加は認可の変更である、と命令形で書いた。 前口上に「OPEN_ROUTES への追加は『この経路を未ログインに開く』という宣言として読み、認可の変更としてレビューすること」「テストを通すために足すのは禁止」を明記。事故で足せないよう EXPECTED_OPEN_COUNT（79）とも突き合わせるようにしたので、1行足すと必ず数も動き、差分に現れる。表そのものも用途ごとの塊（ログイン前・死活・cron・メール・公開の読み取り・SPA/フィード等）に並べ替えて、足すときにどの塊かを選ばせている。

2. 歩けない2つの形を塞いだ。 api.all("/x", h) のような ALL メソッドの終端ハンドラは、ワイルドカードでなければ代表パスを作れるので普通に歩く対象に入れた。これで requireEventRole の5本（broadcasts・todos・staffing・name-cards・timetable/editing）も検査対象になり、歩く数は 533 → 538。

ワイルドカードのパスは代表パスを作れず依然歩けないが、そこに入るのはミドルウェア登録で、ミドルウェアは終端ではないので穴にならない。穴になるのはワイルドカードに終端ハンドラを載せた場合だけなので、next を受け取るか（引数の数）で見分け、終端ハンドラが worker.ts:625 の ASSETS フォールバック1本だけであることを固定した。現状 arity=1 が1本、arity=2 が44本ときれいに割れている。

追加の変異（いずれも内容ハッシュで当たり／復元を検証、使い捨てコピーで実行）

変異	ハッシュ (前→変異→復元)	結果
api.all("/leak-all", h) を境界の外に追加	a0398b7ec7de→5e94184cd309→a0398b7ec7de	落ちた（未認証の検査）。旧実装では見えなかった
api.get("/leak-wild/*", h) を境界の外に追加	a0398b7ec7de→371c69811acc→a0398b7ec7de	落ちた（ワイルドカード終端の検査）。同上
表にだけ1行足して件数は据え置き	3eb7908830a5→c6fc8f5b6747→3eb7908830a5	落ちた（件数の検査）

既存の4つ（境界の削除・境界の外への新ルート・worker.ts の並び替え・重複の復活）も引き続き落ちることを再確認した。

検証

pnpm -r typecheck 通過。サーバー全件 86ファイル 1152件 通過（11シャード、auth-boundary は 5→7件）。web 全件 880件 通過。auth-boundary.test.ts は272行。

docs/staff-todo.md の801行は把握した（main でも801行）。このPRでは触らず、別issueに回す。