User unexpectedly logged out of Jira server
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms.
- JIRA users are consistently logged out on each page or whilst using other applications (e.g.: Confluence).
- After logging into one application (e.g.: Confluence) then into another (e.g.: JIRA), users are automatically logged out of the other application (or vice-versa).
This is a client-side issue and as such the log files will typically not contain anything in them that will assist in identifying this problem.
If neither of these problems describe your situation, such as you are not using or logging into any other Atlassian applications, it may be that your session cookie (JSESSIONID) is being modified or removed automatically by a browser extension. This can be confirmed by using Jira in your browser's incognito mode, or by reviewing your browser extensions for any with this behavior and disabling them.
This problem is most often caused by the cookie being overwritten when accessing JIRA, Confluence or potentially any other applications with a web-login on the same domain or IP, such as with the below configuration:
As the cookies are not distinguished by the port number, the browser will overwrite the previous cookie and it will appear as if the user has been logged out of the previous application. Given that this is browser-specific, it will not be visible within the application logs.
Another possible cause for Jira 8.20+ is
JRASERVER-73281Getting issue details...
, which causes the
/status endpoint to take a long time to respond and cause the load balancer to understand that the node is not responsive. If that is the case, check the workaround in the bug.
Use separate browsers when accessing each application (IE, Firefox, Chrome, etc) or use private browsing mode in one tab to access JIRA and normal browsing to access Confluence. This is not a recommended fix, however can be used for testing environments.
Configuration of DNS and reverse-proxies are supported by JIRA, however are out of scope of our Atlassian Support Offerings. Consequently, Atlassian can not 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.
As JIRA and Confluence can be resource intensive and as part of standard best-practices, Atlassian recommends running Confluence and JIRA on separate physical machines, behind a reverse-proxy such as Apache Web Server or IIS.
If there is a requirement to use the same machine, any of the below can be utilised to resolve this problem:
- Have separate DNS entries for the same IP, allowing the browser to distinguish between the two, for example:
- Modify the Context path in
server.xmlfor both JIRA and Confluence, as per our How to change the JIRA context path KB. For example, a recommended setup would be:
If you are using Crowd authentication between the products, you have to reconnect all the products (Confluence and Fisheye) to the updated JIRA URL for Crowd authentication.
- Host both applications behind a reverse-proxy, as in Integrating JIRA with Apache & Running Confluence behind Apache.
- Set up Single-Sign-On with Atlassian Crowd, as in our Overview of SSO docs.
Using Tomcat 6, the session cookie name can be changed to something unique (the two applications must have different session cookie name) as per Setting Properties and Options on Startup using the below argument:
Using Tomcat 7 & 8, the session cookie name can be changed to something unique (the two applications must have different session cookie name) by modifying the
<!-- The contents of this file will be loaded for each web application --> <Context> <!-- Default set of monitored resources --> <WatchedResource>WEB-INF/web.xml</WatchedResource>
<!-- The contents of this file will be loaded for each web application --> <Context sessionCookieName ="JIRASESSIONID"> <!-- Default set of monitored resources --> <WatchedResource>WEB-INF/web.xml</WatchedResource>
- After making the above changes, please be sure to recreate any Application Links as the configuration of these can also cause the user to be logged out in the same scenario as in the cause section.