Я привязываюсь, чтобы понять лучший способ использования функции безопасности на уровне строк в базе данных с несколькими арендаторами, которая поддерживает веб-приложение.
В настоящее время приложение имеет несколько разных ROLE, доступных в зависимости от действия, которое оно предпринимает.
Как только приложение создает соединение с помощью своего собственного ROLE, приложение передает параметры аутентификации (предоставляемые пользователем) в разные функции, которые отфильтровывают строки на основе параметров аутентификации, предоставленных пользователем. Система предназначена для работы с тысячами пользователей и, похоже, работает; однако он вызывающе неуклюжий (и медленный).
Похоже, что если бы я хотел использовать новую функцию безопасности на уровне строк, мне нужно было бы создать новый ROLE для каждого пользователя реального мира (а не только для веб-приложения) для доступа к базе данных.
Это правильно? и если да, то стоит ли создавать тысячи ROLE в базе данных?
Обновить из a_horse_with_no_name ссылку в комментариях (спасибо, этот поток включен):
CREATE USER application;
CREATE TABLE t1 (id int primary key, f1 text, app_user text);
INSERT INTO t1 VALUES(1,'a','bob');
INSERT INTO t1 VALUES(2,'b','alice');
ALTER TABLE t1 ENABLE ROW LEVEL SECURITY;
CREATE POLICY P ON t1 USING (app_user = current_setting('app_name.app_user'));
GRANT SELECT ON t1 TO application;
SET SESSION AUTHORIZATION application;
SET app_name.app_user = 'bob';
SELECT * FROM t1;
id | f1 | app_user
----+----+----------
1 | a | bob
(1 row)
SET app_name.app_user = 'alice';
SELECT * FROM t1;
id | f1 | app_user
----+----+----------
2 | b | alice
(1 row)
SET app_name.app_user = 'none';
SELECT * FROM t1;
id | f1 | app_user
----+----+----------
(0 rows)
Теперь меня смущает current_setting('app_name.app_user')
, поскольку я находился под впечатлением, что это было только для параметров конфигурации... где определено app_name
?