Ограничить множественный вход одного и того же пользователя в 2 веб-приложения

У нас есть требование ограничить одновременный вход в систему одного и того же пользователя в двух веб-приложениях.

Например, у нас есть 2 веб-приложения: WebApp1, WebApp2.

Пользователь: Панель управления

Если пользователь Dashboard вошел в WebApp1, то тому же пользователю не разрешено входить в WebApp2, вместо этого отображается сообщение об ошибке при втором входе.

Пробное решение:

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

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

Очистите запись БД (идентификатор пользователя, идентификатор сеанса и имя приложения) в следующих сценариях:

  1. Выйти
  2. Время ожидания сеанса
  3. Перезапуск приложения.

Не уверен, как обрабатывать следующие сценарии.

  1. Закройте браузер.
  2. Сбой браузера
  3. Системный сбой

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

как лучше всего аннулировать Http-сессию WebApp2/WebApp1?


architecture websphere servlets tomcat9 httpsession
person Madhusudana    schedule 10.09.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

Затем другое приложение может запросить «Последнее посещение», и если это более 5 секунд (я бы фактически увеличил его до 10 для опроса) или событие выхода из системы, предположим, что первый сеанс ушел и что они свободны. для входа во второе приложение. Если «Последнее посещение» меньше 5-10 секунд, вычеркните их обоих и предупредите администратора с обоими IP-адресами, чтобы решить, какой из них следует убить.

person Rob Conklin    schedule 10.09.2019
comment
Это было бы перебором. Представьте, что у вас 1 тыс. пользователей, это даст вам 200 бесполезных запросов в секунду. И вы также должны эффективно отключить тайм-аут бездействия сеанса, так как пользовательский интерфейс будет постоянно генерировать новые запросы. - person Gas; 11.09.2019

arrow_upward
0
arrow_downward

В дополнение к тому, что у вас есть, вы можете сохранить время последней активности в своей БД сеанса и обновлять его, когда происходит обновление сеанса, как часто (например, каждый запрос или раз в 5 минут) это зависит от ваших требований. Затем в случае перезапуска приложения/браузера/системы вы входите в систему, даже если запись существует, если она старше, чем время ожидания сеанса. И у вас может быть пользователь-администратор, который может вручную удалить запись, если это необходимо.

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

person Gas    schedule 11.09.2019
comment
Спасибо за ответ. Чтобы выйти из старого: имея 2 веб-приложения, мы не знаем, как нам получить HttpSession другого веб-приложения. Например: пользователь панели мониторинга вошел в систему WebApp1 и второй раз входит в систему того же пользователя в WebApp2. Я думаю, возможно, стоит взглянуть на написание кода на уровне контейнера, например: Tomcat -Valve. - person Madhusudana; 11.09.2019
comment
Вот почему я написал, что для этого нужна дополнительная логика, которая может зависеть от времени выполнения. Конечно, вы могли бы написать что-то простое (но, возможно, не самое лучшее с точки зрения производительности/эффективности), например фильтр сервлета, который проверял бы БД, действителен ли сеанс, если нет, выполнял бы автоматический выход из системы в контейнере. - person Gas; 11.09.2019