Я разрабатываю часть управления пользователями веб-сайта, на котором будет проходить веб-трансляция. Цель состоит в том, чтобы одновременно использовать один и тот же пользовательский адрес (адрес электронной почты). То есть мы не хотим, чтобы два человека использовали один логин для просмотра события.
Я уже установил таблицу, в которой хранятся данные регистрации пользователя с regID в качестве первичного ключа. Моя мысль заключается в создании таблицы истории входа с именем пользователя в качестве первичного ключа, внешнего ключа для имени пользователя в таблице регистрации. В таблице истории входа будет просто отметка времени, когда пользователь войдет на сайт. Однако это не приведет к моей цели – предотвратить использование одним и тем же именем входа более одного человека.
Вместо этого было бы лучше иметь поле состояния входа либо в истории входа в систему, либо в таблице пользователя, которая установлена в 1 для входа в систему и 0 для выхода из системы? Для обновления значения при входе в систему и при выходе из системы потребуется хранить хранимую процедуру, и ее необходимо будет проверить, когда пользователь войдет в систему, так что если статус входа = 1, пользователь уже зарегистрировался и не может войти во второй раз. Это приемлемый подход?
Поделитесь другими методами, которые вы использовали, чтобы не допустить использования одинаковых учетных данных для входа несколькими пользователями.
Спасибо, Сид
Если вы можете выйти из уже зарегистрированного пользователя, если кто-то еще входит в систему с одинаковыми учетными данными, вы можете сделать следующее: когда пользователь регистрируется в генерации случайного идентификатора в вашей базе данных для этого пользователя и того же в сеансе cookie . Эти два должны соответствовать аутентификации.
Не сворачивая собственный обработчик сеанса, вы можете сделать небольшое параллельное отслеживание. Когда пользователь входит в систему, вы можете сохранить идентификатор сеанса пользователя и время входа в базу данных (возможно, внутри таблицы информации пользователя). Скрипт входа в систему мог бы проверить наличие, если этот идентификатор sessionID и разрешить / запретить вход в систему на основе наличия идентификатора сеанса. Если идентификатор пуст / пуст, тогда пользователь входит в систему. Если есть идентификатор сеанса, и он больше, чем X минут, разрешите вход. Иначе отрицать их.
Конечно, вы, вероятно, захотите свернуть собственный обработчик очистки сеанса в этот момент, чтобы при удалении устаревших файлов сеанса вы могли одновременно удалить связанные идентификаторы из базы данных.
Проблема здесь заключается в обнаружении входа пользователя в систему (т. Е. Он не вышел из системы).
Один из возможных способов – зарегистрировать в базе данных время его последнего действия и время его явного выхода из системы. Затем вы можете отказать в регистрации, если это было сделано менее чем за 5 минут назад относительно его последнего действия, и если он не заходил в систему между ними.
Вы можете заставить «активность», если страницы веб-сайта периодически опросают сервер с помощью Javascript.
Легко определить, когда кто-то входит в систему. Гораздо сложнее определить, когда кто-то выходит из системы. Если у вас есть механизм быстрого потокового потокового вещания для конкретного пользователя, вы можете захотеть получить что-то, запрашивающее у пользователя, если они захотят убить свою другую сессию, если вы считаете, что может быть один активный.
Как вы выполняете сеансы пользователя на сервере? Если вы храните их в db, вы можете запросить активные сеансы в любое время, когда кто-то попытается войти в систему и посмотреть, уже ли они там. Конечно, вам, вероятно, также придется проверять временную метку, так как вам не гарантировано, что сеансы исчезнут в session.gc_maxlifetime.
Возможно, вы захотите рассмотреть возможность создания глобальной переменной в php для хранения хэш-массива с статусом входа. Это имеет то преимущество, что если приложение по какой-то причине необходимо перезапустить, пользователь не застрял в неправильном состоянии в базе данных.
Вы можете сохранить сопоставление от идентификатора пользователя к IP или cookie сеанса и перенаправить запросы, которые поступают с другой информацией на страницу входа. Если пользователь войдет в систему, другой сеанс будет недействительным и последующие запросы на последнем сеансе перешли на страницу входа.