iBase.ru Forum

Здравствуйте, товарищи ГУРУ!
Вопрос о ролях: у меня в БД 5 ролей - гость, регистратор, кассир, спец и админ.
При подключении к БД, как мне быть? Нужно же сразу указывать роль, если не ошибаюсь...
НО я же не знаю какой именно юзер (в смысле какая роль ему принадлежит) подключается.
Как мне определять соответствующие роли? Не будет же прога подключаться под SYSDBA, а
потом проверять роль юзера, и затем как бы переподключаться?

И смежный вопрос:
как поменять пароль SYSDBA через FIBServices, я пробовал, но ничего не получается...
Может у кого есть готовый примерчик?

Заранее СПАСИБО, всем кто откликнется!

AnryGTR писал(а):Здравствуйте, товарищи ГУРУ!
Вопрос о ролях: у меня в БД 5 ролей - гость, регистратор, кассир, спец и админ.
При подключении к БД, как мне быть? Нужно же сразу указывать роль, если не ошибаюсь...
НО я же не знаю какой именно юзер (в смысле какая роль ему принадлежит) подключается.

Как мне определять соответствующие роли? Не будет же прога подключаться под SYSDBA, а
потом проверять роль юзера, и затем как бы переподключаться?

1. В IB Expert'е в User Manager указываешь, какому пользователю какая роль будет доступна. G[rant] - разрешит роль, AO - Admin Option.
Конечно, пользователь может запросить авторизацию с, например, ролью админа, но если она для него недоступна, авторизация будет отвергнута.
2. У себя сделал так: при авторизации пользователь выбирает из списка роль (на русском языке). Затем она преобразуется в настоящее имя роли (системное) и используется при коннекте. Делается это элементарно через TStringsList:
Гость=Guest
Администратор=Admin и т.д.

Спасибо! Я так и хотел сделать, но просто думал может какое-то другое решение есть?

AnryGTR писал(а):Как мне определять соответствующие роли? Не будет же прога подключаться под SYSDBA, а
потом проверять роль юзера, и затем как бы переподключаться?

Я создал в базе представление (VIEW), которое показывает доступные роли только текущего пользователя (current_user никто пока не отменил). Отдал права на select из него PUBLIC'у. В приложении сразу после соединения с базой под логином пользователя из этого представления считываю первую доступную ему роль. Если таковая есть, то именно переподключаюсь уже с полученной ролью. Если доступных ролей нет, то коннект с базой не передёргиваю (например, для SYSDBA).

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

Кстати, коннектиться из приложения, используя SYSDBA, не стоит ни при каких обстоятельствах.

Dimitry Sibiryakov писал(а):Кстати, коннектиться из приложения, используя SYSDBA, не стоит ни при каких обстоятельствах.

Почему ни при каких?

Хотелось бы услышать от разработчиков FB, будет ли изменена концепция ролей? Например, чтобы не было необходимости явно указывать имя роли при подключении...

CyberMax писал(а):Хотелось бы услышать от разработчиков FB, будет ли изменена концепция ролей? Например, чтобы не было необходимости явно указывать имя роли при подключении...

Окстись, пользователю может их и десяток быть награнтовано. Именно концепция роли прописана в стандарте, так что меняться не будет. Возможно, появится дополнительный механизм типа user groups, с суммированием прав, это другое дело.

Slavik писал(а):

Dimitry Sibiryakov писал(а):Кстати, коннектиться из приложения, используя SYSDBA, не стоит ни при каких обстоятельствах.

Почему ни при каких?

Хотя бы потому что этот пароль надо где-то хранить в жестко заданном виде: либо "вшивать" в программму либо хранить во внешнем источнике. И то, и другое ведет к нарушению безопасности БД.

Merlin писал(а):Окстись, пользователю может их и десяток быть награнтовано.

Знаю.

Merlin писал(а):Именно концепция роли прописана в стандарте, так что меняться не будет. Возможно, появится дополнительный механизм типа user groups, с суммированием прав, это другое дело.

Вот именно это и имел ввиду: применение всех доступных ролей. В этом случае явное указание роли как раз и не требуется.

Dimitry Sibiryakov писал(а):Кстати, коннектиться из приложения, используя SYSDBA, не стоит ни при каких обстоятельствах.

Slavik писал(а):Почему ни при каких?

CyberMax писал(а):Хотя бы потому что этот пароль надо где-то хранить в жестко заданном виде: либо "вшивать" в программму либо хранить во внешнем источнике. И то, и другое ведет к нарушению безопасности БД.

Зачем хранить? Админ так же как и все остальные при входе его указывает.

Похоже имеется ввиду использование автоматического "служебного" коннекта. В общем я тоже против этого. Меня смутило "ни при каких обстоятельствах"!

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

Т.е. сначала разработчик по лени всем SYSDBA вставляет, а потом когда наступает момент, говорит - ой, а мне вот надо, а что-то не получается...

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

Slavik писал(а):Зачем хранить? Админ так же как и все остальные при входе его указывает.

Есть кадры, которые пишут клиентов, которые авторизуются под SYSDBA, а введенное имя пользователя и пароль используют для разграничения доступа собственными средствами. Вот про этот ну очень частный случай я и говорил.
P.S. В купленной нами базе по учету абонентов, все глобальные действия (типа операций с периодами - закрытие, создание) можно делать только под SYSDBA. В итоге администраторский пароль знают все, кому не лень .

Есть кадры, которые пишут клиентов, которые авторизуются под SYSDBA, а введенное имя пользователя и пароль используют для разграничения доступа собственными средствами. Вот про этот ну очень частный случай я и говорил.

ничего против такого варианта, только модифицированного, не имею.
Заводится юзер A, ему даются все нужные права, этот юзер используется вместо SYSDBA. Все.
Я ж говорю - разработчики в основном лентяи.

Dimitry Sibiryakov писал(а):Админ в моем понимании обычно является владельцем базы, так что его собственного логина более чем достаточно. Использовать SYSDBA - оверкил.

Работать с учётками пользователей в FB2 может только SYSDBA. Элементарная задача получения списка логинов для сопоставления его справочнику пользователей, хранящемуся в базе, вынуждает админа логиниться под SYSDBA.
Кстати, никак не могу понять, чем плох SYSDBA в качестве владельца базы? (за исключением случая, когда разные админы админят каждый только свои базы на одном сервере)