AGC Compatibility for Forge Apps Using Forge Remote (Migrated from Connect App)

Jira Development Jira Cloud
, ,
1

Hi there,

I am in the process of migrating my Atlassian Connect app to Forge, following the guide at How to adopt Forge from Connect. Currently, I am using Forge Remote to maintain the functionality of modules from my legacy Connect app.

I understand from the documentation that “AGC currently doesn’t support Forge Remote.” However, I would like to confirm if there is any way to make my Forge app AGC-compatible, especially considering the documentation outlines necessary steps for Connect apps, which my app did not previously handle:

My questions are:

  1. Despite Forge Remote not being directly supported in AGC, is there a way to integrate the above requirements (key server, token, CDN) into my Forge app to achieve AGC compatibility?
  2. If so, please provide detailed guidance or examples on how to accomplish this.
  3. If not, please clearly confirm that using Forge Remote is entirely incompatible with AGC and there are no workarounds.

I appreciate any assistance and clarification from the community.

Thank you

2 Likes
2

Hi @HungTran,

Thanks for your questions. Forge remote is for making calls to external systems outside of Atlassian from Forge resolvers.

When your Connect service receives the /install payload, it will be able to make calls to the AGC keyserver. If you’re running ACSB or ACE, this will happen automatically for you, and you won’t need to update your code (if you’re running the latest versions).

The Atlassian CDN and auth service will also work from your Connect service.

If you are running 100 % Forge, then you don’t need to use the Connect URLs for keys, impersonation or JavaScript. Forge doesn’t need them as it uses OAuth2 not jwt, has user impersonation built in with asUser() calls and you will be using either UI Kit or React for the front end, not all.js.

I hope this helps.

Regards,
James.

1 Like
3

Hi @jrichards
Thanks for your explanation.
So if our app uses Forge remote to point to Connect app url, we just need to upgrade the ACE we are using in Connect App to the latest version and don’t need to do anything else to be compatible with AGC, right?

Regards,
Hung.

4

Thank you @HungTran for creating this thread. Piggy banking on what this thread already says, we also have a similar scenario and had couple of questions regarding what exactly does Atlassian mean by saying - AGC currently doesn't support Forge Remote.

  1. Does this mean we can’t use “remotes” entry (means, no external backend) in our manifest.yml file?
# should this entry be removed from manifest.yml file in order to make our app compatible with AGC?
remotes:
  - key: connect
    baseUrl: ${FORGE_REMOTE_BASE_URL}
  1. If that’s the case, is it fair to say that only Forge Native apps are AGC compatible?

@jrichards @HungTran Please let me know if you rather want me to create a new community thread for this.

5

HI Team,

I got some updates about this. In Forge in AGC, you can use fetch() to make external calls to outside services, including the Connect service or any other service so long as it’s in the manifest.yml as usual.

Your Connect service, running ACSB or ACE will work with the in-boundary key-servers. Which means, a Connect service can make product REST calls using a jwt.

Forge apps can make calls to a Forge resolver on the Altassian platform, which can then make product calls, calls to Forge Storage, etc.

But a Forge Remote, as documented in

basically shouldn’t be used because although you can call the Remote service, the token service isn’t available in AGC and so calls from the Remote service to Atlassian platform isn’t supported. This affects product REST calls, Forge Storage, etc.

James.

6

Hi @jrichards
Thank you for the information.

To confirm, if our app uses fetch with JWT for API calls in Connect App service and AP.request for Atlassian API calls on the front-end, will this configuration be compatible with AGC?

Will simply updating our app according to the documentation Adopt Forge from Connect on AGC be sufficient for AGC compatibility?

Best regards
Hung

7

Hi @HungTran,

Yes.

Although, as always please test.

James.

1 Like
8

Hi @jrichards,

After consulting the AGC developer documentation, I have some doubts how the entire process should look like. Thus, I have a similar question: “Is it enough that…?”

