編集用URLを閉じ、Cookie認証へ切り替えた話

今日は、Next.jsで作っている申込管理機能の「あとから編集する」導線を見直した。

最初の仕組みでは、申込ごとに発行したトークンをURLへ付け、そのURLを知っている人が入力内容を再編集できる形だった。実装は分かりやすいが、URLが履歴、画面共有、アクセスログなどへ残る可能性がある。期限や検証を入れていても、認証情報をURLで運び続けること自体が気になった。

そこで、初回アクセス時だけトークンを検証し、その後はHttpOnly Cookieの短時間セッションへ切り替える設計にした。ブラウザのJavaScriptから値を読めないようにし、旧URLのトークン経路は閉じた。画面側もURLを保持せず、Cookieを使う専用APIから下書きを取得・更新する。

もう一つ直したのが、更新処理の順番だった。本人確認、期限確認、現在の状態確認、保存を別々に行うと、その間に別の更新が入り、確認時と保存時の前提が変わることがある。今回は必要な条件確認と更新をデータベース側で一まとまりにし、条件が崩れた場合は保存しない形へ寄せた。

検証では、本番データを使わず隔離したデータベースで、正常な編集、期限切れ、無効なセッション、古い条件での更新拒否を確認した。さらにAPI単体テストで、旧URL経路から更新できないことも確かめた。

入力フォームは見た目が簡単でも、編集権限と更新の競合まで考えると設計範囲は広い。今回も、便利な再編集機能を残しながら、認証情報の置き場所と保存の境界を先に整理してよかった。

Next.jsやSupabaseを使った申込フォーム、会員機能、管理画面のご相談では、画面制作だけでなく、認証・権限・競合更新・テストまで含めて設計します。既存機能の安全な見直しも対応できます。