Comments 10
Ограничиваем количество сессия --> Ограничиваем количество сессий
.forEach(key -> sessionRepository.deleteById((String) key));Лучше удалить данные из БД за один запрос. Сначала собираем ключи в коллекцию, а затем делаем один DELETE.
В данном случаем у нас есть только одна активная сессия. Чтобы сделать один DELETE придется реализовывать свой метод, т.к. JdbcIndexedSessionRepository не содерджит такого метода.
Мне вот тоже интересно, а вообще нельзя удалить все неактивные сессии за 1 раз, при этом ничего не выбирая из БД? Что-то типа… principal_name = :userName AND session_id <> :currentSessionId…
Если всё в одной транзакции, то большой разницы по идее быть не должно.
не закрывать старую сессию и не открывать новую сессию
Правильно ли я понимаю, что при таком выборе пользователя одна сессия шарится между 2мя устройствами? И если да, это условно означает, что 2 и более <разных> пользователя могут работать под одной учетной записью с одной общей сессией? Опять же, если да, то чем продиктована такая необходимость?
Технически все хорошо. А вот продуктово ужастно. Вам срочно менеджер нужен. Тот который понимает ваших пользователей.
Выйти и сообщить администратору. Даже звучит грозно.
Подождать 30 минут. То что надо! Как раз чайку попить можно.
Вы точно хотите чтобы пользователи пили больше чая в рабочее время?
А еще можно куки или session_id между компами передавать. Это совсем несложно. При необходимости обучу этому любого бухгалтера минут за 30.
Логин в сервис одной сессией в общем случае не имеет смысла вообще. Пользователь имеет право работать с вашей системой. В чем проблема если у него будет много сессий?
Если хотите привязать пользователя, так привяжете его к компу. Или полным запретом логина с его учетки на других или через аппаратный токен. В 2 компа он тогда точно не залогинится. А в сервисах обычное SSO, без ввода логина и пароля естесвенно.
Выйти и сообщить администратору. Даже звучит грозно.
Подождать 30 минут. То что надо! Как раз чайку попить можно.
Вы точно хотите чтобы пользователи пили больше чая в рабочее время?
А еще можно куки или session_id между компами передавать. Это совсем несложно. При необходимости обучу этому любого бухгалтера минут за 30.
Логин в сервис одной сессией в общем случае не имеет смысла вообще. Пользователь имеет право работать с вашей системой. В чем проблема если у него будет много сессий?
Если хотите привязать пользователя, так привяжете его к компу. Или полным запретом логина с его учетки на других или через аппаратный токен. В 2 компа он тогда точно не залогинится. А в сервисах обычное SSO, без ввода логина и пароля естесвенно.
Sign up to leave a comment.
Контролируем и сохраняем сессии, используя Spring