We’re building an Atlasssian Connect extension so that our product could be integrated into the Jira UI. We already have a working “stand-alone” integration.
We were able to follow the documentation and install a mock/development add-on that uses the standard Atlasssian Connect JWT authentication to access the API of our Jira cloud instance. Unfortunately some endpoints return 403.
/rest/api/2/myself --> 200 OK
/rest/greenhopper/1.0/rapidviews/list --> 403 Forbidden
It appears that the /rest/greenhopper/1.0/* endpoints cannot be accessed, while others can. Are there some additional configurations that are needed to access the private APIs? Would the OAuth authentication work better?
If you didn’t gather from the links provided by @vkrupach, there’s already a public equivalent to the rapidviews/list as agile/boards.
Furthermore, there is an Atlassian controlled whitelist for JIRA REST API endpoints available to Connect Add-ons; hence, you may find some REST API endpoints available to Basic or OAuth 1.0, that are not available to a Connect add-on. Like you’ve done in your question, it’s best to deal with those on a case-by-case basis.
The situation you are in is not unique, we also found the whitelist of endpoints too restrictive for some activities. In the end we added a who section for the configuration of ‘the workaround user’ where customers type in addition user/password credentials that are used in Non-JWT signed interactions with the server.
The ‘workaround user’ can then be allocated JIRA global user permissions enabling Browse Users ([AC-1014] - Ecosystem Jira) for connect addons. Having a sideways REST channel is mandatory for full operation of our addon.
Yes, having another user/password is not ideal, that your customers have to consider as well as the AddonUser, but currently you have no choice if you need non-whitelist API’s.