Может ли пользователь читать чужие строки Supabase?
Может, если доступ разрешает политика, запрос выполняется с повышенными привилегиями или чужую строку возвращает другой слой приложения. Сначала подтвердите, что запись должна быть приватной. Затем сравните один и тот же ID через Data API и через проблемный экран.
Что подготовить
Пометьте тестовую строку Б уникальным вымышленным значением. Зафиксируйте таблицу или представление, проект, роль и ожидаемое правило: например, «видит только владелец, кроме явно приглашённых». Не копируйте ключи в тикет.
Порядок проверки
Изолируйте запрос пользователя
Под сессией А запросите id строки Б с публичным ключом. С теми же параметрами проверьте Б как владельца. Если Б видит строку, а А получает пустой массив, прямой SELECT для этой пары её не раскрыл.
Найдите путь, который раскрывает строку
Если интерфейс А всё равно показывает метку Б, проверьте ответ собственного backend, RPC, представления и кэш. Если метку отдаёт и прямой запрос, проверьте RLS именно на этой таблице, применимые SELECT-политики и членство А в организациях.
Шаблон наблюдения для таблицы notes: одинаковый ID, разные сессии
Б / Data API: 200, [{"id":"note-b","body":"Демо-Б"}]
А / Data API: 200, []
А / экран: видна «Демо-Б» → проверить ответ сервера и кэшКритерий результата и ограничения
Назовите конкретную границу, на которой появились данные. После исправления повторите оба пути и убедитесь, что приглашённый с законным доступом по-прежнему работает.
Что остаётся непроверенным
Пример предполагает запрос списка, а не .single(). Пустой массив без успешного контроля владельца не подтверждает защиту.