認証サブシステム(メール確認・CSRF・セッション)を実装する

背景

認証(Auth)系エンドポイント(後述の「対象エンドポイント」)は、ブラウザ向けの HTML 応答・リダイレクト・Cookie を伴うため、oRPC(パース済み JSON を前提とする契約)には適さず、通常の Nitro ルートとして実装する。

なお本人性の担保は2層に分かれる:

• traQ ID: NeoShowcase プロキシが付与する信頼済みヘッダ X-Forwarded-User から取得する。自前で認証を実装する必要はなく、ヘッダを Context に注入するだけでよい。
• メールアドレス確認セッション: isct メールアドレスの所有権を確認して確立する一時セッション(Cookie)。本 issue の実装の大半はこちら側にある。

対象エンドポイント(oRPC 契約対象外)

• POST /verify-email — 確認メール送信(202)
• GET /verify-email/confirm — 確認ページ表示(text/html)
• POST /verify-email/confirm — トークン消費・ログイン完了(303 リダイレクト + Set-Cookie)
• GET /csrf — CSRF トークン用 Cookie 発行(204)

やること

• traQ ID を X-Forwarded-User ヘッダから取得し Context に注入する(信頼済みプロキシ前提)
• メール送信基盤(isct メールアドレス宛)
• ワンタイムトークンの発行・検証・消費
• __Host-checkin_email_verified_session / __Host-checkin_csrf Cookie の発行と検証
• 状態を変更するリクエストの CSRF トークン(X-CSRF-Token)検証

スコープ外/関連

• 認可・レート制限は #15。
• traQ ID ↔ Stripe Customer のマッピング(DB)は #18。
• oRPC 契約には含めない(RPC に不向きなブラウザフローのため)。

Start by locating the Nitro route setup and the Context definition, then map the four listed endpoints and their browser-facing response requirements. Trace how trusted X-Forwarded-User data enters Context and determine the existing email, token, and cookie infrastructure before implementing the flow. Done means email verification, one-time token consumption, session and CSRF cookies, and X-CSRF-Token validation work for the specified endpoints.