Управление пользователями FireBird

← →
MZ (2007-09-10 15:43) [0]

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

← →
Desdechado © (2007-09-10 15:58) [1]

Работать с таблицей RDB$USER_PRIVILEGES.
Читать документацию и ibase.ru

← →
kaif © (2007-09-10 16:38) [2]

Я пробовал разные варианты построения подобной логики.
Мне показался довольно удобным такой вариант.

1.Имеется таблица "функций" программы (F_ID, NAME).
2.Имеется таблица "привилегий юзеров на функции" (USER_NAME, F_ID).
3.Имеется таблица "привилегий функций на объекты базы" (F_ID, OBJECT_NAME, PRIVILEGE_KIND).

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

Как это все работает?
Допустим, юзер (или роль) имеет привилегии "видеть это окно". Добавляем в таблицу "функций" запись вида:
F_ID, NAME
---------------
1, "Видеть это окно"

Добавляем в таблицу "привилегий юзеров на функции"
запись вида
USER_NAME, F_ID
-------------------
"VASIA_PUPKIN", 1

Добавляем в таблицу "привилегии функции на объекты базы"
запись вида

F_ID, OBJECT_NAME, PRIVILEGE_KIND
--------------------------------------
1, "TABLE1", "S" (привилегия на чтение таблицы TABLE1)

А если функция называется "видеть форму и редактировать записи",
то:

F_ID, OBJECT_NAME, PRIVILEGE_KIND
--------------------------------------
1, "TABLE1", "S"
2, "TABLE1", "I"
3, "TABLE1", "U"
4, "TABLE1", "D"

(привилегии на чтение, вставку, изменение и удаление записей в таблице TABLE1)

Разумеется, после вставок в таблицу "привилегии юзера на функции" или удалений из нее следует посылать соотвествующие команды GRANT или REVOKE на объекты базы данных для этого юзера, отыскав имена таблиц и виды привилегий в таблице "привилегии функций на объекты базы" или редактировать таблицу RDB$USER_PRIVILEGES непосредственно.

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

Всегда проще администратору просто поставить птичку у надписи "Разрешить вводить заказы", чем расписывать птички у всех таблиц (ORDERS, CUSTOMERS, ITEMS и т.п), с которыми придется работать тому, кто получит привилегию "вводить заказы".
С другой стороны наличие привилегии у юзера на функцию "Разрешить вводить заказы" упрощает программисту принятие решения о том, чтобы дать возможность отобразить форму, в которой это будет происходить и нужные кнопки в этой форме сделать доступными, в зависимости от того, что это за была привилегия (только просмотр или привиления на ввод данных тоже).

← →
Petr V. Abramov © (2007-09-10 23:33) [3]

для Delphi - могу продать подобную библиотеку. Права на уровне, правда, не форм, а пунктов меню, но за ними четко и однозначно появляются права на объекты базы.
делали нас энто трое, и совсем не чайники (тута общепризнанные )были в команде.
правда, заточено под Oracle, но будет скидка.

← →
Turbouser © (2007-09-11 00:21) [4]

В [1] дан вполне исчерпывающий ответ.
Раздача прав из клиентского софта, как в [2] и [3]
требует весьма специфичного т.з.
Вообще, раздача прав "на лету" это моветон.
На этапе проектирования должны быть розданы соответствующие
привелегии соответствующим ролям (пользователям), если
надо что-то изменить - все вопросы к DBA.

← →
Petr V. Abramov © (2007-09-11 00:59) [5]

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

← →
Turbouser © (2007-09-11 02:14) [6]

> [5] Petr V. Abramov © (11.09.07 00:59)

Я не зря сказал о спецефичности т.з.

← →
Turbouser © (2007-09-11 02:32) [7]

> [5] Petr V. Abramov © (11.09.07 00:59)

К стати - даже в случае если от отдела продаж выписка счетов
перейдет к кому-то другому подразделению кто должен заниматься
перераспределением прав? Ответственный менеджер (гл.бух, еще кто-то)?
В любом случае - это обычный пользователь. Это чревато проблемами.
"Ой не ту кнопку нажал" и ты пы. Не говоря уже о безопасности...
DBA не повесится и не уволится, если софт грамотный.

← →
Sergey13 © (2007-09-11 09:05) [8]

> [7] Turbouser © (11.09.07 02:32)

1. Можно подумать DBA не может ""Ой не ту кнопку нажал" и ты пы".
2. У автора ЖарПтица, так что очень вероятно, что у заказчика DBA вообще нет, как класса.

> [0] MZ (10.09.07 15:43)

ИМХО, очень важно делать свою систему прав как надстройку к СУБД-шной системе прав доступа, а не писать ее заново. В любом случае последний рубеж должен остаться.

> свою систему прав как надстройку к СУБД-шной системе прав доступа, а не писать ее заново
золотые слова

> DBA не повесится и не уволится, если софт грамотный.
а вот грамотный софт и подразумевает, что роли определены уж никак не на этапе проектирования

О чем спор-то?

Раздать права всегда DBA может.
Но в системных таблицах интербейз вы не найдете таблицы RDB@FORM_PRIVILEGES. или RDB@MENU_PRIVILEGES

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

Если бы разработчики интербейз предусмотрели такую таблицу, то сейчас (я почему-то уверен) звучали бы мнения о том, что юзать эту таблицу и есть наивысший признак грамотности.
-------------------
Если пытаться ничего от себя не добавлять, то есть единственный выход - использовать роли в качестве функций и каждому юзеру присваивать роли при помощи тех же птичек. С точки зрения "не то нажал" при этом ничего мы не выиграем. Зато мы потеряем такую прекрасную вещь, как роль. Которую можно было бы приписать юзеру и он сразу получил бы все остальное. Если сделать, как я предлагаю, то под всем остальным подразумеваются привилегии на формы и пункты меню (то, что я назвал функциями) и вытекающие из них привилегии на объекты базы. Назовем привилегии на функции защиитой на уровне клиента, а привилегии на объекты базы - защитой на уровне сервера. Я предлагаю использовать обе защиты одновременно весьма незатейливым способом, просто добавив таблицу, увязывающую между собой функции программы и привилегии на объекты базы. При желании можно даже сделать триггеры для таблицы привилегий юзеров (и ролей) на функций, которые будут сами вставлять нужные записи в RDB$USER_PRIVILEGES в соотвествии с тем, как расписаны привилегии в таблице "привилегии функций на объекты базы".

Жесткое решение всегда возможно. Если возможно жесткое решение. Там все тривиально и говорить просто не о чем. Я же предложил (на мой взгляд) удобную реализацию гибкого решения, так как перепробовал много решений и у всех есть свои недостатки. Слишком непонятная система заканчивается всегда одним - сисадмин дает права на все кому-то одному "главному", а потом вся фирма бегает к этому "главному" и просит сделать элементарное. Это в лучшем случае. А в худшем - сисадмин дает права на все всем. И просто умывает руки. Пока гром не грянет - мужик не перекрестится.

Управление пользователями FireBird Найти похожие ветки