Просьба указать, как предотвратить одновременное вход в систему нескольких пользователей с использованием идентификатора пользователя?
Я искал в Интернете и нашел некоторые способы, но почему-то они не работают в таких ситуациях:
Пожалуйста, предложите мне какой-то способ.
спасибо
haansi
Там может быть несколько возможностей. Быстрый ответ:
Поддерживать флаг в базе данных; при каждом обновлении флажка. Например, при каждом запросе проверки подлинности вы можете отклонить запрос на вход, если флаг уже прав.
Кроме того, вы можете сохранить список пользователей в объекте Application и использовать .Contains, чтобы узнать, существует ли он.
- EDIT -
Давайте попробуем параметр флага базы данных; и предположим, что у вас есть метод под названием StillLoggedIn(User), который обновляет дату/время и флаг.
Итак, когда пользователь входит в систему:
Для последующих запросов приложение вызывает StillLoggedIn(User);
Подготовьте службу Windows, которая время от времени будет просматривать базу данных (скажем, через 5 минут, если у вас есть 10000 пользователей). Служба будет сравнивать дату/время базы данных с текущей датой/временем и пометить флаг как 0, если currentTime минус lastUsedTime больше, скажем, 5 минут.
Это может быть что угодно, кроме базы данных и службы Windows.
Мы реализовали систему для этого в следующих строках:
Мы пошли для опции базового класса, поскольку у нас есть два уровня аутентификации:
Основные проблемы, которые вы найдете практически в любой системе:
InProc, событие SessionEnd никогда не срабатывает, если ваш сервер выходит из строя, событие не вызывается и т.д.Проблемы, которые вы найдете с таким решением, как мои:
Ответ на комментарий
В ответ на ваши конкретные запросы:
В самом основном, это не остановит пользователей, разделяющих их логины, но вызовет их раздражение, заставив их продолжать вход в систему. Если вам нужно добавить задержку в процесс входа в систему, то, если другой session id пытается войти в сайт в течение таймаута сеанса (по умолчанию 20 минут) или в другое время, например, на основании среднего времени, которое пользователь проводит на странице, а затем отклоняет попытку входа.
Здесь нет ни одного ответа, поскольку это зависит от того, как вы аутентифицируете пользователей. Однако основная логика была бы простой: когда пользователь входит в систему, проверяет свое имя пользователя или идентификатор на список уже зарегистрированных пользователей и, если есть совпадение, не аутентифицирует их (и вместо этого дает им какое-то сообщение, объясняющее почему они не могут войти в систему).
Очевидно, что именно то, как вы это делаете, зависит от того, как вы аутентифицируете пользователей и сохраняете данные пользователя - вам нужно будет предоставить более подробную информацию, если вам нужна дополнительная помощь.
Я просмотрел таблицу членства и не видел ни одного столбца, такого как "IsLoggedIn", поэтому членский API не отвечает этому требованию.
Возможно, вы можете использовать систему кэша Asp.net и указать пользователя как "LoggedIn". Таким образом, вы можете проверить дополнительные логины.
Так я и делаю.
После входа в систему, проверьте флаг и идентификатор сеанса от БД, если вы вошли в систему с той же учетной записью и другим идентификатором sessionID (Сравните недавно сгенерированный текущий идентификатор сеанса и идентификатор сеанса от БД), предупредите пользователя о том, что "система обнаружила, что вы не вышли из системы ваш последний логин, нажмите <" OK " > , чтобы выйти из последнего входа и создать новый сеанс." Если ОК, просто замените старый SessionId текущим SessionID в DB.
Еще одна вещь - проверить текущие идентификаторы sessionID и sessionID из БД на каждой странице, если это не так, выйти и перенаправить на страницу входа.
Независимо от того, что пользователь не вышел из системы правильно или просто закрыл браузер, у пользователя есть шанс выйти из системы и не нужно ждать окончания сеанса от IIS. Это предотвратит одновременное использование нескольких учетных записей с одинаковой учетной записью.
Надеюсь на эту помощь, спасибо...
Что мы сделали, мы использовали комбинацию состояния сеанса и состояния приложения для предотвращения повторного входа в систему.
Когда пользователь регистрирует свой userId, он извлекается из базы данных членства asp.net и сохраняется в состоянии приложения как уникальный объект.
Так как состояние приложения является глобальным для приложения и не является специфичным для пользовательского сеанса, мы можем проверить, сохранен ли userId в состоянии приложения. Если он уже сохранен, мы можем уведомить пользователя и остановить вход в систему. Когда сеанс истекает (в Session_End в файле Global.asax), этот объект состояния приложения для этого конкретного пользователя может быть удален из состояния приложения, чтобы он мог снова войти в систему после истечения срока его сессии.
Здесь код: В Login.aspx.cs:
protected void OnLoggingIn(object sender, LoginCancelEventArgs e)
{
// Accesses the database to get the logged-in user.
MembershipUser userInfo = Membership.GetUser(LoginUser.UserName);
UserMan.UserID = userInfo.ProviderUserKey.ToString();
if (Application[UserMan.UserID] != null)
{
if (Convert.ToString(Application[UserMan.UserID]) == UserMan.UserID)
{
e.Cancel = true;
}
else
{
// Save the user id retrieved from membership database to application state.
Application[UserMan.UserID] = UserMan.UserID;
}
}
else
{
Application[UserMan.UserID] = UserMan.UserID;
}
}
И в Global.asax:
void Session_End(object sender, EventArgs e)
{
// Code that runs when a session ends.
// Note: The Session_End event is raised only when the sessionstate mode
// is set to InProc in the Web.config file. If session mode is set to StateServer
// or SQLServer, the event is not raised.
if (Application[UserMan.UserID] != null)
{
if (Convert.ToString(Application[UserMan.UserID]) == UserMan.UserID)
{
Application.Contents.Remove(UserMan.UserID);
}
}
}
Несмотря на то, что это решение кажется немного беспорядочным, оно работает достаточно хорошо, не слишком много кодирования и меньше ударов базы данных.
Zhaph - Ben Duguid, Небольшой заметки Профиль не может быть доступен в AuthenticateRequest, поскольку он не создан до события приложения AcquireSessionState, поэтому, если бы они использовали такой подход (вместо подхода к странице), им пришлось бы обрабатывать AcquireRequestState или PostAcquireRequestState
Когда член входа в систему. setup a Random int ex. randNo, сохранить кеш [UserName] = randNo, session [UserName] = randNo. Когда участник получает доступ к любой странице, мы проверяем: cache [UserName] == Session [UserName] в порядке, иначе этот пользователь будет выходить из системы. (Среднее: сначала вход, выход из системы)