> >Заводить по постгресному пользователю для каждого реального пользователя системы?

Question

> >Заводить по постгресному пользователю для каждого реального пользователя системы?

> а что в этом плохого?

Вот где-то в этом вопросе и есть ответы на остальные заданные вами вопросы.
В первую очередь, конечно, что фреймворки вроде Django используют собственные механизмы аутентификации, собственные таблицы/управление ими, а не системные.
(И одна причина этого — в том, что они сразу работают не только над PostgreSQL, но и другими базами).
Ну то есть: если этого нет в крупном фреймворке, ускоряющем задачу разработки всего приложения — то этим и не будут пользоваться. Ни к чему.

Но это и потому, что «аутентификация конечного пользователя» и «аутентификация в PostgreSQL» — это уж ну очень разные вещи. Аутентификация через Oauth2, через всякие аппаратные ключики вроде Yubikey, с учётом или без учёта 2FA (причём у каждого пользователя независимо 2FA может быть или может не быть). Повышение или понижение привилегий пользователю на основании бизнес-логики (что-то вроде того, что: «если в последние 10 минут он подтверждал своё 2FA – у него есть разрешения на выполнения переводов» (и что-то я не припомню крон-функциональности в апстриме постгреса); или: «если внешний сервис проверил его паспортные данные, то у него появляется новая роль kyc_passed и связанные с ней привилегии»).

Ну в целом это я сформулировал бы так. Потому что в реальных приложениях для аутентификации может не хватить встроенных механизмов, а набор ролей и разрешений может определяться программно и в зависимости от дополнительных критериев.

#backend #devops #pgsql #programming #russian

0

08.05.2020

1 ответов

14 просмотров

Владимир · Accepted Answer

Владимир

вас это не устраивает? https://www.postgresql.org/docs/current/auth-methods.html

0

08.05.2020

172 похожих чатов

> >Заводить по постгресному пользователю для каждого реального пользователя системы?

1 ответов

Похожие вопросы