Комментарии 5
Эта запись не ограничивает доступ к данным никак, открывая их для всех пользователей, включая неавторизованных.
Я хз, что такое USING (true)
Но мне кажется, что это не задача БД проверять права доступа к данным.
Или типа там запрос вида
UPDATE
payments P
SET
P.status = 'Paid'
WHERE
P.id = %id с запроса%
?
Я хз, что такое
USING (true)
Это механизм, чтобы на уровне таблицы настроить политику доступа к строкам, что-бы `where p.id == %id` не писать, и потом не проверять по всему проекту кто забыл это where добавить.
Можно записать `USING (id = current_user_id)` и этот current_use_id вы устанавливаете для сессии работы с БД (как вариант). И далее вам не нужны никакие where, строки будут автоматически отфильтрованы.
Нужно это или нет, это вы уж сами решайте. Это просто фича Postgres.
Я так понимаю это не подходит к бэкенду который мультитенант и где тупо открыто 10 коннекшенов например в пуле с креденшиалс никак не связанных с юзером который дергает напирмер апишку? Сессия к базе открыта же и просто шарится между всеми через пул, и юзер который это делает не имеет юзера в базе, так что current user не имеет связи с ним.
Или я ошибаюсь?
В моем проекте как раз для мультитенант и используется. Про сессию это я просто для примера написал.
Как там сесии создаются и шарятся или нет - это на ваши заботы (ну или фреймворка которым вы пользуетесь). У меня в проете делается не особо оптимально, для каждого запроса в БД устанавливается значение параметра и в конце запроса сбрасывается.
А в целом, RLS - устанавливается для таблицы, потом если у вас переменная которую вы проверяете не установлена, запрос просто упадет.
И вы можете в любом месте SQL запроса установить переменную, а потом сбросить.
Например:
set current_user 1;
select * from users;
reset current_user; -- не помню reset или unset
Они просто в промпте «Напиши мне код для <......>» забыли дописать «...и чтобы без дырок в безопасности!»
Низкий порог входа, высокий риск — как уязвимость в Lovable открыла данные тысяч пользователей