Releases: toolsplus/atlassian-connect-play
0.8.0
This version includes support for Play framework 3.x and updated dependencies.
To upgrade, first, follow the Play 2.9 migration guide, followed by the Play 3.0 migration guide.
0.7.0
Adds support to handle Forge Remote requests by providing request refiners and Forge Invocation Token (FIT) validators.
Starting from this version, we introduced an AtlassianHostUserRequest abstraction because the framework now handles host-user requests from Connect as well as Forge Remote.
A Connect or Forge Remote app is now required to provide the atlassian.forge.appId configuration. Refer to the reference.conf for details.
0.6.2
0.6.1
This release adds ForgeInstallation and ForgeInstallationRepository models to provide accurate Forge installation to Connect host mappings. In some situations, multiple Connect hosts can have the same Forge installation ID or different Forge installation IDs can refer to the same Connect host. When working with Forge Remote Compute requests, the framework user must always look up the correct Connect host based on the Forge installation ID and the ForgeInstallationRepository. Refer to this issue comment for further details.
If you are updating to this release, make sure to use an updated version of your storage adapter that implements the ForgeInstallationRepository. If you are using atlassian-connect-play-slick, make sure to update to version 0.4.1.
If you are using database evolutions, you need to add evolutions to create the Forge installation table on the database. Refer to the sample evolution script for details.
0.6.0
This release updates the AtlassianHost model by including a new optional field called installationId.
If you are updating to this release, make sure to use an updated version of the AtlassianHostRepository storage adapter. If you are using atlassian-connect-play-slick, make sure to update to version 0.4.0.
If you are using database evolutions, you need to add evolutions to ensure the database matches the current AtlassianHost model. It's also recommended to create a database index on the installationId column as apps will be looking up AtlassianHost records based on the installationId column.
0.5.1
This release adds sttp to the project and provides a JwtSignatureSttpBackend to send sttp requests "authenticated as app" to Atlassian hosts. This offers more flexibility to write backend agnostic HTTP clients, which allows us to replace HTTP backend with any desired implementation easily.
This is an alternative to the existing Play-WS HTTP client. We may remove the current Play WS client in the future as sttp already provides a Play WS backend.
The existing Play WS AtlassianConnectHttpClient has been renamed to PlayWsAtlassianConnectHttpClient.
0.5.0
This release updates the AtlassianHost model by including newly added fields and removes deprecated fields.
If you are updating to this release, make sure to use an updated version of the AtlassianHostRepository storage adapter. If you are using atlassian-connect-play-slick, make sure to update to version 0.3.0.
If you are using database evolutions, you need to add evolutions to ensure the database matches the current AtlassianHost model.
0.4.2
0.4.1
This release fixes a major bug in the AsymmetricJwtAuthenticationProvider which rejects valid JWT signed requests if it cannot find an installed Atlassian host in the database. Instead, this fix changes the authentication behavior in the AsymmetricJwtAuthenticationProvider such that it will return Option[AtlassianHostUser] and not fail if no host could be found in the database.
At the same time AtlassianHostUserAction has been replaced and split it into AsymmetricallySignedAtlassianHostUserAction, SymmetricallySignedAtlassianHostUserAction and JwtAction.
App controller endpoints that expect Atlassian JWT signed requests must now use the new framework action format:
atlassianHostUserAction.authenticateWith(qshProvider) where atlassianHostUserAction can either be an instance of SymmetricallySignedAtlassianHostUserAction or AsymmetricallySignedAtlassianHostUserAction. As asymmetric JWTs are currently only used for app lifecycle hooks, apps typically only use SymmetricallySignedAtlassianHostUserAction.
qshProvider should refer to an instance of either CanonicalHttpRequestQshProvider for dynamically computed HTTP request QSH values, or ContextQshProvider if the app endpoint expects static context QSH values.
0.4.0
This release changes the LifecycleController to enforce the new Atlassian Connect install flow using asymmetrically signed JWTs. Additionally, previously deprecated methods are now removed, such as mechanisms to authentication without QSH (context-qsh migration) or userKey property from AtlassianHostUser (gdpr migration).
Starting from version 0.4.0 Atlassian Connect apps must define the following API migration properties in the Atlassian Connect descriptor:
...
"apiMigrations": {
"gdpr": true,
"context-qsh": true,
"signed-install": true
},
...App controller endpoints that expect Atlassian JWT signed requests must now use the new framework action format:
atlassianHostUserAction.authenticateWith(jwtAuthenticationProvider, qshProvider)
jwtAuthenticationProvider can either be an instance of SymmetricJwtAuthenticationProvider or AsymmetricJwtAuthenticationProvider. As asymmetric JWTs are currently only used for app lifecycle hooks, apps would typically only use SymmetricJwtAuthenticationProvider.
qshProvider should refer to an instance of either CanonicalHttpRequestQshProvider for dynamically computed HTTP request QSH values, or ContextQshProvider if the app endpoint expects static context QSH values.
The Play actions to accept unsigned installation requests (previously used for initial, first-time installation requests) are now removed.