Summary

The atlassian-bot-killer plugin watches every request via a servlet Filter and checks if it has seen the session before. If not it must be the first request for that session. It then stores the original session timeout in the session itself and sets the session inactivity timeout to be 1 minute. If the session makes a second request then it gets bumped back to the original timeout of say 5 hours. It follows the same strategy on requests with a known user however to be conservative it sets the inactivity time out to be 10 minutes instead of 1. Context getting-rid-of-unwanted-http-sessions

Due to wrong logic, all users are considered bots and all sessions have their inactive lifetime reduced, overwriting all normally configured settings. This limits user's session to one minute or one hour.

Steps to Reproduce

Based on kczeladko steps:

1. Configure session timeout to 300 = 5h in $JIRA_INSTALL/atlassian-jira/WEB-INF/web.xml
2. Restart Jira
3. Create page in $JIRA_INSTALL/atlassian-jira/secure/sessionattributes.jsp to check session attributes
4. Do a 1st visit to Jira http://company.xyz/jira/secure/sessionattributes.jsp
5. Visit 2nd time Jira - sessionattributes.jsp
6. Visit 3rd time Jira - sessionattributes.jsp

Expected Results

User session timeout is 5h (300 min, 18000 sec).

• 1st call

  Session ID: 6CA579E3F814476B4FA00F1D9034BD49
  Max Inactive Interval: 18000
  

• 2nd call

  Session ID: 6CA579E3F814476B4FA00F1D9034BD49
  Max Inactive Interval: 600
  com.atlassian.labs.botkiller.BotKiller: 18000
  

• 3rd call

  Session ID: 6CA579E3F814476B4FA00F1D9034BD49
  Max Inactive Interval: 18000
  com.atlassian.labs.botkiller.BotKiller: 18000
  

• Note the change of "Max Inactive Interval": 18000 -> 600 -> 18000

Actual Results

• User session timeout is 1h
• BotKiller take Max Inactive Interval value read session timeout from web.xml, but still overwrite MaxInactiveInterval to 3600

  Max Inactive Interval: 3600
  ...
  com.atlassian.labs.botkiller.BotKiller: 18000 
  

• Change of "Max Inactive Interval": 18000 -> 60 -> 3600

Notes

• Based on comment from thomas.weissschuh893360640
  JRASERVER-60844?focusedCommentId=1598784

  In BotKiller.java the method isThereAUserInPlay is used to determine if a request is performed by an actual user instead of anonymously.
  For this it checks if the Jira usermanager is available to make sure this method will not fail during Jira startup or shutdown.
  To hook into the Jira lifecycle the BotKiller class implements to LifecycleAwareInterface and expects to be managed by the Jira component system to call its onStart method to enable its real functionality.

  Unfortunately the class is not actually registered as a component in Jira (as indicated by the plugin manager web UI) and instead is managed by the BotKillerFilter class.
  BotKillerFilter however does never call onStart, so that BotKiller never thinks that Jira has started and therefore classifies all requests as being from bots.

• Related KB When using a third-party authenticator, user sessions may terminate earlier than expected when idle
• sessionattributes.jsp code:

  <%@ page session="true" import="java.util.*" %> 
  <h1>Session attributes</h1> 
  <% Enumeration keys = session.getAttributeNames(); out.println("Session ID: " + session.getId() + "<br>"); out.println("Max Inactive Interval: " + session.getMaxInactiveInterval() + "<br>"); while (keys.hasMoreElements()) { String key = (String)keys.nextElement(); out.println(key + ": " + session.getValue(key) + "<be>"); } 
  %>
  

Workaround

• Disable BotKiller Plugin