DEEP GUIDE 04
誰が何を見て動かせるか
認証、APIの権限確認、RLSを一件の操作で比べる。
このガイドで追う一件
顧客Aが顧客Bの口座番号や管理画面の URL を知っていた場合を考えます。リンクを隠すだけでは何が足りないか、境界ごとに確かめます。
コードを読む順番
以下は MiniBank v1.0.0 の確認先です。マイグレーションは順に適用されるため、関数の最終形を調べるときは後続の変更も確認してください。
- 1
呼び出した人を特定する
顧客向け API はアクセストークンから認証コンテキストを作ります。ログイン済みかどうかと、その口座を使えるかどうかは別の問いです。
確認するファイル
src/lib/auth/getAuthContext.ts - 2
自分の行だけを読む
bank_accounts の RLS は auth.uid() と顧客の所有関係を使い、他人の口座行を読めないようにします。
確認するファイル
supabase/migrations/20260819132836_bank_accounts_rls_and_privileges.sql - 3
管理者の入口を分ける
管理者向け API は管理者セッションを確認します。顧客用の認証があるだけでは、審査や凍結を実行できません。
確認するファイル
src/lib/security/requireAdminSession.ts - 4
実行直前の権限を守る
凍結などのデータベース関数は操作する管理者自身の行をロックし、待機中に権限が変わる競合を防ぎます。
確認するファイル
supabase/migrations/20260823100001_fix_admin_toctou_lock_own_operator_row.sql
失敗時・範囲外の確認
画面から管理者リンクを消しても、URLやAPIを直接呼ぶことはできます。権限不足を API とデータベース側で拒否し、内部情報をそのまま返さないことが必要です。
ここまでで説明できること
認証、認可、行単位の閲覧制限を別々の役割として説明できます。