Контролируем и сохраняем сессии, используя Spring

[vitos73]

Ограничиваем количество сессия --> Ограничиваем количество сессий

[Arb9i]

спасибо, исправила

[IvanVakhrushev]

.forEach(key -> sessionRepository.deleteById((String) key));

Лучше удалить данные из БД за один запрос. Сначала собираем ключи в коллекцию, а затем делаем один DELETE.

[Arb9i]

В данном случаем у нас есть только одна активная сессия. Чтобы сделать один DELETE придется реализовывать свой метод, т.к. JdbcIndexedSessionRepository не содерджит такого метода.

[reforms]

Мне вот тоже интересно, а вообще нельзя удалить все неактивные сессии за 1 раз, при этом ничего не выбирая из БД? Что-то типа… principal_name = :userName AND session_id <> :currentSessionId…

[Arb9i]

можно, но тогда нужно реализовывать свой конфиг для JdbcIndexedSessionRepository(если создадим наследника), либо же создать отдельный репо для такого удаления(без наследования)

[tsypanov]

Если всё в одной транзакции, то большой разницы по идее быть не должно.

[reforms]

не закрывать старую сессию и не открывать новую сессию

Правильно ли я понимаю, что при таком выборе пользователя одна сессия шарится между 2мя устройствами? И если да, это условно означает, что 2 и более <разных> пользователя могут работать под одной учетной записью с одной общей сессией? Опять же, если да, то чем продиктована такая необходимость?

[Arb9i]

Нет, если пользователь выбрал этот пункт, то он просто не логинится. Т.е. старая сессия остается доступна только для старого устройства(с которого изначально и инициализировалась)

[BugM]

Технически все хорошо. А вот продуктово ужастно. Вам срочно менеджер нужен. Тот который понимает ваших пользователей.

Выйти и сообщить администратору. Даже звучит грозно.
Подождать 30 минут. То что надо! Как раз чайку попить можно.
Вы точно хотите чтобы пользователи пили больше чая в рабочее время?

А еще можно куки или session_id между компами передавать. Это совсем несложно. При необходимости обучу этому любого бухгалтера минут за 30.

Логин в сервис одной сессией в общем случае не имеет смысла вообще. Пользователь имеет право работать с вашей системой. В чем проблема если у него будет много сессий?

Если хотите привязать пользователя, так привяжете его к компу. Или полным запретом логина с его учетки на других или через аппаратный токен. В 2 компа он тогда точно не залогинится. А в сервисах обычное SSO, без ввода логина и пароля естесвенно.