iBase.ru Forum

есть ли способы узнать список подключенных к фаирберду пользователей?

возникла необходимость распределять приходящие смс сообщения между текущими операторами поровну и показывать каждому свои. при логине оператора в таблицу ID, IP, OPERATOR_ID процедурой прописывается номер оператора в соответствующую его IP-адресу строчку. дисконекты же не обозначаются никак по причине невозможности 100% гарантировать правдивость (снятия клиентсовй программы, выключения по питанию и т.д.) смс сообщения ловит и вставляет в таблицу сервис который крутится на сервере и не хотелось бы его каким-либо образом вязать на клиентскую программу (например посылать броадкастовые запросы во все клиентские проги и ждать ответа "я живой"), но тем не менее прописывать ID оператора которому пришедший смс должен отобразится - надо. я придумал следущее решение. в таблицу связи IP-адреса и OPERATOR_ID добавляю поле LASTUPDATE и апдейчу его таймером с клиентской проги на now. в сервисе при приходе смс, увеличиваю значение специально заведенного генератора на единицу, беру его значение по модулю записей в таблице (количество рабочих мест вообще) и проверяю для этой записи поле LASTUPDATE и если разница между текущим временем и его (LASTUPDATE) значением меньше частоты обновления с клиентской программы, то вставляю пришедшее смс сообщение с вычисленным OPERATOR_ID в таблицу с смс сообщениями. если же больше - значит оператор ушел в "оффлайн" любым возможном способом и я продолжаю поиск "онлайнового" оператора вплоть до не нахождения ни одного (чего по идее не должно случаться) и добавления нового смс с OPERATOR_ID = -1 (будет видно всем). весь этот гемморой только по причине отсутствия, насколько мне известно, чего-то типа служебной таблицы где например находятся IP адреса подключенных (не дропнутых) на данный момент пользователей.

может есть более правильные, но простые в реализации методы?

есть ли способы узнать список подключенных к фаирберду пользователей?

конечно. IBX.IBDatabaseInfo.UserNames.

там логины судя по всему, а они у меня все под одним логином конектятся. существует внутренняя система имен. она и используется. это очень глупо?

это очень глупо?

для трехзвенки (если не под SYSDBA), то нормально.
для остальных случаев, опять же, если не под SYSDBA - то да, не фонтан.

kdv писал(а):

есть ли способы узнать список подключенных к фаирберду пользователей?

конечно. IBX.IBDatabaseInfo.UserNames.

при добавлении пользователя через

IBSecurityService.UserName := AUserName;
IBSecurityService.Password := APassword;
IBSecurityService.SQlRole := ASQLRole;
IBSecurityService.AddUser;

разве не должно делаться grant ASQLRole to AUserName после добавления? хочется и пользователя добавить и роль ему прописать.

не хочет выполняться если указана роль. ругается: Project *.exe raised exception class EIBInterBaseError with message 'unexpected item in service parameter block, expected isc_spb_sec_username'. Process stopped. Use Step or Run to continue.
а сорцов интербейса нету под рукой

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

НО при коннекте нового пользователя теперь надо для него эту роль указывать, иначе пользователь подключится по умолчанию (public), без тех прав, которые он МОГ БЫ иметь.

если у Вас в системе несколько уровней доступа, то наверное нужно делать в конечной базе специальную таблицу, где прописаны соответствия USERNAME - ROLE
и подсоединяться к базе в два захода:
1) узнать роль
2) присоединиться с известной уже ролью

Если меня сейчас "отцы" заматюкают и предложат лучший альтернативный вариант - я только обрадуюсь.

IBX
не выполнен. сказал же. ругается.

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

entryway писал(а): IBSecurityService.UserName := AUserName;
IBSecurityService.Password := APassword;
IBSecurityService.SQlRole := ASQLRole;
IBSecurityService.AddUser;

разве не должно делаться grant ASQLRole to AUserName после добавления? хочется и пользователя добавить и роль ему прописать.

Ну почему, почему, когда хорошо прооптимизируешь запрос, сервер не наливает автоматически кружку пива? Ведь это было бы так удобно...

Пользователь создаётся и хранится где? А права на объекты в базе (в том числе на роли) хранятся где? Когда ответишь на эти вопросы, ответь на мой - с какого перепугу вызов сервис-API для работы с одной базой должен лезть к какой-то другой и что-то там с ней делать?

эхх...
уговорили

прочитал тут случайно
Что нового в IB 7.5
Встроенная в базу поддержка пользователей (rdb$users)

это как раз то что я хотел, да?
удобно, черт возьми :)

www.ibase.ru/devinfo/ib75eua.htm

статья уже год как на сайте.
p.s. баг, упомянутый в статье, давно исправлен в 7.5.1.

kdv писал(а):

есть ли способы узнать список подключенных к фаирберду пользователей?

конечно. IBX.IBDatabaseInfo.UserNames.

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

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