Просмотр подключений пользователей в FB 2.1

[JenyaMoskalenko]

Всем добрый день!

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

Под SYSDBA можно просмотреть все подключения (MON$ATTACHMENTS), но если пользователь не SYSDBA он видит только свой коннект и не видит коннекты своего же пользователя с других машин (с одной и той же тоже не видит).

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

[WildSery]

Это такое лабораторное задание? Или реальная необходимость?
Прежде чем давать какие-то советы и посылать в нужные источники, хотелось бы узнать, с какой целью "не пущать".

[Kotъ-Begemotъ]

Всем добрый день!

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

Под SYSDBA можно просмотреть все подключения (MON$ATTACHMENTS), но если пользователь не SYSDBA он видит только свой коннект и не видит коннекты своего же пользователя с других машин (с одной и той же тоже не видит).

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

У меня это решено созданием собственной таблички пользователей в базе. Кроме проверки чтобы этот юзер не работал с другой машины можно запретить ему доступ, задать имя роли, с которой он автоматом будет логиниться к базе, даже не зная об этом, и так далее. В чём вопрос-то? Почему надо сделать именно средствами FB?

[Kotъ-Begemotъ]

Это такое лабораторное задание? Или реальная необходимость?
Прежде чем давать какие-то советы и посылать в нужные источники, хотелось бы узнать, с какой целью "не пущать".

Например с целью правильного подсчёта повремённой оплаты работы диспетчеров. У меня так.

[JenyaMoskalenko]

Это такое лабораторное задание? Или реальная необходимость?
Прежде чем давать какие-то советы и посылать в нужные источники, хотелось бы узнать, с какой целью "не пущать".

это реальная задача.
приложение работает.
необходимо добавить такую проверку по требованию руководства!

[JenyaMoskalenko]

Пользователи коннектятся с ролями....
А какими средствами это решать???

создавать свои таблицы не хочется(раз FB уже сделал это сам)
плюс это ещё и надо будет решать проблему отслеживания "умерших" транзакций!

[Kotъ-Begemotъ]

Пользователи коннектятся с ролями....
А какими средствами это решать???

Указанием ролей при коннекте )) Явным или неявным.

создавать свои таблицы не хочется(раз FB уже сделал это сам)
плюс это ещё и надо будет решать проблему отслеживания "умерших" транзакций!

Какая еще проблема "умершх" транзакций?!? А логику приложения внимательно посмотреть? А статьи про использование параметров транзакций почитать? Не создавать "длинных" пишущих транзакций?
Своя таблица пользователей поможет решить вопросы, которые ты, даже получив доступ к системной таблице юзеров (а из под "не SYSDBA" ты этого, как мне кажется, нифига не сделаешь) не решишь...

[JenyaMoskalenko]

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

хорошо....
кто будет записывать данные в эту таблицу???
а ещё более важный вопрос кто их будет от тудова удалять???!!!!

[WildSery]

Почитай про current_user / current_role и приложи к прочитанному про database triggers.

Например с целью правильного подсчёта повремённой оплаты работы диспетчеров. У меня так.

Т.е. если у Пети комп заглючил и он залогинился на компе Васи чтобы забить вип-заявку, оставив висеть свой копм, то он клиенту что должен сказать?

[Slavik]

Когда-то я тоже страдал такими вещами. Решил довольно просто.

Создал пустую табличку активных пользователей в базе специально для этой цели, в которой уникальным ключом прописал имя пользователя. Приложение после коннекта к базе стартует специальную "блокировочную" транзакцию и в контексте этой транзакции пытается вставить запись в табличку активных пользователей. Если вставка произошла успешно, то продолжаем работать как обычно. "Блокировочная" транзакция висит до конца работы приложения. Перед разрывом соединения "блокировочная" транзакция откатывается, и "освобождает" возможность подключения другим приложениям. При потере соединения она тоже должна автоматически откатиться. Второе приложение с тем же логином при попытке вставить запись в табличку активных пользователей нарвётся на конфликт блокировок и должно разорвать соединение с выдачей соответствующего сообщения пользователю.

Естественно, этот способ работает только, если все приложения соблюдают данный ритуал.

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

[WildSery]

"Блокировочная" транзакция висит до конца работы приложения.

