Как мне создать систему входа в систему, чтобы каждое имя пользователя могло быть зарегистрировано только в одном месте за раз? Я хочу, чтобы пользователи не указали свое имя пользователя для входа в систему, чтобы они могли не платить за каждого пользователя.
Если пользователь уже зарегистрировался и пытается войти на другой компьютер, я должен заблокировать второй логин (что может быть проблемой, если пользователь вошел в систему на работе, а затем попытался вернуться домой)? Или я должен разрешить второй логин и завершить первый вход? Или у кого-то есть лучшее предложение?
Некоторые Instant Messengers (которые могут работать только с одним зарегистрированным в конечной точке) имеют хороший способ сортировки таких конфликтов. Они показывают сообщение типа
Вы уже вошли в систему из
<COMPUTERNAME>
(в случае веб-приложения, которое будет <IP/Browser> )
и дать вам выбор между
Это технически самый сложный, но, безусловно, самый дружелюбный способ – он гарантирует, что пользователь имеет только один сеанс, не будучи слишком очевиден. И нет плохой крови, когда пользователи не могут войти в систему, потому что они забыли выйти на работу и т. Д.
Blizzard World of Warcraft Я считаю, что это прекрасно реализуется.
В принципе, если вы попытаетесь войти в игру после того, как уже вошли в систему, произойдет первое соединение.
В основном это связано с тем, что сеанс хранится в базе данных. Когда вы храните данные сеанса, также храните имя пользователя. Когда пользователь входит в систему, удаляет любые записи сеанса с этим именем пользователя, а затем создает новый для входа пользователя.
Я бы не предлагал блокировать «новых» людей, пытающихся войти в систему, потому что пользователи не хотят возвращаться на другой компьютер, который у них есть (возможно, за несколько миль), только потому, что они забыли выйти из системы.
Есть и другие вещи, о которых вам, возможно, придется подумать. Такие вещи, как захват сессий. Если пользователь просто кладет куки-файлы в свою систему (что всегда возможно) с помощью правильного sessionid, возможно, что они могут использовать один и тот же сеанс на нескольких компьютерах. В этом случае вы, вероятно, захотите сохранить поле IP, в котором вы сохраняете данные о том, кто в настоящий момент зарегистрирован.
Типичным подходом к этой проблеме является использование
Эта система обеспечивает максимальное количество учетных записей на одну учетную запись, одновременно учитывая указанную ситуацию: пользователь покинул офис без выхода из системы и пытается войти в систему со своей домашней рабочей станции.
Вот основные линии такой системы
Обратите внимание, что общий принцип, описанный выше, может иметь некоторые различия, в частности:
Независимо от логики LM per se, не забудьте сохранить журнал всех связанных с LM событий (логины, выходы, неактивные сеансы «убивает», отказались от входа в систему …). Такие журналы должны включать дату / время, IP-адрес и другую соответствующую информацию и полезны при решении проблем, связанных с украденными паролями и т. Д. Такие журналы также содержат бесценный маркетинг, например, чтобы найти все учетные записи, которые, как представляется, имеют слишком мало мест (и, следовательно, могут приобрести некоторый ugrade), или найти учетные записи и т. Д.
Еще несколько соображений
Заблокируйте первый логин. Если вы входите в систему дома, то в работе вы не хотите блокироваться, поскольку это законный метод. Всегда разрешайте вход в настоящий момент и отбрасывайте старые.
Я бы посоветовал отслеживать, вошел ли каждый пользователь в систему и разрешил второй логин завершить первый сеанс входа в систему.
Затем разрешите пользователю, чей сеанс закончился, сообщить о возможной мошеннической деятельности, если они были вызваны ошибкой.
Не пытайтесь делать это, подсчитывая количество IP-адресов, с которыми пользователь имеет активный сеанс: некоторые пользователи могут находиться за балансированными прокси-серверами.
Решение состоит в том, чтобы написать собственный обработчик сеанса – возможно, самый простой с базовым концом базы данных и разрешить только одному пользователю иметь один открытый сеанс.
Возможно, вы захотите настроить сборку мусора и бездействие. Вы также должны убедиться, что ваша система невосприимчива к атакам фиксации сеанса.
C.
Что касается безопасности, и это то, что вы получаете, всегда хорошо хранить данные сеанса в базе данных. В частности, если вы используете общий сервер.
С точки зрения того, какой пользователь разрешить и который сбить, это вопрос для вас, чтобы судить. Я полагаю, что у вас может быть какая-то вторичная форма идентификации, чтобы убедиться, что они являются реальным владельцем учетной записи. Тот, кто действительно подписался на него.
Я сделал это раньше в веб-приложении, имеющем такое же требование. Вот что я сделал:
Когда кто-то войдет в систему, вы создаете GUID и храните его в своей базе данных, прикрепленной к пользователю. Вы также сохраняете этот же идентификатор GUID в cookie сеанса.
Каждый раз, когда вошедший в систему пользователь попадает на любую страницу вашего сайта, вы проверяете свой GUID-файл cookie и сравниваете его с идентификатором GUID, который им назначается в вашей базе данных. Если эти идентификаторы GUID не совпадают, они вошли в систему на другом компьютере и выходят из этого сеанса.
Этот метод работает очень хорошо.