Запрет на повторный запуск программы под одним пользователем

← →
И. Павел © (2011-07-07 09:43) [0]

Здравствуйте.

Я написал программу, которая работает с БД MS SQL SERVER. Программа установлена на нескольких компьютерах. Пользователь вводит свой логин и пароль, хранящиеся в одной из таблиц БД. А связь с SQL SERVER проходит под общим пользователем (хотя, если MS SQL SERVER уже имеет готовое решение для запрета на повторную авторизацию, можно будет изменить этот механизм).

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

Первое, что приходит в голову: добавить в таблицу пользователей поле “used”, и, как только пользователь залогинится, присваивать этому полю значение true. А при завершении работы программы – сбрасывать значение поля в false. Если поле уже true, то повторный вход не осуществлять. Но тут есть 2 проблемы:

1. Два экземпляра программы могут одновременно убедиться в том, что у некоторого пользователя поле used = false и разрешить вход под одним и тем же пользователем. Думаю, что тут нужно что-то вроде synchronize. Есть ли такое в MS SQL SERVER?

2. Если программа будет завершена через ctrl+alt+delete, то поле used не будет сброшено в false и будет считаться, что пользователь используется кем-то и нельзя будет войти в программу под этим пользователем. По этому поводу придумал такой механизм: писать в поле user не булевые значения - а дату и время. Программа каждые 5 мин. пишет в поле used своего пользователя текущее время. Если при авторизации, в поле used оказалось время, отстающее от текущего на 10 мин., то считается, что программа, которая работала под этим пользователем раньше, уже завершилась. Но это тоже досвольно искусственный способ...

Подскажите, пожалуйста, как осуществить запрет на повторный вход в программу под уже используемым пользователем?

PS: разные экземпляры программы могут запускаться с разных машин. Все они объединены в локальную сеть.

Заранее спасибо!

← →
Медвежонок Пятачок © (2011-07-07 10:06) [1]

например виндовая регистрация на мсскл + политики не дающие войти юзеру васе не с васиного компа.
но останется проблема двух программ васи запущенных на васином компе.

← →
sniknik © (2011-07-07 10:09) [2]

> добавить в таблицу пользователей поле “used”
лучше поле "время отметки" и абдейтить его время от времени (раз в минуту например) из программы. ну и не давать войти если это время больше чем пять минут назад например...
использовать время сервера естественно.

← →
И. Павел © (2011-07-07 10:28) [3]

> [1] Медвежонок Пятачок © (07.07.11 10:06)

Спасибо. Как вариант я это предложу, но врят ли на это согласятся, т.к. число пользователей уже перевалило за 800, и как минимум путаница может возникнуть. Хотя было бы удобно. Тогда повторный запуск программ на одном компьютере можно бы было отслеживать спомощью мьютексов.

> [2] sniknik © (07.07.11 10:09)

Спасибо. Наверное, так и сделаю.

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

← →
Вариант (2011-07-07 10:35) [4]

К передложению

> Медвежонок Пятачок © (07.07.11 10:06) [1]
> например виндовая регистрация на мсскл

можно добавить вариант ->

SELECT COUNT(*) FROM sys.dm_exec_sessions WHERE is_user_process = 1 AND original_login_name = ORIGINAL_LOGIN()
- получаем число сеансов под логином входа

← →
Вариант (2011-07-07 10:45) [5]

> И. Павел © (07.07.11 10:28) [3]

> не может выполняться одновременно в нескольких параллельных
> потоках

Читаем о параллелизме,блокировках и уровнях изоляции транзакций в BOL.

← →
Вариант (2011-07-07 11:00) [6]

> Вариант (07.07.11 10:35) [4]

Кстати и не только для виндовой аутентификации. Если каждый пользователь имеет свой логин, то вполне можно использовать этот вариант, можно и триггер входа создать

← →
Anatoly Podgoretsky © (2011-07-07 11:23) [7]

Опасная вещь, проблемы с блокировками.

← →
Медвежонок Пятачок © (2011-07-07 11:41) [8]

т.к. число пользователей уже перевалило за 800

Итого у вас 800 виндовых аккаунтов, которые надо администрировать + 800 "программных" аккаунтов, которые надо тоже администрировать.

← →
Медвежонок Пятачок © (2011-07-07 11:45) [9]

Я бы вообще внимательнее посмотрел на саму проблему.
Надо ли запрещать сам запуск программ под одним аккаунтом?
Допустим один вася запустился под васей и работает.
Вдруг у него происходит затык.

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

Зачем запрещать именно запуск?
Может я просто хочу работать в режиме ридонли как вася?
В чем здесь криминал?

← →
b z (2011-07-07 11:46) [10]

А пользователи так и норовят зайти несколько раз? :)

← →
Anatoly Podgoretsky © (2011-07-07 11:48) [11]

> Медвежонок Пятачок (07.07.2011 11:41:08) [8]

Еще требуется 800 удавок

← →
SQLEXPRESS (2011-07-07 11:50) [12]

1. каждый под своим входим
2.
select distinct
program_name, hostname, loginame
from sys.sysprocesses

есть уже - свободен

← →
SQLEXPRESS (2011-07-07 11:53) [13]

> Медвежонок Пятачок © (07.07.11 11:45) [9]
> Я бы вообще внимательнее посмотрел на саму проблему.
> Надо ли запрещать сам запуск программ под одним аккаунтом?

+1

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

← →
И. Павел © (2011-07-07 12:05) [14]

