Hi justin.alex,
Could you create a support ticket at https://support.atlassian.com?
That way we can provide you with support specific to your circumstances and with higher security. The credentials should be the same as for this site (https://jira.atlassian.com).
This issue is too general to help everyone who has connectivity problems. The problem you currently face may or may not be related to the problem others face. When connectivity problems are not solved by working through the documentation the best approach is to create a support ticket. There are many different things that can break an application link. The most common are mentioned in the documentation.

Trouble shooting issues with 2-Legged OAuth

I believe that we need more context on the fix than just marking this issue as Done.

We have a client that employs Service Desk as their day-to-day tracker, and they couldn't get the Confluence KB feature to work for them. The link provided by amckague does provide some heads up that if there's a problem with this, we should check the Application Links section to make sure that it's configured correctly. However, JIRA and Confluence does talk together nicely in the set-up (issue in JIRA are able to link to Confluence pages, and Confluence pages can search for JIRA issues).

However, despite going through the 2 legged authentication document and configuring these around, we are still stuck in allowing Service Desk to grab Confluence KBs. SSL could not have been the problem, as from what I can recall, if there's a problem with SSL, JIRA and Confluence should not be able to communicate directly via AppLinks.

Hi there,

We have JIRA 6.2.4 with Service Desk 1.2.6.1 and Confluence 5.4.4 and we're also experiencing this issue from time to time, recreating the Application link between JIRA and Confluence fixes the issue but after some time it recurs.

We have Trusted Applications enabled and also 2-legged OAuth with Impersonation.

Regards,
Antonio

The documentation for Service Desk knowledge bas has been updated recently. Take a look at the trouble shooting section.

https://confluence.atlassian.com/display/SERVICEDESK/Providing+self-help+resources+for+your+customers+with+a+knowledge+base#Providingself-helpresourcesforyourcustomerswithaknowledgebase-Troubleshootingissueswith2-LeggedOAuth

Applinks are not the most intuitive things to configure but that link should help in setting them up. Applinks hide the fact that the two servers involved, JIRA and Confluence in this case, actually maintain separate applink configuration. For Service Desk knowledge base to work both the JIRA and Confluence applink configurations have to match. The outgoing authentication configuration of the JIRA applink needs to match the incoming authentication configuration in Confluence and vice versa. The applink configuration in JIRA can easily be mismatched with the applink configuration in Confluence. Often this configuration mismatch is an accident or misunderstanding of how the different configuration options work together but in some cases the mismatch can be the result of a failure during setup that leaves behind a partailly configured but broken applink. In all cases the mismatch will produce the kinds of errors seen in the issue.

There is no direct feedback between the two servers that when they have conflicting configuration information the requests each server makes just start failing. This can be fixed by carefully editing the configuration on both the JIRA and the Confluence servers.

Any news on when this is going to be fixed. We are still languishing with version 1.1.6 with no sign that we will ever be able to take advantages of the new features added to the product as it has matured. This is acting as a real road block for my organisation to really taking advantage of our investment in a JSD license. Nearly 7 months now and counting.

Hi Ruchi, about this :
PS: The bug is more likely to occur in an environment with reverse proxy and SSL. It is not reproducible in an environment where applications are accessed directly using ip address and http url.
=> we have the problem on two totally separated environments as I said before, one of which doesn't have a reverse proxy, but uses SSL too.
(direct usage of standalone jira & confluence on two distinct servers, with SSL option, but with well generated certificates)

I'd really investigate towards SSL problems, but these do not appear in the logs, and the application links works well for standard JIRA & Confluence interactions.

Hi Ruchi,

Thanks for your help.
We had the problem on our test instances too (not only on the target environment)
So I updated the test env to JIRA 6.2.7 & Confluence 5.5.3 (both latest now)
The problem persists.

I've tried deleting & recreating the application links, changing the type to trusted / oauth (with and without 2 legged oauth option), and basic. They all give problems (different problems with trusted & oauth at least).

Both our servers use the same Crowd server, so usernames are indeed identical. Please note, both are in HTTPS.

Regards
Vincent

I just tried to reproduce this issue with JIRA 6.2.7 and Confluence 5.4.4 and Service Desk 1.2.6.1 and I am not able to reproduce this issue on my side. I tried Trusted auth as well as Basic auth.

service desk plugin 1.2.0.2
Confluence 5.5.2
Jira 6.1.6

Right now my "Normal" user is an administrator of our Service Desk and Confluence

The problem I encountered was resolved by using a different login. My organization provided me with two logins an "admin" login with permission to do pretty much anything and an normal user login. We changed my normal user login to by an admin of the service desk project and I was able to connect the confluence page to the knowledge base.