Запретить обновление последнего времени сеанса связи в Jetty

Question

Возможно ли поручить серверу Jetty не обновлять последнее время доступа сеанса при обращении к определенному сервлету?

Наш пример использования - это HTML-страница, которая отправляет асинхронные запросы в фоновом режиме каждые 5 миниатюр, чтобы обновить его содержимое. Таймаут сеанса установлен в 30 минут. Неудачная проблема с этой конфигурацией заключается в том, что когда пользователь оставляет эту страницу открытой на вкладке браузера, сеанс никогда не истекает, потому что время доступа сеанса обновляется каждым асинхронным запросом.

Для корректности я должен признать, что я еще ничего не пробовал, потому что не смог найти никакой помощи для моей проблемы в Интернете. Если то, что я прошу, невозможно, я собираюсь хранить время доступа в переменной сеанса, которая контролируется непосредственно приложением. Это значение нужно будет проверить раньше, чем будет обработан запрос (в методах сервлетов doGet и doPost), и сеанс должен быть аннулирован вручную. Есть ли лучшее решение?

Answer 1

Сервлет не может отличить, вызван ли запрос каким-либо сценарием или человеком, поскольку оба запроса поступают из одного и того же браузера и, следовательно, отправляют один и тот же JSESSIONID. Поэтому вы должны отметить эти запросы, чтобы отличить его источник. Вы можете пометить их некоторым параметром заголовка или запроса.

Мне нравится ваша идея сохранения времени доступа в переменной сессии (это будет поросенок обратно на сервлет сессии истечения) Ваш алгоритм будет в этом случае:

if isUser(request){ 
    session.lastRobotAccess == null 
}else{ 
    if (session.lastRobotAccess == null) { 
     session.lastRobotAccess = current_time 
    } else { 
     if(current_time - session.lastRobotAccess > session.timeout){ 
      session.invalidate 
     } 
    } 
} 

Когда запрос поступает в контейнер сервлетов является первым обрабатываются фильтрами (если вы определили), а затем сервлетом. Filters are useful for:

Общий сценарий для фильтра является тот, в котором вы хотите применить предварительной обработки или постобработки для запросов или ответов для группы сервлетов, а не только один сервлет. Если вам нужно изменить запрос или ответ только для одного сервлета, нет необходимости создавать фильтр , просто выполните то, что требуется непосредственно в самом сервлете.

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

Вы уже знали, что это вещи, но я просто положил их на «бумаге» :-D