Вариант, Anatoly Podgoretsky ©, Медвежонок Пятачок © , SQLEXPRESS
Спасибо. Задачу поставили люди из сектора поддержки пользователей. Думаю, действительно нужно объяснить им возможные проблемы - может быть, передумают.

← →
И. Павел © (2011-07-07 12:05) [15]

> Еще требуется 800 удавок

+10 для администраторов и 1 для программиста :)

← →
SQLEXPRESS (2011-07-07 12:17) [16]

> И. Павел © (07.07.11 12:05) [14]

задача скорее всего в разборе полетов? :)
Все воротят под одним юзером и потом концов не найти?
Если будут все входить под своим логином - будет легче.
Или делать join с sys.sysprocesses по program_name, hostname
да там и вообще много чего интересно лежит.
это если быстро и своими руками, иногда так делаю сам

А по-уму если, надолго и основательно - аудит надо проштудировать и настроить.

← →
SQLEXPRESS (2011-07-07 12:56) [17]

странно..вот так эту ветку вижу я..

SQLEXPRESS, SQLEXPRESS, И. Павел, И. Павел >|<

← →
И. Павел © (2011-07-08 11:03) [18]

Нашел отличную статью, описывающую различные способы блокировки в MS SQL SERVER: как с помощью стандартных средств, так и на пользовательском уровне. Статья написана максимально понятным языком, указываются достоинства и недостатки разных способов. Рекомендую всем, у кого возникнет похожий вопрос:

http://www.sql.ru/articles/mssql/Seminars/mssem21/SimultaneousEditing.zip

PS: Я пока не решил, какой метод выбрать. Склоняюсь к последнему: SPID + дата входа + отключение пула.

← →
DiamondShark © (2011-07-08 15:04) [19]

> Нашел отличную статью, описывающую различные способы блокировки
> в MS SQL SERVER

За select ... with (updlock) надо отрывать бэйцл.

← →
~ (2011-07-09 03:14) [20]

> Первое, что приходит в голову: добавить в таблицу пользователей
> поле “used”, и, как только пользователь залогинится, присваивать
> этому полю значение true.

Мх, а что произойдет, если поcле присвоения true упадет сеть и все клиенты поймают таймаут?

← →
И. Павел © (2011-07-11 09:43) [21]

> За select ... with (updlock) надо отрывать бэйцл.

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

> Мх, а что произойдет, если поcле присвоения true упадет
> сеть и все клиенты поймают таймаут?

Последний вариант в статье [18], основанный на SPID - это как раз решение этой проблемы.

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

← →
Дмитрий С © (2011-07-11 10:46) [22]

Каждый новый вход сбрасывает все старые - так не пойдет?

> И. Павел (11.07.2011 09:43:21) [21]

> похоже, SQL SERVER может запросто заблокировать всю таблицу с
> пользователями.

Да запросто

> Нужно, чтобы одни пользователи не могли выполнять в системе функции других
> пользователей

Это вообще к блокировкам не относится, это авторизация

> [22] Дмитрий С © (11.07.11 10:46)
> Каждый новый вход сбрасывает все старые - так не пойдет?

Думаю, что нет. Иначе выброшенный пользователь повторно запустит программу и выбросит остальных :)

> Это вообще к блокировкам не относится, это авторизация

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

В программе есть возможность разграничивать полномочия пользователей, скорее всего - просто нужно все правильно настроить, и конфликтов между пользователями не будет. Ну или связывать логин с IP.

← →
Smile (2011-07-11 11:11) [25]

> Сейчас некоторые сотрудники сидят под одним пользователем.
> В основном, видимо, проблемы из-за этого.

Так авторизуй их (раздели пользователей).

> И. Павел (11.07.2011 11:07:24) [24]

> Сейчас некоторые сотрудники сидят под одним пользователем. В основном,
> видимо, проблемы из-за этого.

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

> Вы чего, не понимаете, что творите.

> Так авторизуй их (раздели пользователей).

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

MS SQL SERVER поддерживает Windows Autentification

> [28] Anatoly Podgoretsky © (11.07.11 11:44)
> MS SQL SERVER поддерживает Windows Autentification

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

Сабж по определению тухлый ибо не имеет смысла, а след-но решения.
саппористы первыми ж и завоют от таких "ограничений", потому что
- во-первых, отпадет самый эффективный консалтинг с параллельным просмотром "васиного" и своего экранов (есно ты тоже должен зайти "васей")
-во-вторых, нет возможности зайти "васей" с двух компов для анализа некоторых проблем (например, связанных с тормозами)
-в-третьих, масса ситуевин когда "вася" разрешает на время зайти "под собой" "пете" чтобы тот помог ему сделать срочную работу.
-в-четвертых как не делай, а избежать "дедлоков" не получится - придется админу "разруливать" вручную. При 800 юзверях представляю как его будет рвать :)
-в-пятых, что-то мне подсказвает, что проблема возникла из-за отсутствия нормальной админрулежки. Раздавайте права ролям, а роли - юзверям. Это много гибче. Ну и, конечно, надо в самой базе предусмотреть дифправа. Использовать напимер, папки (разделы, каталоги и т.д.), что позволяет разделить права (и соотв-но границы потенциального вреда) как по людям, так и по долностям или подразделениям.

Терпеть ненавижу Парус, но там, ИМХО, это реализовано на вполне пристойном и надежном уровне.

ЗЫ. не следует подменять алгоритмами то, что обязано выполняться человеком (не имхо)

← →
~ (2011-07-11 22:38) [31]

Запрет на повторный запуск программы под одним пользователем Найти похожие ветки