Degraded performance Customers may experience intermittent errors using Community search. Our platform vendor is investigating.
I have linked a JIRA issue in a Confluence page. Usually this would show up in the JIRA issue under "Issue Links". But all I get is:
Page Failed to load
The page is linked and I can click the link and the Confluence page will open. But it doesn't show the page title in the JIRA issue.
I have the same setup on a staging system where it works. I have not found any difference so far. Both systems access the same LDAP server fpr user management.
What I have found in the access logs (of the reverse proxy) is the following difference.
Working staging system:
"POST /rpc/xmlrpc?xoauth_requestor_id=u.ser HTTP/1.1" 200 625 "-" "Apache-HttpClient/4.4.1 (Java/1.8.0_151)"
Non-working live system:
"POST /rpc/xmlrpc?xoauth_requestor_id=u.ser HTTP/1.1" 403 928 "-" "Apache-HttpClient/4.4.1 (Java/1.8.0_151)"
While researching another problem and trying out the way of an unproxied connector, I found a message in the application logs about "Confluence remote API disabled." Which was actually a difference between the staging and production system. It was disabled on the production system (to prevent outside access to it).
After turning on the Confluence remote API in Confluence the link is working and the page title shows up as expected in the JIRA issue link.
The HTTP 403 response means authorisation failed. Can you check if Confluence port is correct in URL, connections are enabled both ways and application link is showing Connected in JIRA?
I checked the trouble shooting guides and found an article on creating an unproxied application link. I would like to try that as both Confluence and JIRA live on the same server instance.
The article says that I must be able to browse to the unproxied URL. Do you know if this is only true to set up the application link or is that true in general, also for later usage. Of course normal users should not be able to browse the unproxied non-SSL address.
It's needed while creating the application link because your browser needs to be able to access both unproxied URL's. After that it shouldn't be needed anymore (going by the docs, I haven't tried this myself). You can either do it directly from the server itself or make an allowance to your machine only while setting it up. Afterwards test the linked functionalities to make sure we're not going down the wrong path by using this method. If everything works, then you can block all external access to the unproxied addresses and everything should still work well.
Not for the ones created by the application links. I can only hide them, which I did. But the application navigator in general behaves in an unpredictable way, adding and removing entries as it sees fit. I have it in a state I want it now and will simply keep it that way.
Thank you for your help.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hi Community! Kesha (kay-sha) from the Confluence marketing team here! Can you share stories with us on how your non-technical (think Marketing, Sales, HR, legal, etc.) teams are using Confluen...
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!
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