|
|
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Допустим, я хочу создать базу где бизнес-логика будет лежать в ХФ. К базе будет идти соединение, например, из ноды или PHP. Я не хочу, чтобы подключившийся клиент мог работать с базой через SELECT, INSERT и т.д. Для этого я создал ХФ, где нужно все необходимое. Вот как это организовать? К примеру в PHP прописан запрос Код: sql 1. Я хочу, чтобы он не отрабатывал, а отрабатывала готовая функция, к примеру: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 14:33 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджиовсе необходимоеа цель? Серджио Код: sql 1. Я хочу, чтобы он не отрабатывалgrant/revoke ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 14:51 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Запрещаете пользователям работать непосредственно с таблицей. Даёте права на вызов функции + security defined. Владелец функции должен иметь права работать непосредственно с таблицей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 16:28 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
p2., я только начинаю изучать постгрес, поэтому если сморожу глупость - строго не судите. В общем основная и главная цель - разграничение прав доступа на стороне БД и как следствие из этого сама работа с базой. Вот к примеру, обращаться к одной и той же таблице можно из различных частей приложения. Где-то что-то можно пропустить и пиши пропало. Обычный человеческий фактор. От него никто не застрахован. А учитывая, что все унитазы ведут в океан, что все запросы приложения в конечном итоге попадают на сервер БД, вот я и подумал, почему бы и не организовать бизнес-логику на стороне базы данных. GeniyZ, вот просто вопрос. Я под правами суперпользователя создал БД, добавил туда таблиц и функций, которые работают с этими таблицами ( читают, обновляют и т.д. ). Далее я добавил пользователя, и урезал его в правах ( в таблицы не лезь, вот тебе функции и баста ). Вопрос, а будут ли эти функции работать с таблицами, ведь доступ к таблицам я же запретил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 17:44 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Если функции созданы с флагом security defined, то действия в ней описанные будут выполняться с правами её владкльца. Т.е. если у владельца есть права на добавление в таблицу, то функция сможет инсёртить. Вы правильно делаете, что бизнеслогику организуете в виде хранимок. Так намного надёжнее поддерживать целостность данных при сложной логике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 18:07 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
GeniyZ, ах сколько до этого пришлось говнокодить))) Да и сейчас проскальзывает) А если по теме, то получается вот что - предоставить доступ к только функциям, которые делают много чего с таблицами, и при этом урезать в правах на таблицы я не смогу. Вернее, может быть и смогу, но тогда функции у этого пользователя не заработают. Что из всего этого я вижу: все равно делать ХФ, запихивая в них бизнес-логику ( не всю, а ключевые моменты ), и при этом фильтровать приходящие данные на уровне приложения от SQL инъекции. Правильно, хотя бы, вижу перспективу? И да, есть ли PDO в ноде для постгреса? Видел pg, но при нажатии ctrl+f5 и вводе "pdo" ничего не нашел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 18:23 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджио, авторВернее, может быть и смогу, но тогда функции у этого пользователя не заработают. В связи с чем это не заработают??? У нас, например, только так и работает. У конечных пользователей права только на вьюхи и хф. Нечего им "сырые" данные, даже, видеть, не чтоб править. По поводу инъекций, — при реализации работы исключительно через функции, безопасность улучшается, так как параметры будут парсится не только клиентом(php), но и сервером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 18:39 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
GeniyZВ связи с чем это не заработают??? Я ж писал, что чайник в постгресе. Просто подумал, что если у пользователя нет доступа к таблицам, то и у функций его не должно быть, как у пользователя их использующего. ХЗ, почему так подумал. Тогда вообще получается супер: напрямую к таблицам доступа нет, только одни функции. И рад бы порушить базу, да нельзя - функционал не позволит. По поводу SQL-инъекций. То есть, если я укажу в функции тип текст, и передам его в запрос допустим через $1, то оно безопасно передастся? В смысле: если какой нибудь юзер напишет "bla bla bla'; DROP TABLE example_table;", то это не сработает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 18:58 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджио, авторесли какой нибудь юзер напишет "bla bla bla'; DROP TABLE example_table;", то это не сработает? Если вы эту переммую инсёртите в таблицу, — заинсёртится. Сли с ней сравниваете ,— будет сравниваться. Если вы это значение передадите в EXECUTE IMMEDIATE, — будет передано. Но вы это делаете сами на свой страх и риск. И то, одно делать формировать динамический запрос конкатенированием, и совсем другое дело, — по-взрослому, через USING. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 19:08 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджио, авторВернее, может быть и смогу, но тогда функции у этого пользователя не заработают. Убедитесь, что у функций указано SECURITY DEFINER. Что такое PDO, — понятия не имею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 19:16 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджио, 1. И что из вашего web приложения сессии ходят под реальным PG учетками, а не под общей? 2. Лучше пользователей вообще отделить от сервера средним слоем, а не костыли на ХП. 3. Странно все это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 19:22 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
1. Организация работы пользователей под реальными учётками СУБД возможна, желательна, труднореализуема при веб-приложении; очень труднореализуема) 2. Если использовать реальные учётки БД, то незачем лепить прослойку в виде app-сервера. Более того, намного надёжнее контроль прав возложить на СУБД. И легче и надёжнее; 3. Использовать хранимки,— это вовсе не костыли. Особенно если их использовать по назначению; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 20:26 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
GeniyZ, Современный CRUD делается на ОРМ-ах за полчаса. Наружу выставлен тонкий Web API JSON сервер передачи/приема данных и все. Далее тратим время на эргономику фронт энда, а не написание тонн ХП кода. Где-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 20:41 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Relic Hunter, Во многих случаях такой подход оправдан. Но когда логика сложная, производительность критична и хочется соблюсти целостность данных, — без ХП обойтись не получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 21:05 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
GeniyZНо когда логика сложная, производительность критична и хочется соблюсти целостность данных, — без ХП обойтись не получится.Ну дак Вы хоть название топика поменяйте. А то у меня CRUD и "сложная логика" ну никак не сочетаются у меня. Да и производительность тут не причем. CRUD через ХП ниразу не производительнее одиночный операторов, а скорее наоборот=) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 21:35 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Relic Hunter, смысл в следующем: имеется одна учетка с минимумом прав (нельзя смотреть таблицы, изменять их и тд), но есть допуск к ХФ, которые это могут. Что это значит? Случайным образом порушить таблицы будет невозможно (хотя это зависит от кривизны рук, как напишешь ХФ). Все будет выполняться через ХФ. Допуск к нативному удалению, модификации будет закрыт. Что это дает: даже при физическом допуске к файлу php ( к примеру ), ничего нельзя будет сделать с базой ( опять же как напишешь, и, конечно, если не знаешь логин и пароль суперпользователя ). ORM - просто прослойка, которая защищает вас от "случайного выстрела в ногу" и которая в конечном счете генерит INSERT'ы и прочее, и шлет их базе. То есть, если вы используете ORM и злоумышленник имеет доступ к вашим файлам приложения, это не дает вам абсолютно никакой защиты. Вот об чем речь. GeniyZ, спасибо за ликбез. А PDO - это расширение в php для подключения к БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 21:45 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
СерджиоТо есть, если вы используете ORM и злоумышленник имеет доступ к вашим файлам приложения, это не дает вам абсолютно никакой защиты. Вот об чем речь.Да, "никакой защиты". Как дальше жить? У меня на сервере лежит web.config с закриптованной строкой подключения. И раскриптовать ее ни у кого не получится. Ни названия учетки, ни пароль, ни имя хоста, куда идет подключение никому не известно, кроме меня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 21:58 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
JVF, ну а если предоставить физический доступ к файлам приложения, натворить дел с базой можно будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2016, 22:04 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджионатворить дел с базой можно будет?Функция как будет отличать дела от недел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2016, 01:32 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
СерджиоJVF, ну а если предоставить физический доступ к файлам приложения, натворить дел с базой можно будет?нет. сперва подключицца надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2016, 04:10 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
p2.Функция как будет отличать дела от недел? p2., если речь о ХФ и если я ничего не путаю, то там идет параметризованный запрос. JVFнет. сперва подключицца надо. то есть и расшифровать данные для подключения невозможно будет? А если к примеру я написал в твоих скриптах свой код, используя твою переменную подключения, а ты взял и запустил - прокатит нагадить в таблицах? а вообще чем-то напоминает Кощея Бессмертного - яйцо в утке, утка в зайце и погнали-поехали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2016, 22:19 |
|
||
|
Запретить пользователю CRUD, разрешить только ХФ, возможно ли это?
|
|||
|---|---|---|---|
|
#18+
Серджио, Была "сложная логика" и "производительность" - не прокатило. Очередь безопасности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2016, 23:14 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39232460&tid=1997250]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
187ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
79ms |
get tp. blocked users: |
2ms |
| others: | 226ms |
| total: | 542ms |

| 0 / 0 |
