Frequent logouts and Session swap / hijack in JIRA

Still need help?

The Atlassian Community is here for you.

Ask the community

The content on this page relates to platforms which are not supported for JIRA Applications. Consequently, Atlassian cannot guarantee providing any support for it. Please be aware that this material is provided for your information only and using it is done so at your own risk.


Frequent logouts and sessions getting swapped (or hijacked) for some logged in users. When session swap / hijack happens you would see someone else's name as logged in user on top right and if you do not notice and create an issue or comment, it will go as the other user. Conversely, you may find an issue or comment created by your name but you didn't do it.


JIRA is integrated with Apache as per Integrating JIRA with Apache, or a misconfigured LDAP.


  • If use Apache as reverse proxy (mod_proxy) for JIRA server as it handles SSL and talks to JIRA at port 8080 via ProxyPass.
  • Using mod_cache's disk based caching for all URLs. 

Use of mod_cache is known to create problem of session mix ups when Apache is used as reverse proxy with JIRA. Since Apache had been running possibly as long as the uptime of JIRA server which is 101 days, its cache got into a bad state as seen by errors in ssl_error_log file, creating a situation where it started to either drop or mix up JSESSIONID cookie sent by JIRA to client. This results in logout of client or worse session mixups. 

  • Additionally if the LDAP is not configured as per RFC, as detailed in  JRA-47583 - Getting issue details... STATUS , this behaviour can occur.


Error in ssl_error_log:

[xxx xxx xx xx:xx:xx xxxx] [error] (103) Software caused connection abort: cache: error returned while trying to return disk cached data


For Apache:

Restart of Apache itself fixed the issue, but for future following lines have been commented in /etc/httpd/conf/httpd.conf, which is also recommended configuration.

#<IfModule mod_disk_cache.c>
# CacheEnable disk /
# CacheRoot "/var/cache/mod_proxy"


The LDAP engine must not be configured to have a 'user unique ID attribute' ( that is not unique. This is documented in RFC 2307.

Last modified on Sep 23, 2016

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.