Uploaded image for project: 'Confluence'
  1. Confluence
  2. CONF-22530

Change default context path in standalone distribution to "/confluence"

    Details

    • Last commented by user?:
      true

      Description

      This would help people avoid problems like CONF-20426, where running Confluence on the same machine as another Java application such as JIRA breaks session cookies.

        Attachments

          Issue Links

            Activity

            Hide
            chris@atlassian.com Chris Mountford ON LEAVE added a comment -

            Via CONF-20426

            I think the correct solution is to separate the session cookie key namespaces. The JIRA and Confluence session keys should be unique since cookies are not scoped to a port and it's reasonable to expect the two apps to be configured on the same host at the root path with different ports.

            So the JIRA session cookie would be JIRA_SESSION and Confluence would be CONF_SESSION, say.

            Show
            chris@atlassian.com Chris Mountford ON LEAVE added a comment - Via CONF-20426 I think the correct solution is to separate the session cookie key namespaces. The JIRA and Confluence session keys should be unique since cookies are not scoped to a port and it's reasonable to expect the two apps to be configured on the same host at the root path with different ports. So the JIRA session cookie would be JIRA_SESSION and Confluence would be CONF_SESSION, say.
            Hide
            chris@atlassian.com Chris Mountford ON LEAVE added a comment -

            Implementing this exact "solution" would only address the defalut case and not the completely reasonable root context path configuration for multiple tomcat apps on a single network interface.

            Note also that this is inherently a workaround to a limitation in cookie scoping.

            Show
            chris@atlassian.com Chris Mountford ON LEAVE added a comment - Implementing this exact "solution" would only address the defalut case and not the completely reasonable root context path configuration for multiple tomcat apps on a single network interface. Note also that this is inherently a workaround to a limitation in cookie scoping.
            Hide
            matt@atlassian.com Matt Ryall added a comment -

            Yes, Chris, this is definitely a workaround for limitations in cookie scoping. Yes, it's not a total solution because people can still change the context path to empty and hit this problem. But I think that this workaround is a better way forward than changing the cookie name.

            If we were to change the cookie name for Confluence, it would definitely break stuff. It was immediately obvious that stuff broke when we tested it. This includes several Atlassian plugins, undoubtedly a number of third-party plugins, custom authenticators, and proxies or load-balancers that are Java-session-aware.

            Also, from the servlet 2.4 spec, §SRV.7.1.1 (emphasis mine):

            The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be JSESSIONID.

            The Tomcat documentation advises against changing the cookie name too. I think we shouldn't do it, and the JIRA devs I've spoken to seems to agree with me on that.

            Show
            matt@atlassian.com Matt Ryall added a comment - Yes, Chris, this is definitely a workaround for limitations in cookie scoping. Yes, it's not a total solution because people can still change the context path to empty and hit this problem. But I think that this workaround is a better way forward than changing the cookie name. If we were to change the cookie name for Confluence, it would definitely break stuff. It was immediately obvious that stuff broke when we tested it. This includes several Atlassian plugins, undoubtedly a number of third-party plugins, custom authenticators, and proxies or load-balancers that are Java-session-aware. Also, from the servlet 2.4 spec, §SRV.7.1.1 (emphasis mine): The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be JSESSIONID. The Tomcat documentation advises against changing the cookie name too. I think we shouldn't do it, and the JIRA devs I've spoken to seems to agree with me on that.
            Hide
            chris@atlassian.com Chris Mountford ON LEAVE added a comment -

            You make a convincing argument Matt.

            Interestingly I think there is another Tomcat mechanism that may help solve this - it was designed for the purposes of session affinity in a load balancing scenario.

            Check http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html on the topic of jvmRoute.

            It appends the jvmRoute id (specified in the <Engine>) to the JSESSIONID value.

            Show
            chris@atlassian.com Chris Mountford ON LEAVE added a comment - You make a convincing argument Matt. Interestingly I think there is another Tomcat mechanism that may help solve this - it was designed for the purposes of session affinity in a load balancing scenario. Check http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html on the topic of jvmRoute. It appends the jvmRoute id (specified in the <Engine>) to the JSESSIONID value .
            Hide
            matt@atlassian.com Matt Ryall added a comment -

            Wow, good find. I wonder if that is a potential solution. We should definitely test it out.

            Show
            matt@atlassian.com Matt Ryall added a comment - Wow, good find. I wonder if that is a potential solution. We should definitely test it out.
            Hide
            barconati Bill Arconati added a comment -

            Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now.

            Thanks again for your idea.

            Bill Arconati,
            Group Product Manager

            Show
            barconati Bill Arconati added a comment - Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Thanks again for your idea. Bill Arconati, Group Product Manager

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Last commented:
                  2 years, 1 week, 4 days ago