javasessionjettysession-timeoutlastaccesstime

Prevent session's last access time update in Jetty


Is it possible to instruct a Jetty server not to update the session's last access time when a particular servlet is accessed?

Our use case is an HTML page that sends asynchronous requests in the background every 5 miniutes to refresh its contents. The session's timeout is set to 30 minutes. The unfortunate problem with this configuration is that when a user leaves that page open in a browser's tab, the session never expires because the access time of the session is updated by every asynchronous request.

For correctness' sake I have to admit that I didn't try anything yet because I wasn't able to find any help for my issue on the Internet. If what I'm asking for is not possible, I'm thinking of storing the access time in a session's variable that is controlled directly by the application. This value would have to be checked early before a request is processed (in the doGet and doPost methods of the servlets) and the session would need to be invalidated manually. Is there a better solution?


Solution

  • Servlet can't distinguish if the request is generated by some script or human, since both requests come from a same browser, consequently sending the same JSESSIONID. So you have to mark those requests in order to distinguish its source. You can mark them by some header or request parameter.

    I like your idea of storing access time in session's variable (it will piggy back on servlet session expiry) Your algorithm will be in this case:

    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
           }
        }
    }
    

    When request arrives at servlet container it is first processed by the filters (if you have defined) and then by the servlet. Filters are useful for:

    A common scenario for a filter is one in which you want to apply preprocessing or postprocessing to requests or responses for a group of servlets, not just a single servlet. If you need to modify the request or response for just one servlet, there is no need to create a filter—just do what is required directly in the servlet itself.

    Since you can reach session from filter, they are more suitable place for your logic. You won't pollute servlet's logic with additional checking, and you can apply it to other servlets. Filters are also part of servlet specification so this will work in any container.

    You already knew this things, but I've just put them on "paper" :-D