триггеры в базе, соответственно каждый пользователь имеет свой логин и пароль в базе. Это прекрасно работает с клиентскими приложениями которые подключаются к базе напрямую. Однако, если делать клиентские функции через рест, появляется вопрос, как выполнять запросы к базе от нужного пользователя. У меня пока в голове такой вариант - сделать какой-то словарь подключений к базе и брать оттуда нужное подключение и через него работать (чтобы не создавать новое подключение на каждый запрос пользователя и сохранить логирование действий). Может есть иные более интересные варианты?
В многопотоке это сделать сложно
1) Если БД поддерживает, изменять окружение сессии. 2) Задать контекст выполнения запроса. Те пусть работает от имени приложения, а пользователя рядом, в переменных окружения для запроса или сессии передавать.
Про первый пункт ни разу не слышал. Firebird умеет такое? Про второе - я планирую передавать во всех запросах jwt токен с пользователем и паролем, иметь небольшой менеджер подключений к бд, который будет хранить подключения (или создавать новые, если их нет/устарели) и выдавать нужное подключение для выполнения запросов.
Там все одно будешь потом тот или иной токен/ид сессии гонять. Для сервера надо логировать, в какой сессии выполняется запрос. Пул пользовательских сессий убьет масштабирование. Это у тебя расслоение просто получится, а не выделение сервера.
Я так понимаю речь идет в итоге об авторизации в базе. На лету нельзя указывать пользователя, который выполняет запрос. Нужно создавать подключение под нужным пользователем и уже этим подключением выполнять запрос.
я в том плане, что user возвращает строку логина, под которым создано текущее подключение
Oracle или MSSQL такое позволяют-выполнять запросы от имени другого пользователя. Но в общем и целом... Сервера и (микро)сервисы пишутся несколько иначе, чем клиент-сервер.
Это я все прекрасно понимаю. Однако, сейчас нет времени переделывать всю систему аудита и надо использовать бдшных пользователей
Переход на аудит не пользователей а сессий требует незначительных усилий. Много меньших, чем переписывание пула сессий. Просто оцени затраты и делай как выгоднее.
Может мы немного про разные вещи говорим? Что мы подразумеваем под аудитом сессии?
Обсуждают сегодня