Права в Oracle

← →
Andrushk (2003-08-14 10:52) [0]

Господа, подскажите как лучше сделать.

Куча пользователей работают с одним приложением, но скажем, для примера, если есть табличка с городами, то кто-то может видеть только города Нижегородской обл, кто-то Владимирской, кто-то все.

Я хочу сделать так: на таблички просмотр которых надо ограничить навесить политик, а в предикатной функции лезть в табличку структурой [ID пользователя|ID права] и если у данного пользователя нет необходимых прав, то функция будет возвращать что-то типа 1=2.

Может есть какие-то другие способы решения данной проблемы???

Если кто знает статьи по данной тематике - скинте плиз, буду крайне признателен :-)

← →
Reindeer Moss Eater (2003-08-14 10:59) [1]

Решения всего два.
Ограничивать сервером и ограничивать приложением.
Есть еще правда третий способ - административный. Запретить инструкцией смотреть на то, на что нельзя смотреть.

← →
Unknown (2003-08-14 11:05) [2]

1. Сделать для каждого узера view
2. Пользователь имеет толбко право execute на пакетную
процедуру где реализованнп вся логика
3. Средства Оракле + твой Application Server

← →
Sergey13 (2003-08-14 11:10) [3]

2Andrushk (14.08.03 10:52)
>Я хочу сделать так: на таблички просмотр которых надо ограничить навесить политик, а в предикатной функции лезть в табличку структурой [ID пользователя|ID права] и если у данного пользователя нет необходимых прав, то функция будет возвращать что-то типа 1=2.

Это сейчас модно. Но что то стали попадаться вопросы в форумах, что мол непредсказуемо меняются планы выполнения запросов и как с этим бороться. В примерах из литературы рассматриваются только простенькие запросы, типа select * from emp. В жизни бывают и посложнее. И "автоматическая" модификация текста такого запроса, ИМХО, не всегда оптимальна.
В общем, я этим не баловался, поэтому советовать/не советовать не могу.

Я бы посоветовал сочетание ролей на сервере и ограничений в приложении. Например про города - наверное у них есть признак какой то, по которому кому то надо/не надо их видеть. Если нет его в таблице, то можно и создать. А дальше, после анализа логина - выдавать только то что нужно. Я так делаю.

← →
DenK_vrtz (2003-08-14 11:16) [4]

сделать таблицу соотвествия для каджого юзера + Сделать фунцию с параметром, которая будет возврщать курсор

← →
Sergey13 (2003-08-14 11:17) [5]

← →
Sergey13 (2003-08-14 11:18) [6]

Сори за повтор.

← →
Andrushk (2003-08-14 11:29) [7]

Свой view для каждого пользователя решение на мой взгляд не самое удачное, получается что у каждого пользователя свое приложение, либо надо делать чтобы приложение автоматически выбирало вьюхи в зависимости от пользователей... а кроме того, на каждую вьюху придется писать триггера, чтобы с ней работали update, delete, insert

Функция возвращающая курсор...штука хорошая, но на сколько я себе это представляю, для операций update, delete, insert придется еще dataset специально вытаскивать

Ограничения на уровне приложения....не уверен что это правильная вещь, никто не мешает поставить пользователю какой-нить TOAD залезть под собой и нахирачить в базе чего не следует.

Может кто-то прокомментирует мою идею??? Может есть какие-то подводные камни??? Я пока ничего более удачного и гибкого не вижу.

← →
Sergey13 (2003-08-14 11:41) [8]

2Andrushk (14.08.03 11:29) [7]
>Ограничения на уровне приложения....не уверен что это правильная вещь, никто не мешает поставить пользователю какой-нить TOAD залезть под собой и нахирачить в базе чего не следует.

Ну если у тебя юзера жабами пользуются тогда конечно.

>Я пока ничего более удачного и гибкого не вижу.
Про гибкось не спорю, а вот про удачность....

← →
DenK_vrtz (2003-08-14 11:51) [9]

>Ограничения на уровне приложения....не уверен что это правильная вещь, никто не мешает поставить пользователю какой-нить TOAD залезть под собой и нахирачить в базе чего не следует

а если по sys"ом зайти то ваще все похерить мона

← →
Andrushk (2003-08-14 11:56) [10]

>Я пока ничего более удачного и гибкого не вижу.
Про гибкось не спорю, а вот про удачность....

Рассчитывать надо на самый плохой вариант :-))
А что с удачностью? Расскажи?

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

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

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

А если я сделаю политику на одну табличку, то я сразу ограничу видимость и для связанных таблиц.

Но что-то так все здорово выходит, что даже страшно, уж не забыл ли о чем-то.

← →
Andrushk (2003-08-14 11:57) [11]

2DenK_vrtz © (14.08.03 11:51) [9]
а если по sys"ом зайти то ваще все похерить мона

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

← →
Sergey13 (2003-08-14 12:00) [12]

2Andrushk (14.08.03 11:57) [11]
>А вот если у пользователя есть дофига прав и обуздывает его только твое приложение - то уже есть о чнм беспокоиться.
Убрать все права и дать только нужные. 8-)

