Hi everyone,
We’ve released an update regarding the Connect-on-Forge migration pathway. You can read it here: Unifying Atlassian Connect and Forge: An Update - Atlassian Developer Blog.
Please use this thread to raise any questions you have and a member of the Atlassian team will try to respond as soon as possible.
As always, if you have any feedback or are interested in migrating your Connect app, please reach out to us.
Regards,
Aditi Venkatesh
Product Manager, Forge
Thanks @AditiVenkatesh for sharing this. Can you make it more clear: do you want all apps to eventually reach Stage4, or it’s just an option, and those who want can stay in Connect?
Forge does not offer any real time communication capabilities, so there is no point to start migration, because the requirement of “all data on-Atlassian” cannot be satisfied. I assume Atlassian will not try to compete with cloud tech vendors like AWS, GCP, or Twilio, because it’s a race you can’t win.
that’s just my perspective, I’m sure other people will bring other viewpoints
Hi @Grzegorz,
Thanks for your question.
States 3 and 4 are not hard requirements with room for cases where “off-Atlassian” compute and storage are absolutely essential. As noted in the blog post, although there will be no approval process regarding this, we will be making it more transparent to end customers where data is stored and processed.
We understand that apps have varying needs however, we do highly encourage developers to consider State 3 or 4 where possible.
Regards,
Aditi Venkatesh
@AditiVenkatesh - how is all of this going to work with data residency?
Assume an app cannot reach state 3 and 4 due to technical limitations, and is implementing data residency now, how will that work going forward when that app need to reach state 2?
@AditiVenkatesh I’m not sure if you intended to do this, but please be aware that you’ve cause a lot of anxiety in the Marketplace Partner community. Your blog post is basically the first time we’ve been communicated a timeline for Connect deprecation (end of 2022) from Atlassian. We’ve been asking for clarity on this subject for some time now, and we finally have an answer (buried away deeply in your blog post).
This will mean that Marketplace Partners will start reconsidering a lot of planned work for Connect apps as it might no longer be feasible to implement / support features like data residency for Connect apps.
Also, it might be worthwhile to start communicating End of Life for Connect on the Atlassian documentation sites, as it would not be fair to new developers to start with Connect without knowing that the framework is deprecated per end of 2022.
Hi @AditiVenkatesh thanks for the update that’s very illuminating.
Please can you provide a timeline for implementation of the following on Forge:
Those are all blockers for us to even start planning a move of our apps to the Connect-on-Forge.
@ademoss and @jbevan , I’m hopeful we can get a public roadmap for those features up soon. The end-of-2022 date is when we hope the very last app will be unblocked to start the process of registering onto forge and swapping out their modules that depend on JWT and remote-server-hosted iframes, not when we intend to switch those things off. That’s why the date was not up top, front-and-center, it is not a sunset date.
@jbevan given your app includes DR and dynamic modules, there’s a good chance it will be in the tail end of unblocked apps, but the order in which we tackle the feature gaps will be influenced by what we hear from app developers about what is top priority.
To add some things to the blockers:
Thanks @jmort , this is the sort of thing need to take into account to figure out when it’s feasible to insist on a migration - there’s a lot to take into account which is why we are trying to share what we can about it but also only able to talk in rough dates at the moment.
If there is something specifically stopping us implementing our app on forge, where is the best place to report that?
Simply posting it in a thread doesn’t really work. Is the requirements list formally written down somewhere?
Hi @remie,
Thank you for sharing this with us. We understand your concern, however the intention was not to indicate a timeline for Connect deprecation.
We still support Connect and will continue to deliver additional functionality to the framework. This migration pathway is designed to allow you to continue running your Connect apps whilst also taking advantage of Forge features.
We do want to be transparent that in the future, Connect will stop supporting JWT auth and remote iframes, to set a higher security bar. While these services are not being deprecated yet and we are still far out from making this a hard requirement, we encourage app developers to start planning to make these changes as soon as migration for these components is unblocked, which we estimate will happen towards the end of 2022.
Any hard requirements regarding this will be announced with enough buffer for you to make any necessary changes.
I hope this addresses your concerns.
It was this part that created the confusing. The wording was a bit ambiguous. But it has been clarified by @jhazelwood:
@daviddrawio you can share your requirements and feedback by creating an issue in the Forge Jira project
Connect will stop supporting JWT auth and remote iframes, to set a higher security bar.
This practically means deprecating Connect. I did not see any official announcements on that matter, this is the first one 
I agree with @Grzegorz here: even after the confusion about the sunsetting date has been resolved, it does mean that Atlassian has now for the first time communicated that it plans to deprecate Connect in the future.
It might still be worthwhile to mention that in the Atlassian Connect documentation, as it means that by definition, Connect is now a deprecated framework as there will be a point in the near future in which it will no longer be supported.
This practically means deprecating Connect. I did not see any official announcements on that matter, this is the first one
That’s fair; this is a first and JWT auth and remote iframes do form a big part of Connect, and I’ll feed back the idea about signalling this in the Connect docs somehow. The tension is that we think the official deprecation of JWT and remote iframes (with a clear migration path) is the right move, and we want to share our thinking on this, but we haven’t got the migration path in place yet to do an official deprecation.
@AditiVenkatesh @jhazelwood can you give a bit more information about this OAuth implementation for Connect on Forge? Will it be app-based OAuth, with a service account as the user, or do you mean the already existing OAuth implementation in which the app will require to ask permission to individual users (as per the current flow)?
All the latest security initiatives are related to AC for Jira/Confluence. And seems like this update is also related to Jira/Confluence apps only. Could you please share any plans about Bitbucket Connect in relation to Forge?
As there any ETA on when Stage 1 will be production-ready? We just started work on a whole new UI and now knowing it would have to potentially be rewritten is a headache
Also an update on Bitbucket Cloud support is important too
Hi @remie, the OAuth 2.0 implementation for Connect on Forge will be using the Client Credentials flow where an app will authorise as itself rather than a specific user.