В сайте asp.net, как предотвратить несколько логинов того же идентификатора пользователя?

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

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

Мы реализовали систему для этого в следующих направлениях:

• Добавили свойство в профиль пользователя для хранения идентификатора сеанса.
• Каждый раз, когда пользователь входит в систему, сохраняет идентификатор сеанса в профиле.
• На любой странице, требующей такого уровня безопасности, проверьте, соответствует ли идентификатор сеанса, хранящийся в профиле, их сеансу.Эту проверку можно выполнить в настраиваемом обработчике событий AuthorizeRequest или в базовом классе, от которого происходят эти страницы, а если нет, перенаправить их на страницу входа.

Мы выбрали вариант базового класса, так как у нас есть два уровня аутентификации:

1. У пользователя есть токен cookie, чтобы доказать, что он вошел в систему в какой-то момент в прошлом - это нормально для показа им ограниченного содержимого сайта .
2. Пользователь фактически предоставил свои данные для входа в систему в этом сеансе - это требуется при отображении им любых личных данных (адреса электронной почты, предпочтения, сохраненные поисковые запросы и т. Д.).

Основные проблемы, с которыми вы столкнетесь практически с любой системой:

1. Использование IP-адреса пользователей ненадежно - корпоративные пользователи, те, кто использует прокси-серверы и т. Д., Часто используют общий IP-адрес, поэтому будет "казаться" одинаковым Пользователь.
2. Ненадежно полагаться на выход пользователя из системы - компьютер / браузер пользователя может дать сбой, не давая им возможности выйти из системы, пользователь может / забудет выйти из системы.
3. Использование тайм-аутов сеанса ненадежно - если вы не используете сеансы InProc , событие SessionEnd никогда не срабатывает, если ваш сервер выходит из строя, событие не вызывается и т. Д.

проблемы, с которыми вы столкнетесь с таким решением, как мое:

1. Это не мешает второму пользователю войти в систему - вместо этого он блокирует первого пользователя, что должно препятствовать обмену данными в первом место.
2. Если вы не реализуете это как обработчик AuthorizeRequest, вы должны помнить о выполнении проверки страниц, которые должны быть заблокированы.

Ответ на комментарий

В ответ на ваш конкретный запрос:

1. Поставщик профиля по умолчанию хранит данные в той же базе данных SQL, что и поставщик членства (таблицы создаются вместе с членством и таблицы ролей). Если бы вы сохранили его «в кеше», это должен был бы быть глобальный кеш приложения в соответствии со строками , которые предлагает KMan в варианте 2 -и, как указано в комментариях, вам нужно будет установить тайм-аут для этого, и это возвращает нас к проблеме надежного определения этого.
2. Пользователь не выходит из системы: это обрабатывается в нашей системе, не блокируя будущих пользователей, а блокируя ранее вошедших в систему пользователей - так: {{1 }}
   • Алиса заходит на сайт, входит в систему, начинает просматривать.
   • Боб заходит на сайт, входит в систему, используя данные Алисы, и начинает просмотр.
   • Алиса пытается продолжить просмотр, блокируется, ей нужно снова войти в систему.
   • Боб заблокирован.
   • и др.

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

Я просмотрел таблицу членства и не увидел ни одного столбца, такого как «IsLoggedIn», поэтому API членства не соответствует этому требованию.

Возможно, вы можете использовать систему Asp.net Cache и пометить пользователя как «LoggedIn». Таким образом вы можете проверить наличие дополнительных логинов.