remix-v2-meta-sessions-review

Remix v2 のメタデータ、セッション、認証、CSRF のコードレビュー

Remix v2 のメタデータ／SEO、セッション、認証ゲート、CSRF のコードパスをレビューします。差分が次のいずれかに触れる場合、包括的な review-remix-v2 レビュアーによって読み込まれます。 meta／links エクスポート、root.tsx、セッション／Cookie モジュールの *.server.ts、session を読み書きするローダー／アクション、または <Form>／useFetcher によるミューテーション。

標準的なパターンについては、remix-v2-meta-sessions を参照してください。

クイックリファレンス

問題の種類	リファレンス
v1 のオブジェクト形式で meta を返す（破壊的変更）、OG の省略形、エフェクト内の document.title、<Meta />／<Links /> の不足、親のマージ	references/meta-v2-shape.md
httpOnly／secure の不足、ハードコードされたシークレット、単一文字列の secrets、先頭に追加せず置き換えるローテーション	references/cookie-security.md
コンポーネント内の認証チェック、ローダー内のログアウト、commitSession の不足、コミットなしの flash	references/auth-gates.md
CSRF を回避する手動の fetch POST、セッション Cookie 内のトークン、CSRF 保護なし、共有シークレット	references/csrf.md

最優先で検出して指摘する項目： v2 のコードベースにおける v1 の meta オブジェクト形式（return { title, description }）。型チェックは通りますが、実行時に無視され、ページにタイトルもメタタグも表示されません。すべての export const meta を Grep し、戻り値が { ではなく [ で始まることを確認してください。

レビューチェックリスト

• meta は MetaDescriptor[] を返す（配列は [ で始まる）。v1 のオブジェクト形式ではない
• OG／Twitter タグでは { property, content } を使う。v1 の省略形 { "og:title": "..." } ではない
• document.title = "..." や useEffect(() => { document.title = ... }) がない — メタデータは meta エクスポートで設定する
• root.tsx の <head> 内に <Meta /> と <Links /> が含まれている
• 親の値を使う子の meta は matches.flatMap((m) => m.meta ?? []) を使っている
• meta で data が null の場合を処理している（ローダーが実行されていない、または 404 で undefined を返している可能性がある）
• Cookie の設定に httpOnly: true と secure: process.env.NODE_ENV === "production" が指定されている
• secrets は process.env から読み込まれている（文字列のハードコードや、値を含む .env.example のコミットがない）
• secrets はローテーションに対応する配列になっている（新しい値を先頭に追加し、古い値も保持する）。単一の値ではない
• すべての session.set／session.unset／session.flash の後に、"Set-Cookie": await commitSession(session) を含むレスポンスがある
• 認証ゲートは requireUserId(request) を使って loader（または action）に配置されている。コンポーネントレベルのリダイレクトではない
• ログアウトは action（POST）であり、loader（GET）ではない
• CSRF 保護を使用している場合、ミューテーションを行うアクションで csrf.validate(request) を呼び出している
• CSRF トークンにはセッション Cookie ではなく、専用の createCookie("csrf", ...) を使用している
• ミューテーションには <Form>／useFetcher を使い、AuthenticityTokenInput がトークンを添付するようにしている（手動の fetch POST は使わない）

有効なパターン（指摘しないでください）

以下は正しい使い方です。問題として報告しないでください。

• sameSite: "lax" — 許容されるデフォルト値です。すべてのアプリで "strict" が必要なわけではありません。より厳格な設定が脅威モデル上必要な場合（例：CSRF 保護が他に存在しない場合）に限り、指摘してください。
• meta が [] を返す — ルートが意図的にメタ情報を出力しない場合（ルートのタグを継承する、または兄弟ルートに依存するなど）は正当です。
• links が [] を返す — ルート固有のスタイルシートやプリロードがない場合は正当です。
• session.flash(...) の次の行に commitSession(session) がある — 標準的な2行のフラッシュパターンです。行を分けるのは正しい使い方です。「コミット漏れ」として指摘しないでください。
• action（loader ではなく）での認証チェック — POST 専用ルート（例：ログアウト、削除）では正しい使い方です。ローダーは GET を制御し、アクションは変更操作を制御します。
• root.tsx の <head> にある、プレーンな JSX <meta> としての charset および viewport — v2 のマージなし動作で重複タグの警告が出るのを避けるため、meta エクスポートよりもこちらが推奨されます。
• secrets: [process.env.X!, process.env.X_OLD!] — 上部にフェイルファストガード（if (!process.env.X) throw）がある場合は、! による非 null アサーションを使用しても問題ありません。
• ローダー／アクション内の throw redirect(...) — Remix の標準的なパターンです。レスポンスをスローするのは意図的な動作です。
• （アクションだけでなく）ローダー内での commitSession の呼び出し — ローダーがフラッシュメッセージを読み取り、クリアする必要がある場合に必須です。

コンテキストに応じたルール

以下の問題は、特定のコンテキストに当てはまる場合に限り指摘してください。

問題	指摘するのは次の場合のみ
アクションでの CSRF 検証の欠如	アプリが remix-utils/csrf を保護手段として宣言している、またはアクションが公開されており（内部／VPN で保護されているものではなく）、Origin チェックもない
sameSite: "lax"	アプリにライブラリベースの CSRF 保護も Origin チェックもない場合 — "lax" が唯一の防御策となり、不十分です
secure フラグの欠如	Cookie 設定が本番環境のセッション／CSRF Cookie の場合（テスト用フィクスチャやコメントアウトされた例ではない）
meta が [] を返す	そのルートに固有のタグが必要であると文書化されている場合（例：公開ランディングページ）— 通常、空なのは意図的な継承です。デフォルトでは指摘しないでください
action にあり、loader にない認証チェック	ルートを GET でレンダリングできる場合（loader がある場合）— POST 専用ルートでは、action が正しい制御箇所です
action でのログアウトと <Form method="post"> の併用	指摘しないでください — これが標準的なパターンです
手動の fetch による POST	対象が内部の Remix アクションであり、ヘッダーを介して CSRF トークンが付加されていない場合
secrets: [singleValue]	アプリが本番環境にある、またはローテーションが必要になるほど長期間デプロイされている場合 — CRITICAL ではなく推奨事項として指摘してください

指摘を記述する前の必須ゲート

以下を順番に実行してください。これから報告する一連の指摘について、すべてのゲートを通過するまで、ユーザー向けの指摘を作成してはいけません。

1. 場所の根拠 — 合格： 各問題について、リポジトリ内のパスと、行の範囲または実際に読んだファイルからの短い逐語的な引用を記載します。差分だけ、または記憶に基づく主張は合格になりません。メタ情報、リンク、セッションに関する問題では、引用元のファイルは .ts／.tsx のルートモジュール、root.tsx、または *.server.ts でなければなりません。一般的な設定ファイルは不可です。

2. 免除対象の確認 — 合格： 各問題について、有効なパターン（指摘しない）の対象ではない理由を1行で説明できます。特に、sameSite: "lax"、空の meta／links 配列、および標準の flash ＋ commitSession の2行パターンについて、明示的に対象外であることを確認してください。

3. meta の形状確認 — 合格： meta に関する内容を指摘する前に、実際の関数本体を読み、何を返すか確認します。TypeScript の型定義によって、型付けが不適切な MetaFunction エイリアスに v1 のオブジェクトが適合しているように見える場合があります。確認事項は、返却式が [ で始まり、すべての要素がディスクリプターオブジェクトであることです。{ で始まる場合は v1 の形式なので、CRITICAL として指摘してください。[] の場合は有効です（指摘しないでください）。

4. プロトコル — 合格： このレビューについて、review-verification-protocol の提出前検証チェックリストを完了しています。

参照資料を読み込むタイミング

• export const meta または export const links、あるいは root.tsx をレビューするとき → meta-v2-shape.md
• createCookieSessionStorage、createCookie、または Cookie を設定する *.server.ts をレビューするとき → cookie-security.md
• session を読み書きする loader／action、または認証ヘルパーをレビューするとき → auth-gates.md
• フォーム、fetcher、または変更を伴うルートをレビューするとき → csrf.md

レビュー項目

1. すべての meta エクスポートが配列を返し、OG／Twitter タグがそれぞれ { property, content } になっていますか？
2. root.tsx の <head> 内に <Meta /> と <Links /> がありますか？
3. Cookie に httpOnly と secure: NODE_ENV === 'production' が設定され、環境変数由来の secrets がローテーションに備えて配列になっていますか？
4. セッションを変更するたびに、Set-Cookie: await commitSession(session) ヘッダーが設定されていますか？
5. 認証ゲートはコンポーネントではなく、例外をスローするヘルパーを使って loader／action で実施されていますか？
6. ログアウトは action（POST）になっており、変更を伴う action では CSRF を検証していますか（または脅威モデルを記載していますか）？

追加ドキュメント

• references/meta-v2-shape.md — v2 コードベースにおける v1 オブジェクト形式（重大な変更）、OG の省略記法、document.title のアンチパターン、root の基本構成、親からのマージ
• references/cookie-security.md — httpOnly／secure／sameSite、ハードコードされたシークレット、ローテーションの適切な運用
• references/auth-gates.md — loader レベルのゲート、ログアウトは action にすること、commit の対応付け、flash パターン
• references/csrf.md — remix-utils/csrf の接続、手動 fetch による回避、専用 Cookie、共有シークレットの適切な運用

指摘を提出する前に

必須ゲート（特にゲート3の meta の形状確認）を完了し、review-verification-protocol の提出前チェックを引き続き通過する問題のみ報告してください。