"write:folder:confluence" permission scope sometimes triggers user consent

Forge
, , , ,
1

I have a Space Page app that I’ve recently updated with the ability to create Folders in the space, and for that I’ve added both the write:folder:confluence and the read:folder:confluence (to display a tree hierarchy preview) scopes.

After this update, the following notice started appearing below the app’s UI, alongside an “Authorize” button:

For MY_APP to display, you need to allow the app to access Atlassian products on your behalf.

A couple of things to note:

  • When my page initializes it asynchronously pulls from both Confluence’s Pages API (specifically /wiki/api/v2/spaces/{spaceId}/pages) and from GitLab’s API to populate two different Select components on a Form. Sometimes it would be GitLab’s Select that is stuck on loading, sometimes it was the Pages’ Select and on other times it was both.
    The authorization notice doesn’t always appear either, at times it took 5 refreshes to show and at others it appeared with every invocation of a backend function.

  • The resolver functions do run, they just don’t return the requested value(s) to the frontend.

  • Even after pressing the button and authorizing the app, it doesn’t “remember” my authorization and might trigger the consent request again on the next backend invocation. I believe that it’s possible that it remembers one authorization per backend function, but I can’t say for sure.

  • The details on this post were observed both on the Production environment and the Development one.

This is the permissions section of my manifest:

permissions:
  scopes:
    - read:confluence-content.summary # Content Descendants API
    - read:page:confluence 
    - read:content.metadata:confluence # Ancestors API
    - read:folder:confluence
    - write:page:confluence
    - write:folder:confluence
    - storage:app
  external:
    fetch:
      backend:
        - https://gitlab.com/*

From my tests:

  • Deploying it without either folder scopes: No issues
  • Deploying it with just read:folder:confluence scope: No issues
  • Deploying it with just write:folder:confluence scope: Issue observed
  • Deploying it with both folder scopes: Issue observed

As I’ve mentioned, there were times when this issue appeared and times when it didn’t, so it’s possible that the read:folder one might have been a false negative (I’m certain that the neither scopes one is not, considering it worked fine before adding these scopes).