Issues linking Jira Service Desk and Confluence

[rapidtk]

We have had two separate issues creating a link between Jira Service Desk and Confluence on the same Windows server but with two separate Tomcat instances: Jira 8080(HTTP)/8442(HTTPS) and Confluence 8090/8443, the base URL in both cases is HTTPS.

We couldn't get the Application Link to work using the HTTPS addresses, but it did work fine using the HTTP address and Oauth.  The server sits behind a firewall that blocks port 8080 and 8090 so there was no security risk involved {so this was actually our preferred configuration} i.e. only port 8442 and 8443 are accessible to outside users.  Jira nicely gave us a warning message about the Application (HTTP) and Display (HTTPS) addresses being different and being behind a firewall (exactly our case) and created the link without issue.

Everything seemed to work fine, but now that Firefox and Chrome have blocked mixed content by default, there are issues:

1. The first issue is that the Jira Service Desk seems to "inconsistently" use the Application Address (HTTP) when it should be using the Display address (HTTPS).  When you simply type into the Search bar in the customer portal, the service desk suggests links that are built correctly usingthe HTTPS address:

However, if you go into one of the categories like Technical Support, and then type into the Search bar, the links are incorrectly built with the HTTP (8090) address, and clicking on any of them to open is either blocked because of mixed content (behind our firewall) or is inaccessible (outside the firewall) - either way it would be much better if the window would not simply spin and give no indication to the user what the error is.

2. Secondly, we were finally able to resolve the HTTPS application linking issue; because we assumed that was the problem with Jira Service Desk building the links incorrectly was because of our HTTP application link (even though it really shouldn't matter in this case).

We tested with a new service desk and added a new link to Confluence and the HTTPS links are indeed always correctly built now, but despite what the online documentation says here https://confluence.atlassian.com/servicedeskcloud/set-up-a-knowledge-base-957150219.html there appears to no longer be a way to "unlink" the knowledge base from the help desk anymore?!?  We assume that simply deleting the link and rebuilding it will take care of the issue, but the only options are "Create Article" and "Go to Confluence" so we can't do that anymore, so what do we do to rebuild the link?

I would assume that #1 is a "bug" or maybe just a "limitation", and I'm hoping that #2 can be overcome somehow, but if anyone has insights, please let us know, thanks.

[Andy Heinzer]

Those mixed content happen because the site is being accessed on an address/port combination that doesn't match the server.xml files parameters set for that sites Tomcat instance.  Specifically the proxyName, proxyPort, and/or scheme parameters that should be defined there.  Since you're using a proxy and SSL, I would expect that your connector in both Jira and Confluence's server.xml files should have these parameters defined for each connector.    It might still be possible to connect to that port using a different address for example, and this can work. But when you connect using an SSL protocol such as https, but the scheme parameter is either not defined or set to use http, you get these kinds of mixed content error.

Since you created an application link using http, but the main site is accessed over HTTPs, this is another way that having one application using HTTPS is having to try to load content from the other application but has to do so using only http protocol.  Modern browsers like chrome and firefox flag this kind of data transfer because the content in the browser might not all be ssl/tls secured.

As for your 2nd question, this KB linking feature is built on top of the application link.  You need to have an application link between a Jira and Confluence in place before you could create this KB integration.  That said, if you want to remove this KB integration for that project, you can do so from within the Jira project settings -> Knowledge base link without the need to delete the application link entirely.  The URL for this page should be something like $JIRAURL/servicedesk/admin/{ProjectKey}/confluence-kb

Then just select the 'Don't link to a Confluence space'  This will remove the kb integration with this project without deleting the entire application link.

[rapidtk]

Hi Andrew,

Thank you for your response - on the first part, we are not using a proxy and a scheme is explicitly specified for the https port - we tried to copy this out of the examples on the web (which are unfortunately, not very clear, but I understand that it is a Tomcat issue) so this could certainly be wrong (this is on IIS - I blanked out the keyfile info):

        <!-- Relaxing chars because of JRASERVER-67974 -->
        <Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
                   maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
                   maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8442"
                   acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>
        <Connector port="8442" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="200"
                   relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
                   SSLEnabled="true" secure="true" scheme="https"
                   keystoreType="PKCS12" keystoreFile="/SSL/XXX.pfx" keystorePass="XXX"/> 

As far as the second part, that did work, thank you - simply deleting the link and then recreating it successfully builds both the link and what is embedded into the frame with https! 

It would be nice if the https connection wasn't strictly required for the application link (just for performance reasons as noted before) but that's such a minor issue that it's probably not worth pursuing, thank you again for all of your help.