feat(#194): 認可のセッションキー方式化に向けた DB スキーマ追加

[kuu13580]

概要

issue #194 の認可方式移行 (PR #210) の前段として、認可用テーブルを追加する。

やったこと

• users — 認可の主体。Cookie 発行時に匿名 user (firebase_uid IS NULL) を自動作成し、Firebase 認証時に firebase_uid を埋めて昇格させる
• sessions — Cookie に載る session_id と user_id の紐付け
• user_trip_access — (user_id, trip_id) 複合 PK の中間表。並列付与の race を INSERT ... ON CONFLICT DO NOTHING で idempotent 化する
• Alembic migration (20260726_0000_add_users_sessions_and_user_trip_access_tables.py)
• docs/db_schema.md を全面最新化（既存欠落テーブル Location, DeviceSubscription, SentNotification も含めて全体を追記）

設計上の意思決定

• users.email は保持しない: Firebase Auth 側に一元化してプライバシー面積を最小化。Firebase Admin SDK で必要時に firebase_uid から取得可能
• クラス名は UserSession、テーブル名は sessions: sqlalchemy.orm.Session との名前衝突を避けつつテーブル命名は業界慣習に沿う
• user_trip_access を複合 PK テーブルに: 単一 PK + UK ではなく (user_id, trip_id) の複合 PK にすることで、ON CONFLICT DO NOTHING の効きが自然になる

Test plan

• Alembic migration が実行できる（本 PR の CI で確認）
• pnpm dotenvx run -- sh -c 'cd server && uv run pytest' (既存テストを壊していないこと)

関連

• Issue: 認可システムを永続セッションキーに移行 #194
• 後段: PR feat(#194): 認可のセッションキー方式化とバックアップ用メール認証 (BE) #210 (認可ロジック実装、Firebase Auth 統合、旧 Cookie 移行ミドルウェア等)

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: e7a46858-2875-4080-964c-4472b0c2d668

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Visit the preview URL for this PR (updated for commit 35e67d5):

https://tabi-share-8ef6b--pr212-feature-issue194-ses-trwlrn0a.web.app

_{(expires Sat, 08 Aug 2026 02:40:45 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 9f2a87ede127df7673322845e34cf22c1372d720}

[koki-fore]

usersテーブルにもlast_seen_atがあり、用途が不明

[koki-fore]

(任意)このテーブルにカラムが増えることが予想されるのであればサロゲートキーを用意してもよさそう

[koki-fore]

コメント

[kuu13580]

@koki-fore レビューありがとうございます。以下の通り対応しました (fixup で 61a8abd に squash → force-push 済み、PR #210 側も rebase 済み):

#2 (users.last_seen_at, line 342): 削除しました。
現状 grant/link/middleware 等どこからも更新されておらず「使うつもりで置いた dead カラム」だった状態です。YAGNI と判断し、将来 GC ジョブを実装するタイミングで sessions.last_seen_at と合わせて必要なら再追加します (sessions 側は認可判定の起点になるため必要)。

#3 (UserTripAccess サロゲートキー, line 394): 「任意」でしたが対応しました。
理由:

• 将来 access 個別への参照 (監査ログ、招待経緯の記録等) が発生した時に FK が張りやすい
• 複合 PK のままだと後付けカラム/API での「どの access 行」の指定が (user_id, trip_id) の 2 値渡しになり煩雑
• 移行コスト自体は今 (未マージ) だと migration 1 行の変更だけで済むので、後で困る可能性を早めに潰す方が得

(user_id, trip_id) は UNIQUE 制約に降格 (uq_user_trip_access_user_id_trip_id)、INSERT ... ON CONFLICT (user_id, trip_id) DO NOTHING は unique constraint 経由でそのまま機能します。142 tests passed 確認済み。

#1 (Valkey 移行, line 342): issue #215 で追跡としてこの PR では対応しません。