As of 11/11/2013, this issue is NOT resolved. I have just updated my company's JIRA/Confluence instance to the latest releases (JIRA 6.1 and Confulence 5.3), and now our application linking is broken.

This is a blocker for us, as our application deployments depend on being able to reference JIRA issues from within Confluence.

Atlassian, please address this issue quickly.

Thanks for the details Todd. The SSL reverse proxy workaround is not really what we are looking for, but we might have to try it. This is making our setup extremely complicated, difficult to document, and difficult to troubleshoot, especially since we already have a web application running on SSL/443 on this machine. From what I understand about the way SSL works with IP/port combos, we would then have to add an extra IP to this box, and then try to do some more dancing in the configs. If the Atlassian product(s) would just work like they should be designed, then we wouldn't have this conundrum.

Yes, Atlassian needs to solve this issue. Until then, I can't really recommend deployment of JIRA/Confluence to all our clients actively looking for such a solution.

CPDev: I think Atlassian should just fix this issue, but I don't believe that the /etc/hosts workaround won't work for you.

The way we had to set this up was as follows. This assumes that confluence runs at https://<external url>/confluence and JIRA runs at https://<external url>/jira. You'll need to modify it if your URLs look different. This also assumes that you have Confluence set up to listen on 8443 over https, which I believe you do.

1. Change /etc/hosts to resolve <external host> to 127.0.0.1
2. Run an instance of apache ON LOCALHOST with an SSL reverse proxy set up like this:
a. Make a vhost for <external URL>
b. Set up an ssl reverse proxy on that vhost like this:

# SSL Proxy Engine                                                                                                      
SSLProxyEngine on
SSLProxyMachineCertificateFile /path/to/unencrypted-client.pem
SSLProxyCACertificateFile /path/to/trusted-cert-file
SSLProxyVerify none
ProxyRequests Off

# Preserve Host while proxing                                                                                           
ProxyPreserveHost On

# Optimizations (optional)                                                                                              
ProxyReceiveBufferSize 4096

<Location /confluence>
  ProxyPass               https://localhost:8443/confluence
  ProxyPassReverse        https://localhost:8443/confluence
</Location>

<Location /jira>
  ProxyPass               https://localhost:8443/jira
  ProxyPassReverse        https://localhost:8443/jira
</Location>

If you do this, then when Confluence wants to talk to JIRA, it makes a request to https://<external url>/jira (standard port 443), which resolves to 127.0.0.1, which then gets reverse proxied by apache to localhost:8443/jira, and the host name is preserved so your JIRA instance should be ok with the app link request (app links verify the hostname, so it will break if you do not preserve that while proxying).

This works around this issue (displayURL is now the same as the app link URL) AND another issue that I think you are seeing, JRA-34550. According to your answers.atlassian.com post, you tried to get app links working on 8443, 8444, etc. but that did not work either. App links are broken over https on ports that are not the default 443. We spent an inordinately long time debugging that one, as well.

In the end, it took a lot of contortions, and an entire extra apache instance to do the proxying, but it worked out. This might be easier if you can run nginx or something at your site – I hear the proxy setup is easier there.

Anyway, hope that helps. It would be awfully nice if app links actually worked properly and we didn't have these issues. the above approach has made the repeated regressions of this issue moot for us.

Thanks Todd for your input, however, the /etc/hosts workaround does not/will not work for our deployment. See description here: https://answers.atlassian.com/questions/227450/confluence-shows-application-url-instead-of-display-url-when-inserting-a-jira-issue-via-jira-macros-addon

This issue is not resolved and the regression remains.

We also had this issue, and after working with support on it for a long while, and after seeing a similar regression, we just reverted to the /etc/hosts workaround described above.

Given the number of problems people are having, and given the lack of certainty on Atlassian's side about whether or not this issue is even resolved, I can only conclude that they don't actually test with this configuration in their regression suite. This is sad because it's an important feature for a fair number of users. Also, it is hard to deal with support on issues like this because you tend to get assigned to someone dedicated to either Confluence or JIRA. The support guys know the apps very well, but problems with app links integration seem to be a no-man's land in between the various support teams.

We tried running with a separate displayURL for a while, but after a couple regressions in various versions, we finally resorted to the /etc/hosts workaround I mentioned above. It is not pretty (especially if you have to do SSL proxies like we do), but it is reliable, and at least have control over our /etc/hosts file. We weren't willing to depend on this not regressing again.

I agree with Peter Callies. This is NOT resolved. See https://jira.atlassian.com/browse/CONF-29182. This issue is occurring in Confluence v 5.3 with JIRA Macros v 5.1.3 and was duplicated and confirmed by technical support when I created a support ticket. My support rep added CONF 5.3 to the list of affected versions.

FYI: I tried rolling back to v4.x of JIRA Macros, as SERGEY previously recommended as a workaround, and can confirm this does NOT work with Confluence 5.3.

This is a regression and is not resolved.

Why is this issue marked as resolved? It appears that many of us are continuing to have this issue in 5.0+ versions.

JIRA 6.0.8, Confluence 5.3. Same problem. Found workaround that worked - replaced confluence-jira-plugin-5.1.jar with confluence-jira3-plugin-4.0.29.jar

This regressed for me, as well, in Confluence 5.2.3

It seems the problem re-appears in Jira Macros v5.0.x. When I downgrade to v4.0.29 together with Confluence v5.1.2 it works.