← →
Andrushk (2003-08-14 12:07) [13]

2Sergey13 © (14.08.03 12:00) [12]
>А вот если у пользователя есть дофига прав и обуздывает его только твое приложение - то уже есть о чнм беспокоиться.
Убрать все права и дать только нужные. 8-)

Логично :-)
Но вот как всетаки лучше дать права не таблички, не на столбцы, а на записи

← →
DenK_vrtz (2003-08-14 12:07) [14]

>>Пользователю никто не даст такого пароля, это понимать надо.

А зачем тогда ему знать пароль на схему? Глупость это! Таблица паролей юзеров никак недолжна быть связана с паролем на схему или пароль д.б. прописать в проге (чтобы никто не догадался)

>>приложение не маленькое, а уж каждому пользователю свою >>табличку соответствия - это я вообще не представляю

зачем же каждому?! Одна таблица (юзер, что разрешено (в частности Id области))

>>Вьюхи...тоже не знаю, не понравилось мне триггера на вьюхи
>>писать

вьюха, для каждого пользователя может создаваться во время выполнения программы с нужным условием, а данные могут вставляться не через эту созданную вьюху, а через специально отведенную для этого дела вьюху(процедуру) или непосредственно в таблицу.

← →
Andrushk (2003-08-14 12:28) [15]

2DenK_vrtz © (14.08.03 12:07) [14]

>>приложение не маленькое, а уж каждому пользователю свою >>табличку соответствия - это я вообще не представляю
>зачем же каждому?! Одна таблица (юзер, что разрешено (в >частности Id области))

Ну да, я так и хочу.

>вьюха, для каждого пользователя может создаваться во время >выполнения программы с нужным условием, а данные могут >вставляться не через эту созданную вьюху, а через специально >отведенную для этого дела вьюху(процедуру) или непосредственно >в таблицу.

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

Вообще, я вчера написал небольшую программку, в которой данные в grid брались из одного дадтасета, а изменение, добавление удаление - были сделаны через процедуру - мне не очень понравилось, сложновато, такую схему дольше реализовывать. Кроме того, то что то ты добавил(удалил, изменил) надо в grid"е отобразить...я вот пока не нашел хорошего способа как это сделать...refresh датасета - это если канал хороший, кроме того курсор слетает с выбранной записи, а возвращать его на место (Locate-ом чтоли??? если канал узкий а данных много, это конкретно тормозит)

← →
Andrushk (2003-08-14 12:28) [16]

← →
Andrushk (2003-08-14 12:29) [17]

сорри за повтор :-)))

← →
Dick Gonsales (2003-08-15 02:07) [18]

Я в Sybase делал так.
Таблица 1 < данные ... id_город >
Таблица 2 < user ... id_город >, где user - его login user

Создавал view типа
select таблица1.* from таблица1, таблица2
where таблица1.id_город = таблица2.id_город
and таблица2.user = current user
with check option

где current user - функция Sybase возвращающая текущего user.
with check option - опция, что view можно редактировать.

Пользователям давал права на view и не давал на Таблицы

В Oracle насколько я помню можно пойти по этому пути

← →
Andrushk (2003-08-15 09:44) [19]

2 Dick Gonsales (15.08.03 02:07) [18]
По сути, я предлагаю сделать тоже самое, ведь сделав политику, я буду неявно добавлять к любому Select-у, inser"ту, delete"у в клаузу where условие возвращаемое предикатной функцией.

Но вьюхи это да, было прикольно переделать все на вьюхи а доступ к табличкам вообще забрать.

← →
Sergey13 (2003-08-15 10:57) [20]

2Andrushk (14.08.03 11:56) [10]
>А что с удачностью? Расскажи?

Да дело тут в том, что при реализации всего этого дела сервер сам будет переделывать твои запросы добавляя еще одно (или больше) условие.
Для запроса
select * from emp
выполняться будет например
select * from emp where name_user="Вася"
Но это разные запросы и план выполнения их возможно будет разным. Для таких простых запросов это не критично, а вот если у тебя запрос на пару страниц и над его настройкой и оптимизацией ты потел не один день? Его "автоматическая" модификация может серьезно осложнить жизнь в плане производительности.

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

← →
Andrushk (2003-08-15 14:14) [21]

2Sergey13 © (15.08.03 10:57) [20]

Да там даже хуже чего будет выполняться :-) (select из таблички пользователей и select из таблички с правами)

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

Вообще, сейчас на одной табличке у нас весит политика, в функции делается один select из таблицы с пользователями, работает зашибись, никаких тормозов.

← →
Andrushk (2003-08-19 14:00) [22]

Если кому интересно - я все сделал как и писал, т.е. через политику. Работает просто зашибись, select выполняется за то же время что и без политики (пока только три права и 130 пользователей), мне кажется, Oracle как-то хитрожопо с этими политиками работает, поэтому получется высокая производительность.

Права в Oracle Найти похожие ветки