どんな話？
第4話で閉じたのは「読む（SELECT）」の扉だけでした。扉は4つ（読む・足す・直す・消す）あり、ポリシーの USING と WITH CHECK は別の質問をしています。わざと事故を起こして開いていることを確かめ、第3話の練習用ポリシーを消し、INSERT・UPDATE・DELETE を auth.uid() = user_id で閉じ、もう一度事故を起こして 403 と 42501 で止まることを見ます。最後は Advisors に見てもらいます。
この記事でわかること
- 第4話で閉じたのは「読む」だけ。扉は4つ（SELECT 読む／INSERT 足す／UPDATE 直す／DELETE 消す）
- USING は「すでにある行に、さわっていいか」、WITH CHECK は「できあがる行が、それでいいか」。別の質問
- WITH CHECK の条件が true の INSERT は、中身を見ずに通す。他人の持ち物として書き込めてしまう
- 閉じたあと、もう一度わざと事故を起こして、403 と 42501 で止まることを確かめる
- 鍵なしで読んで0件なのは、エラーではない。返してよい行が1件も無かっただけ。エラーが出ないことは正しさの証明にならない
- 目視だけで判断しない。Advisors の Warnings から「RLS Policy Always True」が消えたかを見る
こんな人に
- 第4話で「読むほう」だけ閉じて、そのままになっている人
- AIに作らせたアプリを公開したいが、情報が漏れないか不安な人
- ポリシーを作ったのに、効いているのか確かめる方法を知らない人
この話のTIPS
- 注意SupabaseのRLSで「読む（SELECT）」だけ閉じても、足す・直す・消すの扉は開いたままです。WITH CHECK の条件が true の INSERT は中身を見ずに通すので、他人の持ち物として書き込めてしまいます。
- コツSupabaseで鍵なしで読んで0件なのは、エラーではありません。返してよい行が1件も無かっただけです。「エラーが出ない＝安全」ではないので、わざと事故を起こして 403 と 42501 で止まるか確かめ、Advisors にも見てもらう。