Целесообразно ли регистрировать пользователей сайта как PostgreSQL-пользователей?

Question

[Тарас Лабяк]

Собственно есть идея реализовать всю логику сайта в PostgreSQL. Вопрос, собственно, какие проблемы могут возникнуть, если я буду регистрировать пользователей сайта, как пользователей PostgreSQL. Т.е., грубо говоря, вместо создания собственной таблицы user, использовать pg_authid . Возможно и может ли быть целесообразно ли это?
Среди очевидных проблем, с которым я столкнусь - необходимось поддержывать отдельное подключения к PostgreSQL для каждого пользователя

Answer 1

[Saboteur]

Совершенно противоестественная идея.
Пользователи не умеют правильно пользоваться приложением. Не умеют придумывать сложные пароли. Не умеют вообще следить за паролями. Если вы будете раздавать sql доступ к базе, ее обязательно поломают. Сломают других пользователей и так далее. А средствами sql базы безопасность поддерживать можно очень ограниченно.

Comments

[Тарас Лабяк]

Откуда ви взяли что можно что-то сломать и что под капотом какой-то другой пользователь и пароль?

[Saboteur]

Тарас Лабяк: То, что если у вас есть база, и определенные сформированные запросы к этой базе от пользователей - это одно. Если запрос вернет информацию для этого пользователя - окей.

Другое дело, если пользователь сам будет делать запросы к базе. Для начала можно сделать просто кучу джойнов и просто положить базу сложным запросом. Во-вторых можно получить любые данные, к которым есть read у пользователя, а таких данных в любом случае будет больше, чем если ограничивать их отдельным запросом. Я например не знаю, как средствами sql ограничить доступ пользователя к отдельным элементам таблицы - только к таблице целиком.

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

[Тарас Лабяк]

Сергей: средствами правил в постресе можно ограничить как угодно. Насчет тежелих запросов - и вправду не подумал

[Тарас Лабяк]

Сергей: хотя я предполагал что пользователь может визивать только процедури

[Saboteur]

Пользователь SQL может формировать любые запросы к SQL. То, что вы можете правилами ограничивать - это вы изобретаете велосипед. Придется делать кучу различных ограничений, вместо того, чтобы просто сформировать конкретные разрешенные запросы, и ВСЕ.

Answer 2

[Кирилл]

Среди очевидных проблем, с которым я столкнусь - необходимось поддержывать отдельное подключения к PostgreSQL для каждого пользователя

Даже этого "очевидно" должно хватить чтоб "закопать идею", 1 коннект - 1 процесс и даже если оно не так, сама идея пускать каких-то там пользователей со стороны в СУБД вам не кажется, мягко скажем, странной ?

Comments

[Тарас Лабяк]

В случае если это платный сервис и подлючаться можно будет к базе, допустим не только с PHP но и с удаленного андроид-приложения идея мне не кажеться такою уж странной. Собственно хочу реализовать все в постгрес. Производная идея - отдельное подключения для каждой группы пользователей со своими правами.

[Кирилл]

Тарас Лабяк: 1. Я у вас зарегистрируюсь, посмотрю куда трафик с моего андроид-апп бегает, с логином паролем подключуь и расчекрыжу там все к чертям. 2. 1 коннект - 1 процесс, т.е., если уж проще сказать, 500 пользователей "разорвут" вам любой сервер

Answer 3

[Сергей Протько]

есть такая директива в постгресе как max_connections, и это не спроста.

В целом никогда так не делайте. Между базой и внешним миром должна быть прослойка. Организуйте систему пользователей как-то иначе.

Comments

[Тарас Лабяк]

Одновременних пользователей будет меньше 100

[Сергей Протько]

Тарас Лабяк: как минимум поддерживать вашу систему будет адом. Не вам так тем кто будет после вас. А так решайте сами.

[Сергей Протько]

Тарас Лабяк: ну и да, 100 коннекшенов это много.

Answer 4

[Андрей]

Нет, нет и еще раз нет!

Для обслуживания прав доступа пользователей давно придуманы библиотеки авторизации, в частности они принимают решение, будет ли скрипт вообще иметь право доступа к базе в каждом конкретном случае.

Так и только так.