Cannot View Confluence Mentions In JIRA

After Upgrading to JIRA 5.1.4. The new 'mentions' feature in JIRA now shows up under tickets that have been embedded in our Confluence instance. OAuth trust has been established between the two, and JIRA issues are displayed within Confluence fine, however the reverse is not working.

Under the Issue Links heading this is displayed:

wiki Page Wiki Page You do not have permission to view this page

However the url that is generated is correct, and following it will take you to the correct Confluence page. Is there a specific Application Link URL that needs to be added to the Trust for this feature?

14 answers

0 votes

Hi Natt,

Like I mentioned thru the ticket, try to recreate this App Link without this URL Patterns, by-passing the proxy and without the wildcards (IPs with *), just to check where the error relays.

I tried this, leaving only one URL pattern : /sr/jira.issueviews:searchrequest to allow JIRA tickets to be displayed in Confluence.

IP addresses are statically set. The auth works pulling JIRA info from Confluence.

I have the same problem on a 5.1.5 JIRA instance (linked Confluence is on version 4.3.1). I have no URL or IP patterns configured.

Gerald, are you using a reverse proxy in front of your JIRA/Confluence instances? I'm running JIRA 5.1.4 & Confluence 4.2.13

have you resolved this in the mean time? what was the solution?

0 votes
Deleted user Mar 25, 2013

Same for me, Confluence 4.3.1 and JIRA 5.1.8. Followed the instructions on word by word. Then I thought I should make a request at Atlassian, and document there the current state (this support request is not open to the public). At the end of the request, I have added the following comment. I do not know if that qualifies for an answer, but perhaps it is the missing hint ...

Today I wanted to document the current state of the issue, and for that purpose, I recreated the application link between JIRA and Confluence. I noticed there that both "Trusted Application" and "OAuth" was configured. So I deleted the link, and recreated it with OAuth online, to test that (worked as expected). Then I disabled OAuth, and enabled "Trusted Application", and now the links are working in both directions. I have checked the different cases (anonymous, not authorized user, authorized user with public page/issue and private page/issue), and it works now as expected. I do not know what the real reason was, but I would like to keep the working definition now.

I have done that in both application (Confluence and JIRA), but the double configuration was only in JIRA, and there the link was not shown correctly. So I hope this will help others to solve their problems as well.

Any solutions identified for this? I have the same issue.

If you're behind Apache or another reverse proxy, you can re-add the link pointing it to the INTERNAL Tomcat port that you're proxying to.

This fixes it, however the critical issue with that is the link shows as the internal port and that shows in the URL for the issue. So it's a bit of a lame fix that isn't really usable...but's a fix.

Still investigating - but it looks definitely looks to be proxy related.

We fixed our issue by removing adn recreating application links

I was able to fix this in our environment (Jira v5.2.7, Conf v5.1.2) by editing the Trusted Application configuration in Jira and adding this URL to the Outgoing Authentication URL Patterns:


I see this STILL occuring on Confluence 5.1.5 and JIRA 6.0.6, if both Confluence and JIRA are proxying from behind their own individual Apache installs. From 443 Apache to some other "internal" port on the app/tomcat side.

Definitely not resolved for installations behind nginx/apache or other web frontend.

The issue: seemed to be a sign that it was fixed in the later versions of JIRA but clearly not the case.

This is running our app without any URL patterns in the application link areas on either side, JIRA is setup with the proper "proxy-host" bit in server.conf, etc. It works if I put the app link to our internal proxy port but that then gives a backdoor to get into the system by that port (at least tells users what the port is).

I'm seeing this in Confluence 5.3 and JIRA 6.1.

I'm seeing on 5.3 and 6.1 too.

We are seeing this in Confluence 5.3 and Jira 6.1.1 as well, both of which are behind an Apache web front-end.

Just to answer this, we wound up shifting away from Apache front-end and did SSL directly within Tomcat. Once that was done, it worked perfectly. We found no other possible way to do this with Apache in front.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,728 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you