22 Sep 2021 - Unifying Atlassian Connect and Forge: An Update

Hi @AditiVenkatesh ,
in your investigation, please keep in mind that background apps, such as automation apps (e.g. JMWE) need to be able to impersonate users without requesting their consent, for 2 reasons:

  1. the app operates in the background and thus doesn’t have a user interface to request this consent
  2. the users don’t even know about the app, which is installed and configured by admins
6 Likes

Hi @AditiVenkatesh ,
dogfooding is not the same as “trying this out ourselves”. Dogfooding requires you to implement commercial products using the same functionality third-party vendors must use.
To give you an example, when Salesforce built their force.com platform, they simultaneously built their BI solution on top of it, which ensured that the platform would be useable to build commercially viable apps.

14 Likes

Hi @AditiVenkatesh ,

I think you’ve missed my point about Migrations. What you’re asking vendors to do here is write cloud versions of server/dc apps to in Connect (a now deprecated platform). We’ll then have to re-write then for Forge. The re-write to Forge is busy work that provides essentially no value to customers, but costs us development time where we could be delivering value. The Cloud Migration strategy and push to Forge do not appear to be aligned from a vendors perspective (and there fore customer impacting).

@david2’s point about dogfooding is spot on. We don’t want toy apps, we want Atlassian to have something valuable to risk. What about porting Insight Asset Management to Forge?

13 Likes

@remie that’s right, the admin will agree to a set of scopes on install so the app can authenticate (as itself, not as a user) without user interaction.

2 Likes

We can understand the benefits on your end for such a solution, it is definitely not ideal on ours as this changes our technology stack and creates a separation between cloud and DC.

We would like to make sure of one thing though ; As Atlassian will be taking on hosting the app, computing and storing it on its own infrastructure, will the cost of hosting be trickled down to the vendor?

Or in simpler terms: is Forge going to incur a cost to the vendor?

Regards.

I believe that this post is the most recent announcement related to this: Forge pricing update: free through 2023

The direct answer to your question is near the end:

What happens after December 2023?
In the spirit of Atlassian’s OCNB value , we still need more data on Forge app usage to determine a long-term economic model. Our preference is to keep Forge as free as we can: we see its primary value in improving Atlassian products to better serve every customer. In any case, we will always remain competitive against the platform costs and benefits of cloud providers. We will share an update on the long-term plan by September 2022 at the latest, though we endeavor to do so significantly earlier if possible.

3 Likes

That announcement sounds different now once we learned about the plan for Connect, and the idea of “no data&compute outside of Atlassian”.

In any case, we will always remain competitive against the platform costs and benefits of cloud providers.

Such competition will be illusory, if app developers will not be able to use other cloud providers.

1 Like

Thanks @david2 - we are actively exploring our overall consent experience and looking at ways we can simply it for end users and Admins. Will update the community once we have something concrete to share.

Yes @jmort, with connect on Forge we want to soften the migration path and hence Stage 3 and Stage 4 are optional but recommended. We see this as a multi-year transformation, as we get more and more server customers migrated to Cloud, we need to support the ever growing needs that come up with enterprise customers related to trust, scale, security and compliance. This post aim was to share early and often on what we are thinking with the wider community and collectively work to shape the future journey of Connect on Forge.

You make a valid point on dogfooding, internally we have built Forge apps and we should be sharing that more. We are exploring ways to move apps built by Atlassian to migrate to Forge and will share back the learnings we get from those migrations.

3 Likes

What is the reason for sunsetting Connect?

We haven’t said we’ll be sunsetting connect besides deprecating support for JWT auth and remote iframes in due course, to raise the security bar.

Are you asking why we can’t continue to support remote compute or remote storage? We believe we will need to continue to support those in some form.

Are you asking why we can’t keep the connect modules that use those features around, but migrate them to a different kind of auth? We could do that, potentially, if Forge modules were found to be an inadequate substitute.

Are you asking why we’ll be requiring vendors to migrate to Connect-on-Forge, i.e. to go from a descriptor to a manifest, instead of adding a compatibility layer to forever handle the difference behind the scenes? Because there are various historical reasons why that’s more trouble than it’s worth, for example the fact that connect apps are identified by a user-supplied key, which isn’t guaranteed to be unique for non-marketplace apps, rather than by a UUID in a centralized system (as is the case with Forge).

Not sure if I understood the question correctly, let me know if not and I’ll have another go at answering :slight_smile:

2 Likes

