Forge 'Allow Access' endless-loop of death is still a thing

I tried today one of our Forge apps, on two different logins.
And the ‘Allow Access’ endless-loop of death is still a thing:

The allow Access is already a horrible user experience. But having it not work is catastrophic.
Plus is looks like the permission screen shows the wrong permissions: Forge Permission Screen Fails to Mention External Sites

8 Likes

This happens to me from time to time.

Logging out and logging back in often fixes it.

Horrible bug.

It also happens to me from time to time, and it can occur in both deployed and tunnel mode.

Once it happens I will have to stop tunnel, uninstall and reinstall my plugin to get rid of it.

1 Like

A browser hard reload helps me. Seems to be some caching issues.

1 Like

Hello Roman (and other partners/users),

Our internal development team has deployed a fix for the ‘Allow-Access’ endless-loop.

Users that were experiencing this issue will still be presented with the Allow-Access screen, however upon accepting the app should be authorised and the user should no longer see the ‘endless-loop of death’.

If the issue persists, can you please let us know.

P.S. The Forge Permission Screen Fails issue is being handled separately.

Cheers, Chris

@ChrisGraham I’m still encountering this issue. I’ve tried uninstalling and reinstalling the add-on on that instance and clearing the cache. I click allow access on both screens but when I return to the app it loads both the allow access prompt and the app. The app doesn’t load properly as all APIs appear to return 403.

3 Likes

Hello Rhys,

Thank you for the quick feedback, it’s very much appreciated.
We are investigating why the issue persists for this app/site/user combination.

1 Like

Hi all,

The fix that was deployed earlier in the week should be available in Jira Cloud from build JF-PROD-30504 onwards. There were some rollbacks after the initial deployment and I believe this is why the issue persisted.

If you could check the value of window.BUILD_KEY in your browser console then try to reproduce the issue that would be really helpful. If the build is newer than JF-PROD-30504 and the issue persists then we will need to continue our investigation.

Thanks!

Hi @JonathonGrigg ,

I have a different issue now. I updated my app that I have in development and because the scopes changed, I need to give constent again. After clicking on “Allow Access”, I get to the following screen

I have JF-PROD-30505 as build number.

Is this related?

Best
Johannes

Edit: Nevermind, seems like a caching issue. I opened the dialog in a private window and it worked smoothly.

1 Like

Hello.

So, the issue doesn’t seem to be fixed for me, on Confluence Macros. Is there a window.BUILD_KEY or some equivalent on Confluence Cloud to check if I am on a release where it should be fixed?

I’ve attached a video on how it acts for me: https://www.gamlor.info/files/allow-access-loop-of-death.webm

2 Likes

Hi @RomanStoffel, thanks for the feedback and the video!

It looks like Confluence Cloud is still using an older version of our internal Forge package from before this fix was added. I’m only familiar with the Jira side so I have asked the relevant Confluence team if there are plans to bump to the newer version and will update here when I have more information.

Thanks for your patience while we fix this issue :slight_smile:

3 Likes

Unfortunately, login/logout doesn’t work for our apps

The issue was reproduced yesterday, build key - ‘JF-PROD-30505’, our tenant is https://ttb.atlassian.net/

BTW, why this “consent link” screen appears for every user?

My expectation is (and this is what I see working with Azure Enterprise App, they have the same idea behind as Forge App)

  • as Tenant Admin I deploy/upgrade Forge App
  • as Tenant Admin I confirm consent for Forge App
  • Any logged user with sufficient privileges should be able to use App without any additional steps
1 Like

Well, yes: This consent dialog per user is disliked everywhere. And this bug which exists now for at least a year in some form or another makes it truly awful.

Afaik: The ‘Allow Access’ button for each user was planned to be removed, so I didn’t ‘scream’ about it much. Then the removal of the ‘Allow Access’ button got delayed (or cancelled? not quire sure). It is still on the roadmap: Trello.

So, anyway, that was my big suprise: The ‘Allow Access’ dialog is still here, and it is still horrible bugged.

Yep: And my hope is that it will get removed. Its just not a great user expirience.
For example, it if shows up in an Confluence Macro in edit mode, you can’t click it. You will have to do work arounds to even use it.

3 Likes

Worth noting that this seems to be a completely separate and utterly trivial UI/CSS bug from day 1 that could have long been addressed by now (see [FRGE-284] - Ecosystem Jira), but presumably got demoted because of the pending ‘Allow Access’ button removal :unamused: - just addressing that one would remove a significant onboarding hurdle (and likely churn reason).

2 Likes

Hi everyone, I appreciate we’re well overdue for an update on the user consent screen. It was almost a year ago when we announced our intention to remove it.

Our intent is still the same, we will be removing the user consent step, it has just turned out to be a bigger piece of work than it initially seemed.

The good news is we have now made the appropriate space on the roadmap my team is about to pick up this project. We know it’s a top priority, thanks for continuing to provide the feedback.

15 Likes