Will spring atlassian-connect in future won't be supported?

Jira Development Jira Cloud
, , ,
1

Hi Team,

I have some queries regarding our Jira Cloud app. We have developed an application using Spring Boot, which we install in Jira via the atlassian-connect.json file, and it has been functioning well so far.

However, I recently came across information indicating that Atlassian intends to end support for the Connect framework. I am concerned about the implications of this for our application, as we are currently utilizing the atlassian-connect-spring-boot library.

Could you please clarify whether this means our current approach will no longer be viable in the future? If so, I would appreciate any guidance on how we can ensure our application remains supported moving forward.

Thank you in advance for your assistance.

2

As it is currently communicated by Atlassian, Connect apps will continue to work, but they will just not be supported

In practice, end of support means ‘use at your own risk.’ When end of support takes effect, Connect will no longer receive new updates or features. Only critical or security-related bugs will be addressed, and any bugs which are deemed to be non-critical or do not also impact a Forge equivalent will not be fixed. Support queries for the Forge platform will be prioritized, and SLOs for responding to ECOHELP tickets and escalations related to Connect and Connect modules/extensibility will be lengthened or removed. Customers who have Connect apps installed won’t lose access to the app, but this is an undesired state for customers due to lack of support, and we will message accordingly to customers on the Marketplace. In addition, new versions of the app will not be able to be delivered on Connect.

When Connect integration points become incompatible with the future state of our products, they may be deprecated and become Forge-only. We will make these assessments on a case by case basis, and we do not plan to retire Connect as a whole at this stage.

https://www.atlassian.com/blog/developer/taking-the-ecosystem-forward-an-update-on-the-future-of-connect

3

I have spoken with a couple of people of Atlassian in relation to this and as long as Connect is supported, they will continue to support the official connect libraries. But don’t expect any new-new work. Its more keep the lights on.

The future after end-of-support is not clear yet. They may refactor the libraries to become Forge remote starter libraries, or they may just go to the attic or the bin.

I’m keeping ACSB for my app, but only as long as I need it to keep connect-on-forge support going.
I found that in testing all the authentication code with filters, authentication providers provided by ACSB can be replaced by this code:

http.oauth2ResourceServer(oauth -> {
            oauth.jwt(jwt -> {
                jwt.decoder(NimbusJwtDecoder.withJwkSetUri([JWKS_URL])
                        .jwsAlgorithm(SignatureAlgorithm.RS256)
                        .jwtProcessorCustomizer(processor -> {
                            processor.setJWTClaimsSetVerifier(new DefaultJWTClaimsVerifier<>(new JWTClaimsSet.Builder().issuer(
                                            "forge/invocation-token")
                                    .audience(environment.getProperty([APP_ID]))
                                    .build(), new HashSet<>(Arrays.asList(JWTClaimNames.ISSUER, JWTClaimNames.AUDIENCE))));
                        })
                        .build());
            });
        });

Simply replace [JWKS_URL] with https://forge.cdn.prod.atlassian-dev.net/.well-known/jwks.json for deployments and [APP_ID] with your Forge app id.

For invoking Jira, Confluence, Compass, etc. REST APIs you can use the tokens provided in the request x-forge-oauth-system and x-forge-oauth-user.

So the overall value for a supported library is minimal, if any, and thus I wouldn’t count there coming one.

So you have two options for now that I see:

  1. Keep using your app as is without any Forge or Connect-on-Forge and wait for an announcement or breaking changes.
  2. Start your migration to Forge, connect-on-forge to start with, followed by a migration to Forge.

Option 1 is tech dept for the future, option 2 is development effort now.

I’m going for option 2 and am happy to connect if you like to know more.

1 Like
4

Thanks for you response. so here we can keep forge application as gateway/proxy which will be helpful for installation, authentication and all but while using we can proxy it to our spring application so it won’t require ACSB.

5

If you can, simply adopt connect-on-forge, and you can keep your connect app as is without needing to start work this minute.

Then you can opt to implement new features in Forge to start the migration process one module at the time.

6

But issue is I have application such as power BI and Tableau so cannot convert it whole to forge. Need to think some middle way so in future don’t need to re-work.

7

There are some things to consider before doing this. For instance, there is still the issue with manual upgrade requirement. Connect-on-Forge apps are not automatically migrated to the new Forge manifest. That means that some customer will continue to use the Connect descriptor. If you start making changes to your code base assuming that all customers use the new Forge manifest, some customers might loose functionality.

Please make sure to fully understand the implications of migrating to Forge from Connect

8

Not necessarily, you can adopt Forge Remote to keep using your existing code. With connect-on-forge you can continue to use your app as is without any changes.
Then bit by bit, you can adopt your app backend to a Forge Remote so you can invoke them when you decide to update the UI of your app to Forge.

I develop the Jenkins Integration for Jira app, this is currently a connect-on-forge app, basically a Forge manifest on top of my Connect app. Adoption is a very slow process, only a handful customers have updated the to use the connect-on-forge version because of the manual admin approval @remie highlighted. But this is not a new problem, I still have the majority of customers running version 1.4.0, another handful on 1.5.x and then the first adopters of 2.3.0 (forge).
Manual updates have been a pain for a long long time so is not new.
On top of this app, there are the Jenkins for Compass and Jenkins for Confluence apps, both are Forge apps but use the Jira app as a Forge Remote.By adopting connect-on-forge with my Jira app I can start developing a common platform that is shared between the apps, making it easier to maintain in the long run.
Yes the migration is a pain, you need to keep bits of the Connect app alive while customers have not updated yet. Mainly the REST client, Connect uses a shared secret based JWT, where as Forge used OAuth tokens. And if you have a database per tenant multi-tenancy implementation like I do, then you may need a different method to determine the database to use, I used client_key before, but Forge doesn’t have this, only Connect does. However, Forge includes the cloudId in its tokens and Connect can also resolve this id easily, so that is my next step.

The path I have set for my Jenkins apps allows me to keep my Connect app as is, and add new Forge Remotes to the deployment that will service new features.

Then it comes to getting customers to adopt the new version of the app, while features help drive updates, for some customers this is not enough, those will be the last to migrate and thus will be the first to get notifications and/or errors if they keep using Connect.

1 Like