Simple verification procedure to prepare your app for single shared secret migration

We recently announced that we are moving away from per-installation shared secrets for Jira Cloud and Confluence Cloud apps. In that announcement we detailed how we're migrating over to a single shared secret and that your apps will receive a second installed lifecycle endpoint call to make the update.

There have been some discussions on the developer community on how to ensure apps are ready for the migration and Norman Atashbar provided a simple verification procedure you can do on your app to ensure that it is ready for the migration call to the installed lifecycle endpoint.

Verification procedure

The sync process is very similar to an install-uninstall-install sequence that causes Connect to generate a new shared secret and sign it with the old shared secret for the second ‘installed’ lifecycle callback. By ignoring the uninstall event an app developer can simulate the shared secret sync operation that will happen during migration. Here is what you can do to verify your app will behave properly during migration:

  • Disable the uninstalled callback handler. One way is to modify the descriptor and map the ‘uninstalled’ lifecycle event to a non-existing path.
  • Start the app in the dev environment.
  • Install the app using its descriptor URL. Your app will receive an ‘installed’ callback.
  • Configure the app and make sure it works properly.
  • Take a note of the existing shared secret in the app database.
  • Uninstall the app via the Manage add-ons admin screen. Since you've disconnected your app's uninstalled handler, the original shared secret will remain in your app's database.
  • Your app will now receive another ‘installed’ callback, providing a new shared secret in the payload of the request, but with the request signed with a JWT based on the old shared secret.
  • Make sure the app still works properly and the shared secret is changed in its database.

If you had any issues, please feel free to reach us via this thread or by creating a new service desk ticket. We have an internal process to dry run the migration on a test instance.