#jhipster
Вопрос:
Клиентское приложение Oauth2, созданное Jhipster, имеет проблемы с поведением после некоторого простоя. После того, как пользователь, вошедший в систему, некоторое время простоя в приложении, взаимодействие с приложением приведет к нежелательному поведению, например, данные не будут извлечены из базы данных.
Я узнал, что данные сеанса пользователя хранятся в виде файла cookie на переднем конце. Для интерфейса Vue, поиск
this.$cookie.set( не дает результата.
Я вижу идентификатор JSESSIONID в заголовке запроса после входа пользователя в приложение. Итак, я предполагаю, что идентификатор сеанса также хранится где-то на сервере. Для каждого запроса REST сервер проверяет идентификатор сеанса в заголовке запроса, сравнивая его с идентификатором сеанса на сервере. Когда время сеанса истекает, у сервера больше нет идентификатора сеанса. Любой запрос на ОТДЫХ с точки зрения приведет к нежелательному поведению в текущей реализации. Фильтр необходим для проверки идентификатора сеанса запроса на ОТДЫХ на сервере.
Я взглянул на код в пакете безопасности, а также на конфигурацию безопасности. Но я не вижу никакого кода, связанного с пользовательским сеансом.
Как работает сервер в этом отношении?
Обновить:
Чтобы справиться с недопустимым сеансом пользователя для входа в систему, я замечаю, что решатель ExceptionHandlerExceptionResolver обработает исключение недостаточной аутентификации после обновления браузера. В противном случае исключение не будет обработано. Как решить эту проблему?
Комментарии:
1. Реализация OAuth JHipster действительно использует сеанс. Именно там хранятся токены доступа и токены обновления. Когда время сеанса истекает, вам нужно снова войти в систему. Это более безопасно, чем хранить их на клиенте, но имеет недостаток в отсутствии маркера обновления с длительным сроком службы. JHipster также может выступать в качестве сервера ресурсов и проверять переданные JWTS. Вот как это работает с React Native и Ionic.
2. @MattRaible Спасибо за понимание, основываясь на моем опыте, приложение JHipster не требует повторного входа в систему после тайм-аута сеанса. Это создает плохой пользовательский интерфейс для неизвестного результата взаимодействия с приложением. Например, у меня есть ситуация, когда данные (из БД) отсутствуют на странице после щелчка. Если в этом случае этот пользователь должен «снова войти в систему», в приложении должен появиться экран входа в систему или панель с сообщением о тайм-ауте и действиях или так далее. Мы пытаемся исправить эту проблему с пользовательским интерфейсом, но не можем найти код для внесения надлежащих изменений.
3. @MattRaible Можете ли вы дать предложение о том, как бороться с исключением недостаточной аутентификации, пожалуйста?
4. Я не знаю, как это решить. Не могли бы вы, пожалуйста, указать проблему в проекте JHipster с указанием шагов для воспроизведения?
5. Я могу открыть билет на эту проблему. Мы открыли довольно много билетов, но большинство из них, к сожалению, закрыты, ничего с ними не сделав.