9 November 2015

We've deprecated this Diagnostics Plugin guide, because the Diagnostics Plugin has been removed from the Atlassian Marketplace and is no longer being actively developed.

But there's good news! We've released a whole better diagnostics experience for application links. You get the new application links diagnostics with the recent version of Atlassian products.

Some teasers...

Built-in

The new diagnostics experience is built in to the Application Links plugin, so is available right out of the box.
You don't have to install or maintain a separate plugin.

Full product support

The new diagnostics experience supports all Atlassian products that use application links, including Jira 7 and Bamboo
(neither of which are supported by the old Diagnostics Plugin).

If you're having trouble with application links, see our Application Links troubleshooting guide.

 

 

Overview

This test verifies if the remote manifest is valid. For example, if you are creating an application link from JIRA to Confluence, it will check whether the manifest on Confluence is valid. This is done by accessing that instance on the URL paths tested below, and then verifying that manifest retrieved is not malformed and is what it is supposed to be.

This manifest is used to generate application links between different apps. If this is not valid, those application links will fail.

Understanding the Results

IconText resultWhat this means
SUCCESSThe test was successful.
WARNINGSome of the component tests failed and needs troubleshooting.
FAILThe test was not successful and needs troubleshooting.

Troubleshooting

Basic Checks

Error(s)Steps to Resolve
  • Application Link is NULL
  • The Application Link has been corrupted, please recreate it.
  • Application URL is NULL
  • This means the application URL is empty. Try to edit the link and see if this can be fixed.
  • This shouldn't happen, the Application Link will probably need to be recreated.

Remote Manifest Test

  • URL path tested: <URL>/rest/applinks/1.0/manifest & Application URL.
Error(s)Steps to Resolve
  • Oops the Application URL '<URL>' is invalid
  • Is the URL valid?
  • Can you access it with a browser?
  • Is there anything between the applications, for example proxy / firewall and so on.
  • Oh dear, we're unable to retrieve the configuration from '<URL>'
  • Are you able to retrieve the manifest manually?
  • You know this should be impossible but the local Application Link ID <ID> does not match <Application>' ID <ID>
  • Delete the application link and create again.
  • This might be important! The local Application allows <Manifest Name>'s impersonating access while it allows public sign on.
  • On the remote (target) instance, disable Public Signup.
  • Reconfigure the link to use a non-impersonating authentication scheme for incoming requests, such as OAuth without Two Legged with Impersonation (2LOi) permission.
  • See section Public Sign Up and Privilege Escalation below for more details.

Additional Information

Public Sign Up and Privilege Escalation

It is a potential risk to use impersonating authentication schemes such as Trusted Apps or Two Legged Impersonation OAuth for incoming requests from an instance that allows public sign up.

Impersonating authentication schemes pass the current username from the originating instance to the remote instance across the application link. The username is then used to automatically log in to the local instance user account that shares the same username. The request actions are then completed using the permissions associated with this local user account.

The risk arises if, for example, username 'wendy' on the local instance represents an administrator. If the username 'wendy' is not already used on the remote instance and if the remote instance allows public sign up, anyone can create a new account on that instance with username 'wendy'. Although they may be restricted to creating an account with limited permissions on the remote instance, when they make requests to the local instance across the application link they will gain administrator rights on the local instance, due to the shared username. This is referred to as privilege escalation.

 

Providing Information to Support

Atlassian applications allow the use of reverse-proxies within our products, however Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian can not guarantee providing any support for them.

If assistance with configuration is required, please raise a question on Atlassian Community.

In case you are unable to troubleshoot and fix the problem by yourself, please create a support ticket at support.atlassian.com and attach the following information to the ticket:

  1. Copy and save the contents of the 'Diagnostics' tab as a text file.

  2. Screenshots of the Application Links configuration.

  3. A Support ZIP.

Unknown macro: {dynamiccontentbylabel}

 




 

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.