-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
9
-
18
-
NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.
When multiple applications are configured on the same domain with separate ports, users will be constantly logged out of each application as the SESSION_COOKIE_NAME is identical.
This is due to the Tomcat configuration. Please alter the default bundled Tomcat 7 config so that it has a unique JIRA session cookie by modifying the $JIRA_INSTALL/conf/context.xml to the following (or something similar):
<Context sessionCookieName ="JIRASESSIONID">
This will prevent users from getting into this problem in the first place.
Additional workarounds can be found within User is Constantly Logged out of JIRA.
- causes
-
JRASERVER-8726 Session breaks using JIRA and Confluence with same browser and User ID
-
- Closed
-
- is related to
-
- Closed
- relates to
-
- Closed
- was cloned as
-
- Gathering Interest
[JRASERVER-36960] Configure Tomcat so that it has a unique SESSION_COOKIE_NAME to prevent session overwriting for JIRA
We've been putting up with this issue for several years now, thinking the software, the server or the browser was buggy. Just now come to find out we should have used different servers or different names for the same server. Problem is, everything would have to change, and we already have a large installed base, many tickets/pages and links between the two.
A migration path in addition to the workarounds would be welcomed.
@Phil Berry
A workaround we're using is to create multiple A records on our local DNS. For example,
- jira.mydomain.com --> Points to our server, for example 10.1.1.1
- confluence.mydomain.com --> Point to the same server, 10.1.1.1
- bitbucket.mydomain.com --> Point to the same server, 10.1.1.1
Set the base URL on each of these apps to their own subdomain, and if you access them by their correct base URLs you won't experience any of the cookie issues even though all three apps are installed on the same server (running on different ports).
This has been driving our development team nuts, it's a massive hinderance on productivity when it bombs them out whilst trying to perform a software build.
Would welcome a prompt resolution!
Enterprise level customer. We continue to experience this issue. Gitlab and Github both have this issue sorted out. The only thing preventing us from canceling our Jira contract and moving to another vendor is the Jira ticket history.
This is something making new users go mad and disappointed because it happens often in evaluation installations. Not a good first impression!
Why is this not mentioned in the installation/set up instructions for setting them up together / integrating them??
As others have commented this is an unnecessary pain point and one that's not exactly going to be uncommon!
Hi!
Any plans to set out-the-box fix ?
Thanks
Cheers,
Gonchik Tsymzhitov
Why would Atlassian be "Gathering Interest" on a bug? It's a bug, fix it please! If Atlassian can't even fix the simplest of bugs in their system that significantly affect their customers, why the heck are we paying for support every year? We don't want a work around, we need a fix. This issue was identified in 2014, that is approaching 7 years, how do you even think this is acceptable?