Well, what we have already done (and effectively rolled out to production) is that we’d prepared Email This Issue’s Connect backend to:

  • handle lifecycle events received from an AGC site
  • obtain OAuth2 tokens from the AGC-specific servers for user impersonation
  • load and use the AGC-specific AJS Client library (all.js)

That is, completed all the activities and prerequisites listed in this section.

We also converted our Connect app descriptor to a Forge manifest, resulting in a Connect-on-Forge app. This is currently coming through the app approval review.

So far, so good. On the other hand, what is not entirely clear to me now is whether we have to register and deploy an AGC-compliant Forge app - more precisely, an AGC-compliant Connect-on-Forge app - before moving on to the distribution phase.

If my interpretation is correct, we have to create an AGC variant of our app’s Marketplace listing, i.e. a separate listing for AGC customers.

Unfortunately, it is worded a bit ambiguously, whether a Connect-on-Forge app must be also listed in this way or only native Forge apps must get through the process described here. In other words, shall we create an AGC-compatible Connect-on-Forge app, too, or does it apply to native Forge apps only?

If yes, we’ll have two Connect-on-Forge listings as a result, right? (a standard one and an AGC-compliant one)

As a consequence, we shall not instantly enter the standard Email This Issue’s Connect-on-Forge app details as AGC App ID and AGC App Name in this form (as they must be different also in our case), right?

In my understanding, the recent changes in our Connect backend alone make our app suitable for handling requests from AGC sites. Nevertheless, the app management (AGC-specific Forge Developer Console) and the discoverability on Marketplace still require a Connect-on-Forge app to be transparently listed as an AGC-compatible app.

To do this, we’ll need access to https://id.atlassian-us-gov-mod.com (a kind of AGC-specific Atlassian Admin site?). Will it be possible, as soon as our AGC test site (and the corresponding SAML authentication) is correctly set up? Or do we have to perform further configuration steps, too? Anyway, I cannot navigate to this page at the moment (which might be due to the fact that our AGC site registration is still in-progress).

Sorry, if it all sounds a bit confusing. I hope you can deduce from it where we have uncertainties.

Thanks for your support in advance,
Márton

9

Hi @marton.kelemen,

Let me try and answer all of the questions. Having a Connect on Forge app is enough, it doesn’t have to be a pure Forge app for AGC.

If you’re running ACSB or ACE with the latest version, then it will handle the jwt look ups from the AGC environment.

For forge register, forge deploy and forge install you will need to override the GraphQL gateway as documented. You need to do this before you log a ticket to register the app, as you will get a new appId which is specific for just the AGC environment.

At the moment, there is no Marketplace for AGC apps. We have an internal list and we’ll handle the installation when requested by a customer. The AGC app won’t be listed in the Marketplace, and so you don’t need to re-list it for app approvals. That process is just for Commercial apps.

Apps will work the same in AGC, the REST calls, etc, all work the same. It’s not expected that there will be any changes to the code except for the unsupported features.

As for the site registration, I thought it was just the admin that was locked out. We’ve been able to reset that so please again to see if you have access.

James.

2 Likes
10

Hi @jrichards,

Thank you for the proper answer.

So, if I understand you correctly, there won’t be a publicly visible AGC-compatible app variant on the Marketplace, at least not for the time being. On the other hand, you require us to register a dedicated/separate Forge app for AGC, as you pointed out:

For forge register , forge deploy and forge install you will need to override the GraphQL gateway as documented. You need to do this before you log a ticket to register the app, as you will get a new appId which is specific for just the AGC environment.

Based on this information, I think, we need to follow and perform all the steps in case of our Connect-on-Forge app, too, as intended for “pure” Forge apps, more concretely, all the steps described in this and this sections, just in order to get and distribute the new AGC-compliant appId. This will allow you to administer our AGC-compliant app variant internally and apply the necessary Forge lifecycle flows, right? (sorry, my wording might not be entirely accurate, but I hope, it is clear what I mean from our perspective)

Well, if there are no more thoughts on this, thanks again for the clarification.

Best,
Márton

1 Like