v1.0.0 の歴史資料当時の説明です。現在の仕様とは異なる箇所があります。現行版の対応記事 →資料一覧へ

DEEP GUIDE 04

誰が何を見て動かせるか

認証、APIの権限確認、RLSを一件の操作で比べる。

このガイドで追う一件

顧客Aが顧客Bの口座番号や管理画面の URL を知っていた場合を考えます。リンクを隠すだけでは何が足りないか、境界ごとに確かめます。

コードを読む順番

以下は MiniBank v1.0.0 の確認先です。マイグレーションは順に適用されるため、関数の最終形を調べるときは後続の変更も確認してください。

  1. 1

    呼び出した人を特定する

    顧客向け API はアクセストークンから認証コンテキストを作ります。ログイン済みかどうかと、その口座を使えるかどうかは別の問いです。

    確認するファイルsrc/lib/auth/getAuthContext.ts

  2. 2

    自分の行だけを読む

    bank_accounts の RLS は auth.uid() と顧客の所有関係を使い、他人の口座行を読めないようにします。

    確認するファイルsupabase/migrations/20260819132836_bank_accounts_rls_and_privileges.sql

  3. 3

    管理者の入口を分ける

    管理者向け API は管理者セッションを確認します。顧客用の認証があるだけでは、審査や凍結を実行できません。

    確認するファイルsrc/lib/security/requireAdminSession.ts

  4. 4

    実行直前の権限を守る

    凍結などのデータベース関数は操作する管理者自身の行をロックし、待機中に権限が変わる競合を防ぎます。

    確認するファイルsupabase/migrations/20260823100001_fix_admin_toctou_lock_own_operator_row.sql

失敗時・範囲外の確認

画面から管理者リンクを消しても、URLやAPIを直接呼ぶことはできます。権限不足を API とデータベース側で拒否し、内部情報をそのまま返さないことが必要です。

ここまでで説明できること

認証、認可、行単位の閲覧制限を別々の役割として説明できます。