Идейка - отстой, для нормальной БД. Если только это не делать в отдельной БД, состоящей только из этой таблицы.

Есть и другие варианты. Я вот так выкручивался.

[Kotъ-Begemotъ]

Т.е. если у Пети комп заглючил и он залогинился на компе Васи чтобы забить вип-заявку, оставив висеть свой копм, то он клиенту что должен сказать?

Для этого есть отдельные механизмы. Но два одинаковых юзера в системе работать не будут ни под каким соусом. Иначе потом такая ...опа будет при расчёте денюжек, что не дай Бог... А с глюками админ разбирается вполне успешно. Это его проблемы чтобы не глючило, или оперативно чинилось. Если комп сломался, диспетчер садится на резервный. Благо резервный всегда (за исключением часов пик по отдельно взятым датам) есть.

[JenyaMoskalenko]

Вся проблема в том что админ проги должен иметь возможность и отключать этот контроль для отдельных пользователй!

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

[WildSery]

Вся проблема в том....

Т.е. ты не понял ничего из обсуждённого здесь?
Тебе ясно парочку разных направлений показали, а ты по-новой нам проблему объяснять начинаешь. Скажи уж, чего не получилось-то, или чем варианты не устраивают.

[Kotъ-Begemotъ]

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

хорошо....
кто будет записывать данные в эту таблицу???
а ещё более важный вопрос кто их будет от тудова удалять???!!!!

Ничего удалять не надо. Есть в таблице Vasya Pupkin. Есть поле ISACTIV. Вася Пупкин ввёл логин-пароль, проверился коннект к базе. Есть соединение? Вася вошёл без указания роли, поэтому получил доступ PUBLIC который подразумевает доступ только к одной таблице юзеров. По таблице проверили поле ISACTIV если оно 1 то Вася уже работает в системе и получает отлуп. Если оно 0 туда пишется 1. Можешь усложнить, и для каждого юзера ввести поле максимального количества разрешённых коннектов. Проверили - доступ Васе разрешён, под этим именем никто не работает. Из этой же таблички считываем Васину роль, и переконнекчиваемся к базе уже с указанием роли (Вася о ролях вообще не в курсе, и не надо). В чём проблема? При выходе из программы поле ISACTIV обнуляется (или декрементируется). Всё. Как один из вариантов.

[kdv]

При выходе из программы поле ISACTIV обнуляется (или декрементируется). Всё. Как один из вариантов.

но если коннект оборвался - шатдаун сервера, умерло приложение, оборвался коннект - то ISACTIV остается в 1. Соответственно, Вася приконнектиться больше не может.

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

1. закрыть приложение на одном компе если такое же запущено с другого компа - практически нереально. Можно, с использованием events, но может работать абы как - т.е. исходное приложение или закроется, или нет.
2. если сетка имеет статические IP на компах, то можно в спец-таблице проверять назначенный IP из mon$attachments. Если не тот ip и пользователь, то досвидания.
3. для отдельной группы пользователей - игнорировать IP.

[Tonal]

Нормально с event-ами работает.
У нас в системе вся интерактивность (обновление отображений) на них построена)

Так что вышибать вполне получается.

[WildSery]

но если коннект оборвался - шатдаун сервера, умерло приложение, оборвался коннект - то ISACTIV остается в 1. Соответственно, Вася приконнектиться больше не может.

Именно такую проблему (для CS под Linux) я решил в той ссылке на sql.ru

[Attid]

Именно такую проблему (для CS под Linux) я решил в той ссылке на sql.ru

кста, а пиды разве не могут повторятся время от времени при активной жизни на сервере ?

[WildSery]

кста, а пиды разве не могут повторятся время от времени при активной жизни на сервере ?

Могут. Их не так уж и много, 32768, кажись.
Я этого не писал, но дополнительно контролировал ещё и IP-адрес, т.е. если такой PID жив, но не с того адреса, откуда был "старый", то тоже считался недействительным. Однако, после наблюдений, от контроля дополнительно IP отказались - коллизии не случалось ни разу.
Ведь надо помнить, что старый процесс должен "застрелиться", не убрав за собой, что происходит не так уж прямо каждый раз, да при этом ещё и PID чтобы совпал, и был выдан именно процессу классика, а не, скажем, миднайткоммандеру...