Access to the resource was denied due to missing scope grants

I am working on a confluence macro that reads a Jira issue.

"errorMessages":[
"Access to the resource was denied due to missing scope grants. Your app was granted the following scopes: [].\nThe resource can be accessed by having one of these groups of scopes:\n * [read:jira-work]\n * [read:issue-meta:jira, read:issue-security-level:jira, read:issue.vote:jira, read:issue.changelog:jira, read:avatar:jira, read:issue:jira, read:status:jira, read:user:jira, read:field-configuration:jira]\n",

Manifest.yml

permissions:
  scopes:
    - read:jira-work
    - read:issue:jira-software
    - read:page:confluence
    - write:page:confluence

The app was installed on Confluence and Jira.

I don’t understand why the scope is empty (per error message) even though the manifest lists a couple of scopes. When I switch from asUser to asApp it works.

1 Like

HI @Meinhard ! I’m running into the same issue. Were you able to find a solution?

@ibuchanan I saw you had popped up in a few other threads with similar issues. Any chance you know of any changes that might cause this? I encountered the problem when I deployed my app to production. Since then have tried adjusting scopes, reinstalling, even tried under a new app id. Upon reinstall, even my dev environment which was working, now doesn’t. It seems to be choking when I try the following,

await api.asUser()?.requestJira(route`/rest/api/3/myself?expand=groups,applicationRoles`, {
            headers: {
                'Accept': 'application/json'
            }
        })

this returns

{
"headers": {},
"ok": false,
"status": 403,
"statusText": "Forbidden"
}
data: {
"errorMessages": [
"Access to the resource was denied due to missing scope grants. Your app was granted the following scopes: [].\nThe resource can be accessed by having one of these groups of scopes:\n * [read:jira-user]\n * [read:application-role:jira, read:group:jira, read:user:jira, read:avatar:jira]\n"
]
}`)

My manifest includes (admittedly with some shot-in-the-dark scopes),

    - write:jira-work
    - manage:jira-configuration
    - manage:jira-project
    - read:application-role:jira
    - read:avatar:jira
    - read:confluence-content.all
    - read:confluence-content.summary
    - read:confluence-space.summary
    - read:content.metadata:confluence
    - read:field-configuration:jira
    - read:group:jira
    - read:issue-meta:jira
    - read:issue-security-level:jira
    - read:issue.changelog:jira
    - read:issue.vote:jira
    - read:issue:jira
    - read:jira-user
    - read:page:confluence
    - read:status:jira
    - read:user:jira
    - read:user.columns:jira
    - read:user.property:jira
    - read:user-configuration:jira
    - write:confluence-content
    - write:confluence-file
    - write:confluence-props
    - write:confluence-space
    - write:issue.property:jira
    - write:issue:jira
    - read:me
    - read:confluence-user
    - read:jira-work
    - read:account```

ALSO, the MacroConfig panel for production is now displaying a “Failed to Load” error.

Failed to load
For this app to display, you need to press the Allow Access button in the macro to allow the app to access Atlassian products on your behalf.

but now having a heck of a time getting it to prompt for Allow Access again, even removing and readding read:account. My dev environment MacroConfig does not prompt the same message and allows for config.

(UPDATE: Removing dev environment install allowed for MacroConfig, but still unable to make asUser /rest/api/3/myself call)

@DavidPezet1,

I assume you are familiar with the limitations around cross-product apps? I think the caveats are best expressed in the blog that explains how to build one:

  1. Cross product apps must be installed in all of the products they interact with. The app we’ll create in this tutorial needs to be installed in Jira and Confluence tenants that belong to the same site.
  2. Cross product apps are not supported by Atlassian Marketplace. This limitation is due to the need to install in multiple products. If you intend to commercialize your multi-product app, see the workaround listed here.

With those, can you explain you elaborate on your “deployment pipeline”? How are you deploying the app and performing install?

Thank @ibuchanan. This app was working fine in the Development environment until I deployed it to the Production environment, installed the app to both Jira and Confluence, and set the Distribution status to Sharing.

Afterwards, the calls from the Confluence Macro app to Jira are giving errors. The development environment is giving errors like “Access to the resource was denied due to missing scope grants. Your app was granted the following scopes: …” while the production environment is additionally giving errors like “…The app is not installed on this instance…”, even though it definitely is on latest for both Confluence and Jira.

I thought that maybe something got screwy with the app, so I created a new app and deployed it under the new ID with the same results. So I thought maybe it was something with the “Allow Access” Consents, so I’ve tried removing access to the app from Atlassian account to get this to prompt again. Even after this, the app does not prompt for consent again, while other internal apps do.

I also just noticed that the forge CLI is only listing a sub-set of the scopes listed in the manifest when install, like

Your app will be installed with the following scopes:
- read:field.default-value:jira
- read:field.option:jira
- read:field:jira
- read:issue-details:jira

? Do you want to continue? Yes

Update: Also have now noticed that the other internal Confluence macro apps which have not had any deploy / install changes are also failing to communicate with Jira…

@DavidPezet1

I switched from asUser to asApp for the Jira API calls. For confluence asUser still works. I would like to understand why it doesn’t work but right now I am trying to move the other parts of the app along.

Regards,
Meinhard

Thanks for the update. Yeah, asApp works, but asUser is important for us because of the types of calls being made. I have an open support ticket, hopefully they figure something out. I’m beginning to suspect something is tangled up with the “Allow Access” User Consent, since after clearing my access permissions via Atlassian account , I’m only seeing the Confluence side get re-added, but the Jira side does not. And with the new “simplified” consent feature, I haven’t been able to find a guaranteed way to get the “Allow Access” prompt again, despite redeploys/resinstalls/scope changes. It just adds itself (but only for Confluence).

@ibuchanan

Here is a simple app with steps to reproduce incase it is something sill I’m overlooking:

  • Forge Create → UI Kit 2 (preview) → Confluence Macro
  • .\src\FRONTEND\index
//FRONTEND
import React, {useEffect, useState} from 'react';
import ForgeReconciler, {Text} from '@forge/react';
import {invoke, view} from '@forge/bridge';


const App = () => {
    const [user, setUser] = useState(null);

    useEffect(async () => {
        invoke('getCurrentUser')
            .then((currentUser) => {
                setUser(currentUser);
                return currentUser;
            });
    }, []);


    return (
        /* jshint ignore:start */
        <>
            {user && <Text>
                User: {JSON.stringify(user, null, "\t")}
            </Text>}
        </>
        /* jshint ignore:end */
    );
};

ForgeReconciler.render(
    /* jshint ignore:start */
    <React.StrictMode>
        <App/>
    </React.StrictMode>
    /* jshint ignore:end */
);
  • .\src\RESOLVERS\index
//RESOLVERS
import Resolver from '@forge/resolver';
import api, {APIResponse, route, requestJira} from '@forge/api';

const resolver = new Resolver();

resolver.define('getCurrentUser', async () => {
  let response = await api.asUser().requestJira(route`/rest/api/3/myself?expand=groups,applicationRoles`);
  console.log(`response: ${JSON.stringify(response,null, "\t")}`);
  let data = await response.json();
  console.log(`data: ${JSON.stringify(data,null, "\t")}`);
  return (data);
});

export const handler = resolver.getDefinitions();
  • .\INDEX
export { handler } from './resolvers';
  • forge deploy (development environment)
  • forge install
  • asUser returns “The app is not installed on this instance.”
  • asApp return User information.

Hope this helps.

I’ve found the Forge team have been constantly changing permission scope names with each new CLI and package version.

And then since scope changes require customers to manually update the app (which they rarely do) you end up with the majority of your apps running outdated versions and bug reports from versions you deployed two years ago. Great developer experience.

@ibuchanan I had submitted an incident report, which they converted to a bug (which I worry will get lower priority), and have not gotten any updates. This is affecting new and previously installed apps for us. From what it seems, Jira calls continue to work for Users who had previously provided user consent to apps, but new apps or users newly adding consent are unable to make asUser calls, even with apps that have not been not redeployed or updated. This is fully impacting function. Any chance you know if there is anything I can do as a correction or workaround for this type of call?

@DavidPezet1,

No. I fear this is buried pretty deep in the sense that both the OAuth implementation and Forge’s “wrapper” for the auth flows are not accessible by apps. Can you DM me the support issue number? I can have a look to see if there is any additional context I can add.

1 Like

@ibuchanan Thanks again. Just confirming my message came through. Please let me know if any additional info would be helpful.

@DavidPezet1, I confirm. Developer support is on the case. Thanks for your patience as they work to investigate the issue.

1 Like

@DavidPezet1,

Just to tie things off, it looks like this bug is a result of mismatched feature roll-out. We rolled out some changes to the Confluence side but not yet the Jira side.

For the set of app developers caught between these changes, please contact developer support with your app id. Dev support can get you added to some feature flag exceptions to suppress the problem until both roll-outs are complete. Since this is a temporary roll-out bug, there isn’t a public issue to track.

I’m also going to lock this thread since the roll-out will eventually fix it. If you aren’t building a cross-product app, there is some possibility you might get the same error, but the underlying cause is going to be different. In that case, please open a new topic for discussion.

1 Like