So from a Connect developer’s perspective - what’s left after JWT auth and remote iframes are removed?

5 Likes

I’m not trying to be difficult - but isn’t marketplace.atlassian.com that register today? Aren’t app keys much more user friendly?

2 Likes

Today’s state of forge modules aren’t the same. What’s the path to take me from any connect module to Non-connect forge? If it’s missing - what’s the path and timelines?

3 Likes

@asridhara

You say Atlassian has built Forge Apps. Maybe I’m just blind, but can you point me in the direction of CDAC threads created by the people working on those Apps? I am assuming they’ve run into issues from time to time? Things like missing features, confusing/missing docs, outages, bugs, etc?
I can’t seem to find anywhere where Atlassian developers working on Forge apps are participating in that.

To me, this makes it look like there is no real dogdooding going on. Because your developers can simply backchannel, using resources that are not available to anyone else. Which in turn would also mean that their experience developing for Forge would be dramatically different than the experience we vendors have.

Of course, I could be horribly wrong about that, and would love for someone to correct me.

6 Likes

So from a Connect developer’s perspective - what’s left after JWT auth and remote iframes are removed?

I admit that makes up a lot of Connect, but there are some extensible things that don’t use those, like custom fields.

isn’t marketplace.atlassian.com that register today?

If the first step for making an app was always to create a private marketplace.atlassian.com listing then that would suffice to keep enforce app key uniqueness, but that’s not the case; some Connect and Forge apps never even make it on to marketplace. Also, marketplace does not serve as an authoritative register for other things we want to know, like where an app is installed.

Aren’t app keys much more user friendly?

I’d argue that an app key as a primary identifier is less user friendly than letting the system generate a unique identifier - to give just one example, if you put your company name in your app key and then your company changes name or hands, you’re stuck with the old name in the key. Additionally, with a UUID you can’t accidentally create collisions between different test instances of your apps by giving them the same key.

Today’s state of forge modules aren’t the same. What’s the path to take me from any connect module to Non-connect forge? If it’s missing - what’s the path and timelines?

We’re working through that that at the moment - that is a good question in particular when it comes to things like existing macros saved in Confluence pages, which we’ll want to ensure keep working if those macros get replaced with the Forge equivalent.

5 Likes

Hello @AditiVenkatesh I want to bring to your notice that Forge does not support organisation level user proxy, which blocked some of our developers to build an app for our requirement.
Refer the issue - I can't login to forge - #3 by GauravAgrawal

A question regarding “state 2”, which includes:

Connect remote iframes must be replaced with Forge Custom UI or UI kit

One of the issues preventing us from moving to Forge (there are many others issues, but let’s focus on this one), is that the sandboxed iframes for CustomUI are more restrictive than Connect, specifically: no allow-popups.

I understand that this was an intentional decision, and that the recommendation for Forge apps that need to open links in new windows/tabs (<a target="_blank">) is to use the router from @forge/bridge.

In our case, this is not easily done. Our Confluence dynamic macro takes user-supplied JSON/YAML (either fetched from an external URL, or embedded into the body of the macro), which may include some arbitrary markdown.

We use a third party library to process this markdown, and by default any links in the user-supplied content are rendered with the target="_blank" attribute.

So as the app developer we are neither in control of:

  1. The user-supplied source that may contain links that explicitly specify target="_blank", nor
  2. The library that converts markdown to HTML, which makes all links target="_blank"

We are currently investigating alternate solutions that involve finding all links on the page that have target="_blank" and augmenting them with an onclick handler that intercepts the click passes it to @forge/bridge’s router.open(url). (This may not be achievable in all cases, since some content is dynamically rendered; so some links may not be in the DOM until later).

Will there be any affordance at “state 2” for Connect apps that currently rely on the sandbox="allow-popup" attribute on remote iframes, or is this something we need to address before we can reach “state 2”?

1 Like

Hi Dmitry,

This update specifically relates to Atlassian Connect for Jira / Confluence. Though we are aiming to bring Forge to Bitbucket Cloud and our other Cloud products, we haven’t publicly announced timelines for them yet.

Hi @scottohara , I can’t give a definitive answer but I wouldn’t count on any extra affordance or exception besides the documented workaround. I’m interested to hear how the investigation goes.

Hi @emil,
If i understand your question correctly, all users with an Atlassian Account should be able to access APIs with OAuth 2.0. If you are specifically talking about access to JSM APIs then this should be available soon and well before State 2.
Cheers,
Sam Purchase

2 Likes