Frequent AUTH_TYPE_UNAVAILABLE errors when using `api.asUser()`

Forge Forge Modules and Product Triggers
,
1

In our Forge application, it’s important for us to know who the current user is that’s interacting with the application. For this, we regularly make a call to:

await api.asUser().requestJira(route`/rest/api/3/myself`, {
  headers: {
    'Content-Type': 'application/json',
    Accept: 'application/json',
  }
});

Most of the time this call works fine, however, around 30% of the time it fails with:

ERROR   11:57:49.164  becc05ad-59dc-4656-a75c-b5525ccb5164  UnhandledPromiseRejection with reason: Forge platform failed to process runtime HTTP request - 401 - AUTH_TYPE_UNAVAILABLE
ERROR   11:57:49.189  becc05ad-59dc-4656-a75c-b5525ccb5164  PROXY_ERR: Forge platform failed to process runtime HTTP request - 401 - AUTH_TYPE_UNAVAILABLE
    at handleProxyResponseErrors (webpack://jira-label-suggestions/node_modules/@forge/api/out/api/fetch.js:84:1)
    at <anonymous> (webpack://jira-label-suggestions/node_modules/@forge/api/out/api/fetch.js:29:1)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
  status: 401,
  errorCode: 'AUTH_TYPE_UNAVAILABLE'
}

Simply re-trying the same call again will usually work. However this flakiness and instability is really frustrating to work around. Any advice on what we could try to deal with this challenge?

2

Hi @ZenhubDev,

The AUTH_TYPE_UNAVAILABLE error is thrown when asUser is called and there is no user involved with the invocation. For example: calling asUser in a product event or async event will cause this error to be thrown.

I can look into this a bit more further if you able to provide us with the modules that you are running into issues with and also your appId so we can match it to logs.

1 Like
3

@ZenhubDev
Which module are you using? Is it possible that an ‘Anonymous user’ is accessing your functionality, which is why there is no specific user context?

4

Hey, thanks for the response.

The most common place where it seems to happen consistently is on the avi:forge:installed:app event. My hope was that we could use asUser() to help us know which user it was that installed our app, but I guess you’re saying that this won’t work? Is there another way to know who installed the app?

5

Hi, thanks for explaining your use case.

For product events, you will have access to asApp which is similar to asUser but allows you to make authenticated API calls on behalf of your app instead of the user, you can use this to query for the user who created the app (replace the current asUser call to query for user info with asApp).

1 Like
6

Using asApp doesn’t return what I expect. It returns a different accountId and accountType than I’m expecting. I’m want to know which user installed the app, but the data coming back doesn’t match that.

Normally if I make the call asUser, I get data like this:

accountId: '712020:cb4b054a-ecf8-4add-ae26-8716e6e7156b',
accountType: 'atlassian',
emailAddress: 'ev@zenhub.com',

But if I use asApp(), I get this data:

accountId: '712020:ab27bf09-c9e0-4f51-a1ba-e6d8f801a6be',
accountType: 'app',
emailAddress: 'a6419872-e254-413e-a528-1e8ac02e9516@connect.atlassian.com',
7

Hi @ZenhubDev, you will need to pass the accountId of the user that installed the app into the API call, for instance if your app is installed into Jira, then you would need to call this API and include the accountId query parameter. If the accountId is not provided then the API will return the user associated with the call, which would be the app user in this case.
The accountId of the user who installed your app should be available in the payload of the installation event.

2 Likes
8

Thank you BoZhang. That makes sense. We’ll use that!