Calling gateway API endpoints from Forge apps

Forge
,
1

Hi, I am trying to call https://site.atlassian.net/gateway/api/… endpoints, which while undocumented, are available and will respond to authenticated user sessions if you access direct URLs via browser, or pass valid Authorization header in direct HTTP requests.

I am hoping to achieve this via Jira Issue Panel and/or Issue Context modules.

As these are not product apis explicitly, the api.asApp/asUser fetch functions are not applicable, as there are no available scopes (all scopes attempted return “401: Unauthorized; scope does not match”)

Is there a way to do a similar asApp() or asUser() type of fetch to these endpoints on the current site instance, passing the current app context or user’s auth in the request?

I am trying to avoid having a Jira admin explicitly save an API key for the app to function.
The goal here is to replicate the Jira Automation issue context pane, with some enhanced functionality.

Thanks

2

Hi @CaelMetcalfe

There’s no supported way to do this, sorry.

Specifically what endpoints are you trying to access? I would love to be able to relay your feedback & use case about the APIs you are trying to access to the relevant team.

Joe.

3

Hi @HeyJoe , thanks for the response.

The endpoint for the Automation issue context, that calls the Automation Audit log for example: https://{site}.atlassian.net/gateway/api/automation/internal-api/jira/{cloudId}/pro/rest/{projectId}/macros/{issueKey}/audit-items

Like I said, not a documented endpoint, but still responds to direct authorized requests (cookie or header based) - and I would argue it is not unheard of that ‘undocumented’ endpoints are used on a regular basis (even mentioned in some Atlassian docs, egs: How to update board administrators through REST API | Jira | Atlassian Documentation and https://community.atlassian.com/t5/Jira-articles/Automate-online-site-backups-for-Jira-and-Confluence-without/ba-p/1271317) and I can only imagine that most tinkerers have leveraged these ‘undocumented’ endpoints, monitoring the HTTP requests made by the browser through the UI, to implement the same in external scripts for various reasons.

In the meantime I have added an adminPage module to capture API creds in secure storage and using fetch to external *.atlassian.net.
Obviously I cannot hard code the site name in to the egress due to moving this app from development to other sites, but it would be really nice if there was a way to define a fetch egress to the current site so as to avoid losing eligibility for Runs on Atlassian – thoughts?

Anyway, I got it working…

4

@CaelMetcalfe - Thanks for the update. Yes, there is precedent all through Atlassian’s history of users and developers finding undocumented API endpoints and using them. :slight_smile:

I have captured your suggestion to have apps automatically be authorised to make fetch calls back to the currently-installed Atlassian site on our internal product board. However, our first preference would be to have 1st class support for an API like this (eg. using API helpers like requestJira) so that apps do not have to handle and manage API tokens themselves.

Also while I do appreciate that you literally have no alternative at the moment, I should call out that Atlassian’s official policy is that we do not recommend Marketplace apps capture personal access tokens to drive app functionality unless written approval is obtained from Atlassian first (see https://developer.atlassian.com/platform/marketplace/security-requirements/).

5

@HeyJoe Thanks for capturing and I agree, 1st class support would be preferred.
Appreciate the direction to the policy, all that to be explored, for now it is for internal use, but certainly will notify and request a waiver citing this thread should that be on the cards.

Cheers

1 Like