nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cannot View Confluence Mentions In JIRA

Nathaniel Alexander

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?

Accepted answers

All comments

petry

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.

Gerald Schneider

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.

Nathaniel Alexander

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

Nathaniel Alexander

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.

Torsten Weck

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

unknown

Same for me, Confluence 4.3.1 and JIRA 5.1.8. Followed the instructions on https://confluence.atlassian.com/display/JIRA051/Configuring+Trusted+Applications+Authentication+for+an+Application+Link 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.

unknown

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

Mike Rocheleau

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 technically...it's a fix.

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

unknown

We fixed our issue by removing adn recreating application links

Alan Basque

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:

/rpc/xmlrpc

Mike Rocheleau

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: https://jira.atlassian.com/browse/JRA-28821 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).

joapa

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

Prashant Kumar6

I'm seeing on 5.3 and 6.1 too.

Mark Stern

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.

Mike Rocheleau

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

issue

jira

permission