Вопрос о ролях...

[AnryGTR]

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

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

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

[CyberMax]

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

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

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

[AnryGTR]

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

[Slavik]

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

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

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

[Dimitry Sibiryakov]

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

[Slavik]

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

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

[CyberMax]

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

[Merlin]

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

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

[CyberMax]

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

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

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

[CyberMax]

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

Знаю.

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

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

[Slavik]

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

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

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

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

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

[kdv]

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

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

[Dimitry Sibiryakov]

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

[CyberMax]

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

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

[kdv]

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

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

[Slavik]

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

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