Link Confluence knowledge base to JIRA - Problem Completing Current Request

[Kathryn Buckley]

We have Confluence and JIRA setup running on the same hosted server and they run on the same domain under different subdomains.  We use NGINX to proxy the requests.

We have followed this link to setup Application Links between the two applications:

https://confluence.atlassian.com/kb/how-to-create-an-unproxied-application-link-719095740.html

Both Application Links indicate that they are connected.

Our current issue is when we go to link a Service Desk project in JIRA to a Knowledge Base space in Confluence we get a vague error indicating that there was a problem completing the request.  Does anyone know how to resolve this? Here is a screen shot:

[Andrew Heinzer · Accepted solution]

When I have seen this error in the past, it tends to be that the user account does not have permissions to list all the spaces in Confluence.   Depending on how your application link is configured will determine how to check which user account is in question here.

If you're using OAuth with Impersonation:
Then the username/password between Jira and Confluence will be the same and in that case you just need to make sure that your account has permissions in Confluence to list all the spaces there. 

But if you're using just OAuth for the application link:
Then you don't necessarily have to use the same username in Jira as you use in Confluence to link these.  That makes it a but more difficult to be sure of the user account in question here, but the problem is likely the same.

If that doesn't resolve this, then I would recommend recreating this problem once more, then immediately go to your $JIRAHOME/log/atlassian-jira.log file.  This file should tell us more about the specific error and reason why you cannot select a space in Confluence to create this kind of link.

[Kathryn Buckley]

This solution worked, thanks a lot Andrew!

[Eric Salonen]

Applink request has returned an error with status code 401: {"message":"Client must be authenticated to access this resource.","status-code":401}

This is what I get in the logs when this prompt is shown in JSD for linking a knowledge base.

We are using Oauth - and the instances do not have the same userbase.

I am logged as admin in JSD and cfadmin is the corresponding Confluence admin user.

Any ideas @Andrew Heinzer?

[Andrew Heinzer]

Hi Eric,

Since you're seeing that error message it tends to indicate that Confluence needs to authorize the user to see that content.   It might be possible to setup this integration when using different users bases between products, but personally I have not had much success doing that.   I've only been able to get this to work correctly when using oauth with impersonation, which implies both applications have the same user accounts.

That said, you might still be able to get this to work, but if you don't need those KB articles to be restricted to a certain subset of users, I'd recommend that you change the space permissions to make the entire space in Confluence viewable to all users.   I'd recommend the official documentation in Serving customers with a knowledge base.   But in addition to that, I found there is another helpful KB when using this feature with unlicensed JSD customers: Guide to link Knowledge Base to JIRA Service Desk for unlicensed user

[Eric Salonen]

Thanks for the quick reply mate. You were absolutely correct.

For some weird reason settinp up the knowledge base can not be completed with only using OAuth and using a separate user base for the applications.

For example the problem occured when I setup the link using Oauth.

Then I deleted everything and tried again but this time I clicked "Applications have the same set of users" thus using Oauth with impersonation - but I did not create a user called "jiraadmin" into Confluence as I was creating the link from JIRA side.

Result? Same problem (didnt check the logs but same UI error).

But then as soon as I went into Confluence and created the user "jiraadmin" (the user I am logged into JIRA) and tried the to create the knowledge base link - boom, worked.

Thus it really does seem you cant setup the link with Oauth.

[Eric Salonen]

So I guess I am now wondering, now that the link is created, can I go and change the authentication back to Oauth and then everything still working fine?

[Eric Salonen]

I tested - as soon as I change the authentication back to Oauth the link does not search and find the articles.

This is stupid - whats the point of having Oauth if you cant utilise it in anyway? @Andrew Heinzer

[Eric Salonen]

Sorry for spam Andrew but Im just baffled - does this then mean that I have to enable the Anonymous access on Confluence side in order for it to work?

If its anonymous then what is the point of Oauth "authentication"?

[Andrew Heinzer]

Hi Eric,

This feature was originally developed for the Atlassian Cloud platform.  In that platform you don't need to create an application link, AND there is a presumption that both applications will have the same user accounts.   We can't always make that presumption in the Server platform of these same products.

This particular integration feature can be used in a couple of different specific ways, from serving knowledgebase content for users, to letting your users create their own content.

Tell me more about your setup.   Is the KB content only supposed to be visible to specific users?  Are you planning to allow the Service Desk users to create their own content here?

In most cases where you don't want to grant a confluence license to these users, I would actually recommend following the previous KB I posted, Guide to link Knowledge Base to JIRA Service Desk for unlicensed user

Granted it expects you to have the same accounts in both systems, so it might not be a simple setup to get working, but I know this setup works.  Setting up anonymous access in Confluence might work, but I've seen configurations where this is not enough.  In those cases it basically boiled down to the fact that these unlicensed JSD users still have a login/password, whereas anonymous users did not.   So it's possible you might open up the confluence space to allow view rights to anonymous users and that still is not enough permissions for a unlicensed users with a login.  Because any user with a login is not the equivalent of anonymous.

Take a look at this feature request: https://jira.atlassian.com/browse/JSDSERVER-4901

There are some more detailed explanations of this feature and suggestions on how to configure your environment to make this work.

Regards,

Andy

[Eric Salonen]

Hi @Andrew Heinzer

I did some further digging into this and found out a few things.

I was able to setup the KB link after I used the legacy edit of the application link page in our Confluence instance described at https://jira.atlassian.com/browse/JSDSERVER-4151 to setup the Execute As parameter in the incoming authentication page in Confluence.

After setting this parameter to a reader user in Confluence the KB linking in the JSD project started working. I am referring to this parameter

?legacyEdit=true

which is added to the end of the URL of the Confluence application link page so that the Execute As paremeter can be set.

We have JSD and Confluence setup in a way that Confluence has a different userbase then JSD and it needs to stay that way due to security risks and analysis.

That means that we would need to utilise this same Exectue As feature for the customers that need to read KB articles because they will not have a Confluence user account.

But in this case, even though it worked for the KB linking, the customer in the portal still is requested to login to Confluence (which that user does not have) so that means the Execute As feature is not working for this operation - for some reason that I do not yet know.

Although I did find bug report https://ecosystem.atlassian.net/browse/APL-1310 which obviously is reported for JIRA and Bitbucket linking but it seems to be the same issue as I do believe the application links plugin is a cross platform plugin and is actually the same plugin

I am contacting Atlassian Support regarding the few questions I now have.

1. Why was execute as removed
2. Why is execute as not working for KB article browsing.