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

Я ведущий разработчик в коммерческом приложении Windows (c #). Новое требование – отслеживать клиентов, которые злоупотребляют лицензией.

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

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

У меня уже есть таблица User с столбцами: userid (первичный ключ), pw, lastLogin, lastLogout.

Я думал о создании новой таблицы «ведения журнала», в которую добавляется новая строка каждый раз, когда пользователь выходит из системы … столбцы могут включать:

LogId, UserId, LoginDateTime, LogoutDateTime

… и тогда у меня будет история каждый раз, когда пользователь входит в / из приложения …

но я не уверен, что этот дизайн таблицы предоставит эффективные вычисления для отчетности … Я использую SQL или c # для выполнения вычислений, для меня не имеет значения, если это достаточно быстро …

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

Примечание. Я не хочу блокировать пользователя 11t, 12-го и т.д. от использования приложения … Требование состоит в том, чтобы отображать предупреждение пользователю, но чтобы он продолжал работать …

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

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

Столбец «count count» теперь дает нам кусочно-непрерывную функцию со временем количества одновременных сеансов.

Пример данных:

SessionId EventType .... your session data here ... SessionCount 1. 1 Login ................ 1 2. 2 Login ................ 2 3. 3 Login ................ 3 4. 1 Logout ................ 2 5. 4 Login ................ 3 6. 4 Logout ................ 2 7. 2 Logout ................ 1 8. 3 Logout ................ 0 9. 5 Login ................ 1 10. 6 Login ................ 2 

О чем беспокоиться:

  1. Вы должны убедиться в том, что вы начинаете / заканчиваете события пары, поэтому в случае любого сбоя все события сеанса должны быть сгенерированы.
  2. Вам нужно, чтобы стол был защищен от несанкционированного доступа? Если это так, у меня есть техника для этого.

EDIT: обратите внимание, что там, где я помещал «ваши данные сеанса здесь», я действительно имел в виду «данные вашего сеансового события здесь». Информация, такая как отметка времени, войдет здесь. Другая таблица должна использоваться для отслеживания информации сеанса, общей для обоих событий, таких как идентификация пользователя, которому принадлежит сеанс (используйте один и тот же ключ SessionId для обеих таблиц).

Другой вариант – создать таблицу пользовательских сеансов. Когда пользователь входит в систему, вставьте свой сеанс в таблицу. Когда они выйдут из системы, удалите его. Таким образом, у вас всегда есть простой способ узнать, сколько пользователей подключено.

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

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

Я бы с осторожностью реализовал что-то вроде проверки лицензии таким образом, потому что (как уже было сказано в ответе Даниэля , вы не получаете выход из системы в случае сбоя приложения или, возможно, даже если пользователь закрывает его определенным образом (End Process from Диспетчер задач, ALT + F4, вместо перехода через File | Exit и т. Д.).

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

Я бы сказал, что разумная схема проверки лицензии требует централизованного доступа к серверу за пределами клиента, а для клиента – доступ в Интернет. Это может произойти примерно так:

  1. при запуске приложения программа информирует сервер лицензий о новом сеансе;
  2. во время работы приложения периодическая программа (скажем, 1x 5 минут или около того) отправляет сигнал статуса серверу лицензий;
  3. при выходе из программы, как правило, он посылает сигнал конца сеанса серверу лицензий;
  4. если сигнал статуса не получен в 10 минутах от программы, сеанс считается завершенным сервером лицензий в любом случае.

Примечание. Это проблема, с которой раньше сталкивались. Лучший вариант, который я видел, заключается в том, чтобы поддерживать стек пользовательской активности MRU для пользователей без разметки (в этом случае глубина 10) и выводится из транзакции базы данных – SELECT TOP 10 DISTINCT usercode FROM atable WHERE (последний тип транзакции wasn 't "log off") ORDER BY timestamp DESC. Как только кто-то обращается к системе, которая не входит в число последних 10, у вас есть два варианта. Вы разрешаете им входить в систему и ударять старейший статус для выхода из системы (что создает проблемы, но позволяет им продолжать работу); или вы заставляете их ждать, пока один из первых 10 явно не выйдет из системы. Иногда пользователь выбирает выбор. Иногда это требует администратора. Но это политическое различие.

Затем вы выставляете их за каждый раз при входе в систему (используя первую схему) или просто применяете лимит (со второй схемой).

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

Таким образом, вы можете отслеживать их использование. Зарядка их дополнительно или пересмотр их контракта становится значимым с реальными данными. Если вы хорошо разбираетесь в обслуживании клиентов, то это не должно сильно раздражать их перья, особенно если вы укажете, что вам нужна инфраструктура для предоставления услуг на выведенной базе пользователей. Предположительно, вы также ясно даете им понять о своей схеме лицензирования …

Проблема с наличием структуры таблиц (LogId, UserId, LoginDateTime, LogoutDateTime) заключается в том, что становится сложным агрегировать – запросы, чтобы все пользователи, использующие систему в указанное время, были просты, но получение количества пользователей в любое время затруднено ,

Одним из возможных подходов было бы денормализовать данные немного – и записать единицы использования, а не промежутки. Вы можете отслеживать использование в 30-минутных блоках со структурой таблицы (UserId, BlockDateTime).

Если BettyR использовал систему с 10:05 до 11:45, создайте четыре записи в своей таблице:

 BettyR, 10:00am BettyR, 10:30am BettyR, 11:00am BettyR, 11:30am 

Затем вы можете использовать обычный SQL-запрос с предложением group by, чтобы найти количество отдельных пользователей, которые использовали систему в течение каждого получасового периода.

 select ... from UsageBlocks group by BlockDateTime having count(*) > 10 

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