401 - Unauthorized on all Jira end points since upgrading to @forge/cli 9.1.1

Forge Forge UI Kit and Custom UI
, , ,
1

Hi,

I’ve upgraded to Forge 9.1.1 this week to plan an update of my Forge application on the Atlassian Marketplace.

My Forge app is a Custom-UI bridge app. It references @forge/api and @forge/resolver. I made sure these packages were up to date in my package.json file.

I noticed a change in the manifest.yml file where I now have to add the runtime. So I did that based on the documentation provided by Atlassian. I made sure my Custom UI app was built on a v18 of NodeJs.

app:
  runtime:
    name: nodejs18.x

After the series of forge install, forge deploy -e development, forge install --update, I got a 401 - Unauthorized on every Jira REST API call that my app does. I tried even the most basic calls like /rest/api/3/myself and used asApp and asUser. I’m always getting a 401 - Unauthorized. I do follow on the Jira request API is proposed

Scopes have not changed since my last update months ago. I’ve checked, double-checked, and triple-checked that my scopes were reflecting the REST API endpoints documentation.

I’ve uninstalled the app with forge uninstall and reinstalled it. I still get 401 - Unauthorized for every call the app does on any Jira REST API endpoint.

I’ve logged out of my Jira account. I’ve updated my browser. I’ve cleared my cache. I’ve run forge lint and forge lint --fix. These commands tell me the scopes in manifest.yml are ok. I’ve moved the scopes section around in the manifest.yml file.

I’m out of ideas to fix my problem.

I’ve even removed the scopes from the file, and ran a forge lint, and I got no error. So this might indicate that the issue is in the Forge CLI and its deploy mechanism.

Reading the forge channel on Atlassian’s Slack, there seems to be some issues lately with @forge/storage. Maybe I’m getting a side effect from this.

Does anyone have an idea of what my issue is? I’m not so far behind on the Forge CLI updates. I was using version 7 in March and things worked well.

Any help is welcome,

Louis-Philippe

1 Like
2

I also updated forge cli to 9.1.1, I am not able even to run forge tunnel it fails with the error Error: Failed to connect to localhost:3000. Check that your service is running.…

1 Like
3

We also started having problems creating new Forge custom ui apps. Any app that was created before last Wednesday (5/15/24) can make asUser API requests without issue. If we deploy the exact same code with an App ID generated on Wednesday or later, all asUser requests get 403 errors.

I’ve literally taken my code and simply switched the app ID in the manifest and redeployed. The only difference between a working app and a non-working app is the app id. Looking in the developer console, all app settings look identical.

The versions of cli or libraries we are using doesn’t seem to matter.

1 Like
4

Hi there, are you able to share some sample code for your API call and an appId?

By the way, we have noticed that in the sandbox runtime, the route tagged template is lenient towards extra white spaces, so you could get away with something like

api.asApp().requestJira(route` /rest/api/3/issue`)

If you do this in the Node runtime, you will end up with a 401 error. Removing the whitespace here would fix the problem if this is what’s happening.

5

Hi @BoZhang ,

In regards to having white space in route, I’ve checked and double-checked. There are no white spaces in my Jira REST API end points.

I’m a bit uncomfortable sharing my appid here for security reasons. Am I correct to assume this?

I just upgraded to @forge/cli 9.2.0 released on Monday May 20 2024. I still have the same 401 issue when I call the sample code below.

I don’t have a sample app but this call in index.js of a basic Forge app returns a 401 with Forge 9.1.1.

import Resolver from '@forge/resolver';
import api, { route } from "@forge/api";

const resolver = new Resolver();

resolver.define('getSystemUserId', async (req) => {


    const response = await api
        .asUser()
        .requestJira(
            route(`/rest/api/3/myself`), {
            headers: {
                accept: "application/json",
                "content-type": "application/json",
            }
        });

    if (response.ok === false) {
        return "Invalid connection";
    }
    else {
        return (await response.json()).accountId;
    }
})
1 Like
6

Thanks, @LouisPhilippeCarigna, for the update. It seems like route is being used as a function here; it must be used as a tagged template literal docs. The problem is that using it as a function in the Node runtime will return an empty string, so your request is being made with an empty path. We will look at adding some linting for this.

1 Like
7

Hello,

I’ve been deploying the exact same code with different app ids. Only the AppId I created early last week works.

Good AppId:

fd573047-c77a-4817-a948-f184dd1227b5

A Bad AppId:

787f16eb-85b5-40b4-8a10-838031e816d7

The request that is failing (this is the first request we make when our app loads):

async getAllUserWorkspaces() {
const workspaces: AtlassianUserWorkspace[] = [];
let fetchingWorkspaces = true;
const limit = 50;
let start = 0;

while (fetchingWorkspaces) {
const workspaceResponse = await this.fetch<AtlassianPaginatedWorkspace>({
url: *route*`rest/servicedeskapi/assets/workspace?start=${start}&limit=${limit}`,
method: 'GET',
});
workspaces.push(...workspaceResponse.values);
start += limit;
if (workspaceResponse.isLastPage) {
fetchingWorkspaces = false;
}
}

return workspaces;
}
8

@BoZhang your solution solved my issue.

I removed the () after route and I didn’t get any 401 error messages. I was able to do my calls to Jira’s endpoints.

To be honest, I had the () after route for at least 18 months with customers using my app without any issues.

So, this worked with previous versions of Forge up until 9.1.1

api.asApp().requestJira(route( /rest/api/3/issue))`

As of Forge 9.2, this works (notice the space after the route).

api.asApp().requestJira(route /rest/api/3/issue)

The Forge linter never warned me about the () after route. On Forge 9.2, it doesn’t warn me about the extra space between route and /rest/api/3/issue.

2 Likes
9

@ChrisHardin, that’s interesting, did you notice any errors when you installed this app into your instance? are you able to uninstall, install it and invoke your bad app again? I will do some more digging as well.

10

Yup, I think this is a runtime issue, the sandbox runtime may have allowed for this to happen, but the Node runtime doesn’t have as much leniency. We will look into adding some linting for this in the future so it becomes easier to troubleshoot.

1 Like
11

No errors during installation. When I uninstall and reinstall the app, I get the same issues. I have tried many installations with many new app Ids. Result is always the same.

12

Thanks for checking, @ChrisHardin. Should we move the discussion to another thread? this issue is not related to the original issue so it might be good to split them up for posterity.
Anyhow, I had a close look at our logs this morning and saw that your bad app does not have a grant for the read: service desk-request scope, so it is getting back 403s from the endpoint that you mentioned.
Can you check that you have that scope in your manifest, redeploy the app, and then reinstall it? If that doesn’t work, I can have a closer look at this particular scope.

13

Hey @ChrisHardin, a quick update, after further investigation, I have found some issues with this scope in particular. We are looking into fixing this.

Update: we have raised an incident and are actively fixing the issue now: Atlassian Developer Status - Some JSM Scopes scopes cannot be consented to for Forge apps

Update 2: we have fixed the issue, can you please try invoking your app again?

14

@BoZhang It is working now, thank you!