Google ログインの先に待ってたのは、proxy と secureCookie のコンボだった

個人向けでも、認証は雑にできない。daily-snap は Google OAuth で入って、許可リスト外は 403 みたいに閉じる。公開のドメインを切っても、中身は自分用の箱だ。JWT セッションに寄せたのは、Edge と DB セッションのトレードオフの話もあるが、個人開発だと運用の単純さもデカい。

CHANGELOG 上、この辺は細かいコミットが連なる。ざっくり手がかりを挙げると、ログイン UI に Google を載せる（6e493a6）、Auth.js 系の環境変数とセッション周りを整える（d1648ce）、認証ゲートを middleware から proxy.ts に移す（8b0fd31）、HTTPS / リバースプロキシ配下で getToken に secureCookie を渡す（ed1b289）。

ここ、地味にキツい。ローカルでは「動いた！」で終わるけど、本番は TLS 終端が前にいる。Cookie の Secure 判定がズレると、ログインできたのに API が 401、みたいな幽霊が出る。Dockerfile や entrypoint もセットで動くので、「コンテナ本番」とセットで見るのが早い。

症状と原因の早見表（Cookie / proxy 地獄）

| 症状 | まず疑う所 | | --- | --- | | ログイン画面は通るが、直後の API が 401 | JWT のデコード、secureCookie、Cookie の Secure / Path | | リロードするとログアウトする | セッションの保存先、同一サイト属性、サブドメイン差 | | 本番だけ CSRF っぽい挙動 | AUTH_TRUST_HOST 相当の設定、Origin ヘッダ、プロキシの X-Forwarded-* | | Edge と Node で挙動が違う | middleware と Route Handler の境界、トークン取得 API の違い |

環境変数の 実名と値はリポジトリの README / .env.example を正にする（このブログにキーを書かない）。変更したら ローカルとコンテナの両方でログイン→API の一本を通すのが早い。

この記事で言いたいのは、認証は機能じゃなくインフラに近い、ということ。SSE やオフラインと同じで、環境差分が殴ってくる。だから変更は小さく、ログは人間が読める形で、と自分に言い聞かせた。

許可リストは冷たいが、個人利用には効く

「公開 URL があるのに閉じる」のは矛盾に見えるかもしれない。でも自分のデータと生成ログを、想定外の第三者に触らせない、という意味では単純だ。実装の詳細はコード側に寄せるが、思想としてはここはブレない。

小さな結論

認証バグは機能バグより怖い。見え方が幽霊だからだ。だから変更は小さく、再現手順は短く。

次の自分へ

「ログインできるのに API が 401」は半分嬉しい。境界が特定しやすいからだ。Cookie の属性とパスとプロキシを疑う。

スクショで残すなら

ログイン画面、Google の同意画面（個人情報はマスク）、ログイン後のトップ、403 の許可リスト画面があればそれも。認証系は「状態が分かる画面」を優先。

コンテナと Cookie は相性確認が要る

localhost で育った実装は、ホスト名や HTTPS 終端が変わると挙動が変わる。Docker + リバースプロキシ環境では、同一サイト扱いや Cookie の Path が見落としがちだ。

この回のまとめは、認証は環境依存の塊だと思って触る。ログが綺麗でも Cookie がズレたら全部ウソになる。

次は、天気とカレンダーを **「思い出の手がかり」**としてどう配線したかに寄せる。

---

daily-snap 開発ログ
前: 画像は AVIF/WebP で…
次: Open-Meteo とカレンダーキャッシュで、今日を思い出しやすくする
索引: 04-02 · … 04-30