I wanted to share a hacky workaround that we use and which just broke and how we found another hacky solution for it and suggest what would be a better solution to the problem.
We need to detect what other apps by other vendors are installed on the same Jira Cloud site as then we can present additional options to users for configuring integration with these other apps.
Previously we created a solution that does an anonymous request to a known app URL (e.g. getting started or configuration page of the app) SITE_URL/plugins/servlet/ac/{appKey}/{path} and checking the response code:
if it is 403, then it means that the app is installed but the access is unauthorized
if it is 404, then it means that the app is not installed (or they have changed the page URL…)
We just found out that in recent days all these requests started to return OK status code 200 and just in the browser page you got an error message. We did the investigation and found that in the response body there is JavaScript code which initializes
window.SPA_STATE={...};
and there is "CONNECT_GENERAL" key with statusCode subkey where we see either 403 or 404. So now we try to match the response body with a regular expression /window\.SPA_STATE=.*"statusCode":(\d+)/ and extract the response code and process it as described above.
This is a fragile temporary solution that we now use but I expect that it will break in the future again. Therefore it would be better to have a REST API that apps could use to detect what other apps are installed on the same Jira/Confluence site. I have discussed this with other vendors and this would be useful for many apps. Please comment if you have similar needs for your apps.
It would be good if we could request /rest/atlassian-connect/1/addons/{appKey} also with other app keys and get just minimal information to identify that they are installed. Now the app can just request it about itself.
Could someone from Atlassian provide feedback for this request and if this could be included in the development backlog?
A REST API of this sort would also be very useful to me. I would most like to get a list of or seach for installed apps. Even just the keys would be sufficient, especially if combined with your proposal of allowing apps to inspect other apps via the endpoint.
Should customer consent be required for this? This is some sort of customer data after all.
From vendor perspective, this will give huge advantage to vendors, who own popular apps.
If abuse of the information of other installed apps is a concern then probably a new scope could be introduced. Similar to ACCESS_EMAIL_ADDRESSES where you need to apply for it and describe the need and then it is granted.
But as the basic information about other installed apps is not personal data then probably it could be just described in the API documentation how the data can be used and what is not allowed (e.g. you cannot advertise a competitor app if you identify that a different competitor app is installed).
In sever products it is possible to detect what other apps are installed. Therefore it would be good to provide the same capability in the cloud as well.
Apps would be isolated in any case and they cannot fetch data from other apps (if they are not stored outside of Jira / Confluence entity properties). And as I described in my post it is already possible to detect what other apps are installed, so it will not be possible to prevent that. My suggestion is to make this easier and less brittle.
But it would be good to hear from Atlassian what they think about this suggestion and if they see any issues with providing such API.
This is an interesting topic and I can see how functionality such as this may be beneficial to various apps. I also like how you have balanced the conversation with considerations for the impact on customer privacy.
I’ve created [AC-2530] - Ecosystem Jira. In the description of the issue, I noted that we need to work out exactly what is required. It feels a lot like introspection of the tenant - apps need to understand what other apps have implemented certain functionality.
We just identified that our workaround is not working anymore. Now statusCode in CONNECT_GENERAL is always 401 (both for installed and not-installed app general pages).
As a new workaround we have identified that any SITE_URL/plugins/servlet/ac/{appKey}/{path} page contains the ajs-licensed-products meta tag with a list of all licensed Atlassian productions and apps, for example:
We can use this information to identify which other apps are installed. But this list only includes apps with a real valid Marketplace license. If the app has a private listing token then it is not included here.
But it would be much better if [AC-2530] - Ecosystem Jira would be implemented and provide a stable REST API how we could identify which other apps are installed on a selected instance. As we see this information is already shown in different ways but unfortunately these “hacky” workarounds break all the time. Please vote and/or comment on this issue if you have a similar need for such API.
Thanks for the re-share. I agree that it would be much better to have a supported API to work against. I’ll raise this again internally to see if it can be prioritised.
In terms of use cases, I assume the bare minimum is a REST API that returns the keys of currently installed and enabled apps. This assumes that the app using the API would have some first hand knowledge about the apps it forms a dependency on. A higher level API might introduce abstractions about capabilities implemented by other apps, but that would require a lot more effort.
We have a similar use case but would like to have a way to figure out if our own app is installed in a Jira instance via the Jira REST API and OAuth2 (3LO). Like others, we are currently using a hack to get that information. Unfortunately, it seems to fall apart now too: How to interpret 400, 403 and 404 errors returned by POST /rest/api/2/search?
