Система входа в систему, позволяющая каждому пользователю одновременно входить в систему на одном компьютере.

Question

Как мне спроектировать систему входа в систему, чтобы каждое имя пользователя могло быть зарегистрировано только в одном месте одновременно? Я хочу, чтобы пользователи не давали свое имя кому-либо еще для входа в систему, чтобы они не платили за каждого пользователя.

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

Answer 1

У некоторых Мессенджеров (которые могут работать только с одной зарегистрированной конечной точкой) есть хороший способ разобраться в таких конфликтах. Они показывают сообщение, как

Вы уже вошли в систему с <COMPUTERNAME>

(в случае веб-приложения это будет <IP/Browser>)

и предоставит вам выбор между

• либо оставив этот вход в систему живым (а не входя в систему с компьютера, на котором вы работаете), либо
• Завершение существующего входа в систему (и входа в систему на текущем компьютере).

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

Answer 2

Типичным подходом к этой проблеме является использование

период ожидания неактивности.

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

Вот общие черты такой системы

• Каждая учетная запись связана с разрешенным количеством одновременных входов в систему (также называемых «местами») (кажется, что ОП желает один и только один для каждой учетной записи, но это может быть больше и варьироваться в зависимости от учетной записи). 1010 *
• Логика менеджера лицензий хранит список всех учетных записей / пользователей, которые в данный момент вошли в систему, вместе с отметкой времени с их «последним» действием.
• Перед обслуживанием любой страницы веб-приложение вызывает менеджер лицензий (LM). Цель состоит в том, чтобы позволить LM обновлять метку времени «последней» активности, а также отклонять вызов в случае получения лицензии (подробнее об этом ниже)
• После каждого входа логика менеджера лицензий проверяет, что количество занятых мест не превышает сумму, указанную для учетной записи.
• Если это не так, LM просто добавляет текущий сеанс в список активных сеансов
• Если это так, то LM проверяет сеансы в списке, которые старше, чем период ожидания. Если он найден, он отключает его и предоставляет доступ к новому логину. Если ничего не найдено, вход запрещен.
• при каждом [явном] выходе из системы LM удаляет соответствующий сеанс из списков активного сеанса.

Обратите внимание, что общий принцип, изложенный выше, может иметь некоторые вариации, в частности:

• вместо того, чтобы молча и систематически аннулировать [обычно самый старый] сеанс тайм-аута, можно проинформировать пользователя, пытающегося в данный момент войти в систему, об этой ситуации и позволить ему / ей решить необходимость «убить» такой сеанс.
• Во избежание обременения LM каждым и каждым новым запросом страницы, веб-приложение может отслеживать для каждого сеанса время, прошедшее с момента последнего «обновления» сеанса в LM, и вызывать LM только в случае время превышает, скажем, 1/3 периода ожидания.

Независимо от самой логики LM, не забудьте сохранить журнал всех событий, связанных с LM (входы в систему, выход из системы, неактивные сеансы "убивают", отказанные входы в систему ...). Такие журналы должны включать дату / время, IP-адрес и другую соответствующую информацию и полезны при решении проблем, связанных с украденными паролями и тому подобным. Такие журналы также содержат бесценный маркетинг, например, для поиска всех учетных записей, у которых, по-видимому, слишком мало мест (и, следовательно, может приобрести некоторое количество ugrade), или для поиска учетных записей, подверженных риску и т. Д.

Еще несколько соображений

• облегчает пользователям выход из системы (кнопка / ссылка выхода на большинстве страниц в фиксированном месте
• позволяет пользователям легко сообщать о конфликте / краже паролей

Answer 3

World of Warcraft от Blizzard Я считаю, что это прекрасно реализуется.

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

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

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

---

Есть также некоторые другие вещи, о которых вам, возможно, придется подумать. Такие вещи, как угон сеанса. Если пользователь просто помещает файл cookie в свою систему (что всегда возможно) с правильным идентификатором сеанса, возможно, он может использовать один и тот же сеанс на нескольких компьютерах. В этом случае вы, вероятно, захотите сохранить поле IP, в котором хранятся данные о том, кто в данный момент вошел в систему.

Answer 4

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

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

Answer 5

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

Answer 6

Я делал это раньше в веб-приложении, которое имело те же требования. Вот что я сделал:

Когда кто-то входит в систему, вы генерируете GUID и сохраняете его в своей базе данных, прикрепленной к пользователю. Вы также сохраняете этот же GUID в файле cookie сеанса.

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

Этот метод работает очень хорошо.

Answer 7

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

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

Answer 8

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

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

Возможно, вы захотите настроить сборку мусора и неактивность сеанса. Вы также должны убедиться, что ваша система защищена от атак фиксации сеанса.

C.