It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

JIRA session timeout set to 1 hour due to JIRA bug - Okta and 2FA users take note!

(this is a straightforward bug report, but https://jira.atlassian.com no longer allows reports from mere mortals, and Starter licensees can no longer create support tickets)

As you may know, JIRA's default session timeout these days is 5 hours, as specified in atlassian-jira/WEB-INF/web.xml:

<!-- session config -->
<session-config>
<session-timeout>300</session-timeout>
</session-config>

The problem is that in reality, a session never lasts more than 1 hour.

A 1 hour session isn't much of a problem to regular users who click 'Remember me', but it is a (really annoying) problem for:

- Users of Okta and similar external authentication systems that don't set a long-lasting "remember me" cookie equivalent. Okta users will be redirected to Okta every time their 1h session expires. This gets really annoying.

- Users of 2FA plugins like SecureLogin. Such users will have to re-enter a 2FA token after an hour of inactivity, because the plugin stores its "2fa authenticated" state in the session.  

 

To see your JIRA's session timeout, add the following JSP to atlassian-jira/secure/sessionattributes.jsp

<%@ 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) + "<br>");
}
%>

Then hit https://your.jira/secure/sessionattributes.jsp, and look for the 'Max Inactive Interval' line, which returns the HttpSession.getMaxInactiveInterval() value (i.e. session length). You'll probably see:

Max Inactive Interval: 3600

3600 seconds == 1 hour.

The problem is the Bot Killer plugin. Bot Killer initially sets the session timeout to 1 minute, and then it meant to set it back to the default on the second request. But it's buggy: sessions always get set back to 1 hour.

To demonstrate this for yourself, remove your JSESSIONID cookie, then hit /secure/sessionattributes.jsp (logging in if necessary). On first hit, 'Max Inactive Interval' will be 60. On second hit it becomes 3600.

Disabling the Bot Killer plugin is a simple and safe fix. Afterwards (and after removing your JSESSIONID) 'Max Inactive Interval' should report '18000' = 5h.

4 answers

Okta is reporting the following:

https://help.okta.com/en/prod/Content/Topics/ReleaseNotes/production.htm

Okta Production 2017.49 began deployment on December 11 

JIRA and Confluence SAML toolkits updated to version 3.0.6

This version supports the following:

  • Support for adding Remember me cookie during JIRA logins.
  • Fix for new sessions not being created for Jira and Confluence apps when an already logged in user re-authenticates with a new SAML assertion.
  • SP-initiated flows are disabled for Confluence users that are not present in Okta.

For version history, see Confluence Authenticator Toolkit Version History and JIRA Authenticator Toolkit Version History.

I have not tried it yet, so I don't know.

Hi Jeff,

Thank you for finding the reason behind this issue. We had two customers, who had the problem, that they had to revalidate the Secure Login PIN in a very short interval. But we were not able to reproduce the issue on any of our test systems. But your finding should explain the issue.

Regards,
Alexander

Hi Jeff, 

we have that the same problem, when we can expect that the problem will be solved?

 

Thanks and Regards

Martin Beke

This bug has been around for some time, and every SSO-vendor should know about it. We reported the bug to Atlassian, but I do not know the status of that case.

Our experience was that there were a few prerequistes for it to happen though.

We (Kantega Single Sign-on) implemented a fix for it  2016-11-21 in version 1.68 our add-on. That is also the reason we added the following to our debug information page.

sesssion: {maxInactiveInterval: 18000, lastAccessedTime: Fri Aug 25 08:46:55 CEST 2017}

-Lars

Hi @Jeff Turner 

When I hit url/sessionattribute.jsp I get a dead link. Any idea why?

Is atlassian-jira/secure/sessionattributes.jsp present? Is it readable by the user Jira is running as?

Thank you for your reply. The issue is with the file permissions. And below is what I see, 

Session attributes

Session ID: 43EF
Max Inactive Interval: 3600
atlassian.xsrf.token: B0CJ-
ASESSIONID: jcj7vl-43EFDBDCEADAE7688C27AD
com.atlassian.labs.botkiller.BotKiller: 28800

I have removed session cookie and I saw rest to 3600, now I am not sure where to disable bot killer any suggestions?

Thanks

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

303 views 1 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you