Просмотр подключений пользователей в FB 2.1
Модератор: kdv
-
- Сообщения: 16
- Зарегистрирован: 12 май 2008, 17:05
Просмотр подключений пользователей в FB 2.1
Всем добрый день!
Вопрос такого плана.
Есть клиентское приложение надо проверить при входе не подключен ли пользователь с этим же именем, но с другой машины.
Под SYSDBA можно просмотреть все подключения (MON$ATTACHMENTS), но если пользователь не SYSDBA он видит только свой коннект и не видит коннекты своего же пользователя с других машин (с одной и той же тоже не видит).
Задача не стоит просмотреть кто ещё работает в базе, надо запретить приложению пускать пользователя если приложение уже запущено с другой машины этим же пользователем!
Вопрос такого плана.
Есть клиентское приложение надо проверить при входе не подключен ли пользователь с этим же именем, но с другой машины.
Под SYSDBA можно просмотреть все подключения (MON$ATTACHMENTS), но если пользователь не SYSDBA он видит только свой коннект и не видит коннекты своего же пользователя с других машин (с одной и той же тоже не видит).
Задача не стоит просмотреть кто ещё работает в базе, надо запретить приложению пускать пользователя если приложение уже запущено с другой машины этим же пользователем!
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Re: Просмот подключений пользователей в FB 2.1
У меня это решено созданием собственной таблички пользователей в базе. Кроме проверки чтобы этот юзер не работал с другой машины можно запретить ему доступ, задать имя роли, с которой он автоматом будет логиниться к базе, даже не зная об этом, и так далее. В чём вопрос-то? Почему надо сделать именно средствами FB?JenyaMoskalenko писал(а):Всем добрый день!
Вопрос такого плана.
Есть клиентское приложение надо проверить при входе не подключен ли пользователь с этим же именем, но с другой машины.
Под SYSDBA можно просмотреть все подключения (MON$ATTACHMENTS), но если пользователь не SYSDBA он видит только свой коннект и не видит коннекты своего же пользователя с других машин (с одной и той же тоже не видит).
Задача не стоит просмотреть кто ещё работает в базе, надо запретить приложению пускать пользователя если приложение уже запущено с другой машины этим же пользователем!
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
-
- Сообщения: 16
- Зарегистрирован: 12 май 2008, 17:05
-
- Сообщения: 16
- Зарегистрирован: 12 май 2008, 17:05
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Указанием ролей при коннекте )) Явным или неявным.JenyaMoskalenko писал(а):Пользователи коннектятся с ролями....
А какими средствами это решать???
Какая еще проблема "умершх" транзакций?!? А логику приложения внимательно посмотреть? А статьи про использование параметров транзакций почитать? Не создавать "длинных" пишущих транзакций?JenyaMoskalenko писал(а):создавать свои таблицы не хочется(раз FB уже сделал это сам)
плюс это ещё и надо будет решать проблему отслеживания "умерших" транзакций!
Своя таблица пользователей поможет решить вопросы, которые ты, даже получив доступ к системной таблице юзеров (а из под "не SYSDBA" ты этого, как мне кажется, нифига не сделаешь) не решишь...
-
- Сообщения: 16
- Зарегистрирован: 12 май 2008, 17:05
хорошо....Kotъ-Begemotъ писал(а): Своя таблица пользователей поможет решить вопросы, которые ты, даже получив доступ к системной таблице юзеров (а из под "не SYSDBA" ты этого, как мне кажется, нифига не сделаешь) не решишь...
кто будет записывать данные в эту таблицу???
а ещё более важный вопрос кто их будет от тудова удалять???!!!!
Почитай про current_user / current_role и приложи к прочитанному про database triggers.
Т.е. если у Пети комп заглючил и он залогинился на компе Васи чтобы забить вип-заявку, оставив висеть свой копм, то он клиенту что должен сказать?Kotъ-Begemotъ писал(а):Например с целью правильного подсчёта повремённой оплаты работы диспетчеров. У меня так.
Последний раз редактировалось WildSery 12 май 2008, 19:31, всего редактировалось 1 раз.
Когда-то я тоже страдал такими вещами. Решил довольно просто.
Создал пустую табличку активных пользователей в базе специально для этой цели, в которой уникальным ключом прописал имя пользователя. Приложение после коннекта к базе стартует специальную "блокировочную" транзакцию и в контексте этой транзакции пытается вставить запись в табличку активных пользователей. Если вставка произошла успешно, то продолжаем работать как обычно. "Блокировочная" транзакция висит до конца работы приложения. Перед разрывом соединения "блокировочная" транзакция откатывается, и "освобождает" возможность подключения другим приложениям. При потере соединения она тоже должна автоматически откатиться. Второе приложение с тем же логином при попытке вставить запись в табличку активных пользователей нарвётся на конфликт блокировок и должно разорвать соединение с выдачей соответствующего сообщения пользователю.
Естественно, этот способ работает только, если все приложения соблюдают данный ритуал.
Позже я донаворотил идею и продолжаю пользоваться ей в случаях, когда необходимо запретить параллельное выполнение каких-то процедур (не обязательно хранимых). Получились эдакие мьютексы.
Создал пустую табличку активных пользователей в базе специально для этой цели, в которой уникальным ключом прописал имя пользователя. Приложение после коннекта к базе стартует специальную "блокировочную" транзакцию и в контексте этой транзакции пытается вставить запись в табличку активных пользователей. Если вставка произошла успешно, то продолжаем работать как обычно. "Блокировочная" транзакция висит до конца работы приложения. Перед разрывом соединения "блокировочная" транзакция откатывается, и "освобождает" возможность подключения другим приложениям. При потере соединения она тоже должна автоматически откатиться. Второе приложение с тем же логином при попытке вставить запись в табличку активных пользователей нарвётся на конфликт блокировок и должно разорвать соединение с выдачей соответствующего сообщения пользователю.
Естественно, этот способ работает только, если все приложения соблюдают данный ритуал.
Позже я донаворотил идею и продолжаю пользоваться ей в случаях, когда необходимо запретить параллельное выполнение каких-то процедур (не обязательно хранимых). Получились эдакие мьютексы.
Идейка - отстой, для нормальной БД. Если только это не делать в отдельной БД, состоящей только из этой таблицы.Slavik писал(а):"Блокировочная" транзакция висит до конца работы приложения.
Есть и другие варианты. Я вот так выкручивался.
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Для этого есть отдельные механизмы. Но два одинаковых юзера в системе работать не будут ни под каким соусом. Иначе потом такая ...опа будет при расчёте денюжек, что не дай Бог... А с глюками админ разбирается вполне успешно. Это его проблемы чтобы не глючило, или оперативно чинилось. Если комп сломался, диспетчер садится на резервный. Благо резервный всегда (за исключением часов пик по отдельно взятым датам) есть.WildSery писал(а):Т.е. если у Пети комп заглючил и он залогинился на компе Васи чтобы забить вип-заявку, оставив висеть свой копм, то он клиенту что должен сказать?
-
- Сообщения: 16
- Зарегистрирован: 12 май 2008, 17:05
Вся проблема в том что админ проги должен иметь возможность и отключать этот контроль для отдельных пользователй!
типа одни пользователи могут коннектится сколько угодно раз с любой тачки....а другие если зашел на каком-то компе то будь добр там и работай....
если надо с другой машины то надо закрыть уже запущеную программу на другой машине!
типа одни пользователи могут коннектится сколько угодно раз с любой тачки....а другие если зашел на каком-то компе то будь добр там и работай....
если надо с другой машины то надо закрыть уже запущеную программу на другой машине!
-
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Ничего удалять не надо. Есть в таблице Vasya Pupkin. Есть поле ISACTIV. Вася Пупкин ввёл логин-пароль, проверился коннект к базе. Есть соединение? Вася вошёл без указания роли, поэтому получил доступ PUBLIC который подразумевает доступ только к одной таблице юзеров. По таблице проверили поле ISACTIV если оно 1 то Вася уже работает в системе и получает отлуп. Если оно 0 туда пишется 1. Можешь усложнить, и для каждого юзера ввести поле максимального количества разрешённых коннектов. Проверили - доступ Васе разрешён, под этим именем никто не работает. Из этой же таблички считываем Васину роль, и переконнекчиваемся к базе уже с указанием роли (Вася о ролях вообще не в курсе, и не надо). В чём проблема? При выходе из программы поле ISACTIV обнуляется (или декрементируется). Всё. Как один из вариантов.JenyaMoskalenko писал(а):хорошо....Kotъ-Begemotъ писал(а): Своя таблица пользователей поможет решить вопросы, которые ты, даже получив доступ к системной таблице юзеров (а из под "не SYSDBA" ты этого, как мне кажется, нифига не сделаешь) не решишь...
кто будет записывать данные в эту таблицу???
а ещё более важный вопрос кто их будет от тудова удалять???!!!!
но если коннект оборвался - шатдаун сервера, умерло приложение, оборвался коннект - то ISACTIV остается в 1. Соответственно, Вася приконнектиться больше не может.КБ писал(а):При выходе из программы поле ISACTIV обнуляется (или декрементируется). Всё. Как один из вариантов.
1. закрыть приложение на одном компе если такое же запущено с другого компа - практически нереально. Можно, с использованием events, но может работать абы как - т.е. исходное приложение или закроется, или нет.JM писал(а):типа одни пользователи могут коннектится сколько угодно раз с любой тачки....а другие если зашел на каком-то компе то будь добр там и работай....
если надо с другой машины то надо закрыть уже запущеную программу на другой машине!
2. если сетка имеет статические IP на компах, то можно в спец-таблице проверять назначенный IP из mon$attachments. Если не тот ip и пользователь, то досвидания.
3. для отдельной группы пользователей - игнорировать IP.
Последний раз редактировалось kdv 13 май 2008, 09:39, всего редактировалось 1 раз.
Могут. Их не так уж и много, 32768, кажись.Attid писал(а):кста, а пиды разве не могут повторятся время от времени при активной жизни на сервере ?
Я этого не писал, но дополнительно контролировал ещё и IP-адрес, т.е. если такой PID жив, но не с того адреса, откуда был "старый", то тоже считался недействительным. Однако, после наблюдений, от контроля дополнительно IP отказались - коллизии не случалось ни разу.
Ведь надо помнить, что старый процесс должен "застрелиться", не убрав за собой, что происходит не так уж прямо каждый раз, да при этом ещё и PID чтобы совпал, и был выдан именно процессу классика, а не, скажем, миднайткоммандеру...