Как проверить RLS в Supabase двумя пользователями
Проверьте политику от имени двух обычных пользователей через тот же API, что и приложение. Сначала каждый должен увидеть свою запись, затем не увидеть чужую. Отдельно попробуйте записать чужой owner_id: успешная защита чтения не проверяет запись.
Что подготовить
Создайте записи note-a и note-b в изолированном проекте, привяжите их к разным тестовым аккаунтам. Используйте публичный ключ проекта и соответствующую пользовательскую сессию. Не запускайте пользовательский тест в SQL Editor от имени администратора.
Порядок проверки
Проверьте видимость строк
Запросите note-a и note-b сессией А, затем повторите сессией Б. Сравните конкретные id и тестовые метки. Пустой ответ у обоих может означать, что истекли сессии, не выданы права или тестовые данные не созданы.
Проверьте ограничения новой версии строки
На отдельной тестовой записи попробуйте вставить owner_id Б от имени А, затем сменить владельца своей записи на Б. Зафиксируйте ошибку или число изменённых строк и перечитайте состояние. При разрешённой записи контрольная операция со своим owner_id должна пройти.
Локальный пример PostgreSQL: выполняется в отдельной тестовой БД и завершает транзакцию ROLLBACK
psql -X -v ON_ERROR_STOP=1 -d rls_test -f rls-fixture.sqlКритерий результата и ограничения
Сохраните результаты SELECT, INSERT и UPDATE раздельно. После изменения политик повторите матрицу теми же пользователями через клиент приложения.
Что остаётся непроверенным
Скачиваемый SQL моделирует пользователей локально. Он не проверяет ваш Supabase JWT, grants, Storage или реальные настройки Data API.